The KDE Developers' Conference is a meeting of KDE contributors from
all over the world. It will feature three days of technical talks and
tutorials. Do you have a particular expertise related to KDE programming that
could be useful for your fellow developers? Do you want to present a
particular programming pattern, a tool, a development strategy, or
anything else that helps KDE developers become more productive? Then
consider talking about it or giving a tutorial at the KDE Developers'
Conference.
KDE Developers' Conference - Call for Papers
August 23th to 25th
Zamek, Nove Hrady, Czech Republic
Conference Program
The KDE Developers' Conference is a meeting of KDE contributors from
all over the world. It will feature three days of technical talks and
tutorials. Following the conference there will be some - albeit
limited - opportunity for interested groups to gather together in
computer labs for a hacking session until the 31st of August.
Besides, there will be plenty of time for socializing.
More information is available at http://events.kde.org/info/kastle
Do you have a particular expertise related to KDE programming that
could be useful for your fellow developers? Do you want to present a
particular programming pattern, a tool, a development strategy, or
anything else that helps KDE developers become more productive? Then
consider talking about it or giving a tutorial at the KDE Developers'
Conference.
We solicit submissions for presentations and tutorials from, but not
restricted to the following fields. Everything KDE-related will be
considered.
- KDE and Qt programming tricks
- DCOP, KParts, KOffice, multimedia etc. development
- programming tools, patterns
- programming patterns and development strategies
- project management issues
- internationalization
- documentation
- usability, accessibility, interoperability
Talks will be scheduled for 45 minutes talk and 15 minutes Q&A. In
some cases, it may be possible to occupy two slots for a total talk
time of 90 minutes or offer short presentations of 15 minutes
each. Please note the estimated talking time in your application.
Finally, BoF sessions can be announced in advance or planned on the
spot. A limited number of group rooms will be available for BoFs.
Submission Guidelines
Those proposing to present papers should submit an abstract including
the name and e-mail address of the author or authors to
[email protected]. The conference language is English. The
abstracts will be reviewed by the program committee based on content,
presentation and suitability for the event. By submitting an abstract
you give permission to publish it on the conference web site.
Location
The KDE Developers' Conference will take place at the Zamek ("Castle")
in Nove Hrady in the southern part of the Czech Republic in Central
Europe. Facilities are hosted and sponsored by the Institute of
Physical Biology of the University of South Bohemia. Nove Hrady cannot
easily be reached by public transportations, but a shuttle service
will be provided from Prague-Ruzyne airport and Prague Central
Station.
Speaker Incentives and Financial Compensation
The KDE Developers' Conference is run by KDE e.V., the Academic and
University Center Nove Hrady and the Polytechnic University of Upper
Austria in Hagenberg. KDE e.V. is a non-profit organization of
volunteering professionals and enthusiasts of free and open-source
software.
We only have a limited budget for this conference, and cannot
generally pay travel expenses or any other reimbursement or
gratification to speakers. We can provide accommodation and boarding
at a very low price (expect about 15-20 Euros per day for full board
and lodging, but don't expect luxury accommodation), and the shuttle
service from and to Prague will be free of charge.
KDE e.V. is soliciting donations from companies and individuals
towards this conference. These donations will be used both for running
the conference and for bursaries for delegates from other continents
and/or without income. Delegates with an accepted paper will be
prioritized in the distribution of these bursaries.
Please note that even if we can grant you a bursary, you will still be
expected to pay a part of trip yourself, as well as your boarding and
lodging.
Important Dates
Please submit your contributions no later than the indicated dates:
Abstract submission deadline:
May 31, 2003
Acceptance notification:
June 16, 2003
Final papers due:
July 16, 2003
all 23:59 UTC
For the Program Committee
Matthias Kalle Dalheimer
President, KDE e.V.
Comments
OK, I see your point. Although this isn't the way I am used to working,
I will try it (again) with another posting about the outdated font stuff (which doesn't work with current software) in the: "startkde" script.
--
JRT
I don't know what one learnt at UCSB in the '70s (data base design?, mainframe programming?). But if you would have studied CS in Germany in the '70s or '80s then 95% of what you would have learnt would have been useless theory and at most 5% would have been useful practical experience. German CS graduates did know near nothing about programming but everything about the theory (aka hot air). That's why many companies prefered to hire mathematicians, electrical engineers, etc. instead of CS graduates because the former didn't just know how to give talks about programming they actually did write programs to solve their problems during their studies. In the meantime (in the last 5-10 years) this has changed in Germany.
My point is that a CS diploma doesn't mean that someone knows anything useful about programming. Especially if he studied CS back in the stone age of CS.
HELLO: I studied Electronic Engineering & Computer Science (with emphasis on the first part) which pretty much negates most of what you said.
And part of your premise is simply wrong. A program is a program; it doesn't matter if it is written in ALGOL, BASIC [:-(], FORTRAN IV, FORTRAN 77, FORTRAN ??, K&R C, ANSI C, F, PL/Fiv, L, or languages many have never heard of. To use your figure, 95% of it is just the same.
Yes, I know what punch cards are by actual experience, and I have used a Tek 104x graphics terminal. Does that mean that I somehow know less?
Also, I learned OS/360 mostly by reading the manual. This teaches an important skill that you probably don't get (and it isn't how to use OS/360).
Your opinion has been noted.
AFAICS (I don't know F and L) all the languages that you mentioned are procedural programming languages. But KDE is developed in C++ which is (or at least tries hard to be) object oriented. Developing OO programs is fundamentally different from developing programs in a procedural language (at least if one fully understood OOP). Knowing all about apples doesn't make you an expert for oranges.
I'm not claiming that you know less about OOP than about procedural languages. But I wonder why you didn't mention any OOP language.
BTW, I once learnt how to program an IBM 360/370 in assembler. So please stop making false claims about people you don't know.
Its good the hear that you know PL/Fiv. :-D
As an OOP skeptic: I point out that OOP is actually only a way of organizing the programs structure. C++ is more of a quasi-OOP language -- C in an OOP wrapper. The actual code is still written in a procedural language. So it is more like apples vs. pears or with C++ and C, with different kinds of apples.
If you read SIGPLAN notes, you will find that there is some really new stuff out there that is "oranges": :-) FPLs and AOP.
I told Datschge that I would stop responding to personal issues.
But, my congratulations on learning IBM 360/370 assembler.
You don't understand that Object-Oriented design is different from procedural design?
You don't understand that choice of language can have profound implications on productivity and design?
You think that Lisp is the same thing as C?
> You don't understand that Object-Oriented design is different from procedural
> design?
No, what I understand is what I said; that it isn't as different as advocates of OOP say that it is.
Tell me, when you want to do something like:
y = m*x + b
do you do that differently in OOP?
> You don't understand that choice of language can have profound implications on
> productivity and design?
I'm not certain that I see your point. Yes, the choice of language can have profound implications. That is why C is a always a poor choice. However, no matter what language you choose to use, the program itself will be basically the same. It will have a structure that appears quite different in the source code, but it will be much more the same than you might think.
> You think that Lisp is the same thing as C?
Well strictly speaking, Lisp is NOT a programing language (the same as BASIC isn't) but there are Lisp dialects which are compilable and meet the technical definition of a programing language. If you use such a compilable Lisp dialect, then the exact same program could be written in Lisp or C. And, I am certain that you will be shocked to learn that there are programs which will convert a Lisp program to a C program.
> Tell me, when you want to do something like:
>
> y = m*x + b
>
> do you do that differently in OOP?
Depends. In a procedural language you can only write the above in case y, m, c, a^H^H^H^Hx, b are scalar variables. In C++ OTOH you can simply overload the = operator, the * operator and the + operator and so make this calculation/assignment work for virtually all types of objects for which this assignment makes sense (think of vectors and matrices). But operator overloading is in fact just a shorthand notation. In real OOP you would probably write this:
y.copy( m.multiply(x).add(b) )
But what has this example to do with a development strategy? Development strategy isn't about the choice of the language, right?
> But what has this example to do with a development strategy?
Absolutely nothing. Very OT.
Much more relevant question is who are these anonymous trolls that ask such questions?
Yes, I know: I shouldn't answer them.
But since you said it, please note the exact one to one correspondence between:
y.copy( m.multiply(x).add(b) )
y = ( m*(x)+(b) )
Changing the tokens does NOT change the syntax. :-)
There was a very good article on this in SIGPLAN Notices sometime in the last year or so, but I can't seem to find it at the moment, which showed with a short example the proper way to write OOP code and also the one to one correspondence to procedural code.
> Development strategy isn't about the choice of the language, right?
Yes.
--
JRT
Have you heard of Turing completeness? What you say is *nothing* insightful.
Of course you can turn C++ into C, but that is not the point of Object Oriented design. Who the heck cares about "y = m*x + b"? This is one single line of code and it is a mistake to look a single line of code and pretend that that says *anything* at all about Object-Oriented design vs procedural design.
Compiling Lisp to C, oh geez. Who cares? Did you know you could compile Lisp to machine code too? What's your point? Focus, man.
I shouldn't reply to anonymous trolls, but:
My point is not about programing languages. You represent my remark about those that, for some reason, think that the realization of a program in a certain language *is* the program.
Like a Platonic form, the actual program has an existence separate from its realization.
It isn't about turning a C++ program into a C program. It is about the fact that you can write the same program in different languages and it will be the same program.
The point with the "single line" is that with C++ when you get down to doing the actual work that it uses C (procedural) code.
> Did you know you could compile Lisp to machine code too?
It depends on what you mean. You can compile Common Lisp and Basic but they will NOT run without the run-time code. This is why it is said that they are not really programing languages.
On the other hand, when you compile C, you get an assembler program which will run independently just the same as if you had written it in assembler. And believe it or not, when you compile C++ it turns into a procedural program in assembler.
--
JRT
Dude, you may have a name, but you're still a troll. Just because I'm anonymous doesn't make me a troll.
Who cares about your discussion? I already told you about Turing completeness. Your discussion about runtimes is a complete crock. Have you ever heard of the C runtime? Yep, it's called libc and it's on just about any machine you can find out there. Your discussion about Lisp not being a programming language, whatever dude... get serious.
You claim to be a design expert yet you don't admit that designs very much depend on the language paradigm you're using. It's your words, not mine. I'm not a troll because I point this stuff out to you.
> Just because I'm anonymous doesn't make me a troll
OK, but are you anonymous because you don't know what you are talking about and don't want people to know who you are.
> I already told you about Turing completeness
You have told me nothing about Turing completeness, only that you know that the term 'Turing completeness" exists. To an engineer (me) all this means is that a program is a FSM/FSA.
If you don't know how Common Lisp and Basic work, don't just display your ignorance, read up on it and you will then understand what I am saying.
Libc is not the C runtime, it is a (statically) linkable library. If compiled to machine code, both Basic and Common Lisp need a runtime program (NOT a linkable library) to work. Can you statically link to Lisp or Basic? LOOK IT UP! Try using Google.
Lisp is NOT a programing language. When you use Lisp, you write lists which are processed by the LISP processor. You might call it a programing language, but Common Lisp can NOT be directly compiled into a static and linkable program. When you "compile" Lisp, it is normally compiled into byte-code like java is. This is still run through the interpreter. Some Lisp implementations will compile it to machine code, but the machine code for Common Lisp still needs the runtime program to work.
Can you prove that a LISP program *is* a FSM/FSA, that it meets the test of Turing completeness? If not, what is your point of bring the concept up.
What I have stated as a fact is the programs written in different languages are much more alike than the advocates of various languages claim they are.
I can now see that it is true that there is no point to having gone to college and studied EE&CS as far as this crowd is concerned. :-)
> I shouldn't reply to anonymous trolls, but:
The anonymous people let their argument speak as compared to you who everytime needs to say "I, professional computer expert, say...".
Yes, and what "anon" said speaks for itself.
(He shows this total ignorance).
--
JRT
OOOPPPSSS: Typo
That is 'ML' not 'L'.
--
JRT
i have some cod ewritten in c++ language and wish to get the code for the same in c language without recoding it in c . How do i do it?
I realize that I would not possibly be qualified to write it but:
The 'arrogant developer' syndrome
Notice in the other thread the implicit premise that a developer would never make any changes in his code based on the suggestions of others (especially mere users).
Therefore: suggestions have no value.
:-)
Which suggestion is more likely to be realized:
A) The plain suggestion and nothing else
B) The suggestion and a lot of information about the person who suggested it
C) The suggestion including use cases, involved problems and logical conclusions
D) The suggestion that is thourghly discussed (and, therefore, improved).
This is the basis of the Open Source "meritocracy" and is at the foundation of the way that the community works. Design suggestions just don't carry much weight without either patches or previously established credibility. This isn't to say that users making requests as users are ignored, but users that want to make suggestions as a developer and yet not fill the role of a developer are ignored.
i.e. "It would be nice if there was a place to click to make this happen" is fine. "Your code is poorly organized, you should be doing this, but I'm not willing to help" will meet apathy.
There have also been some assumptions in what you've said that have been wrong: you assume that KDE developers have not studied and are not professional programmers. The majority are at least one of those and many are both (including myself). The average KDE developer is probably mid-20's, university educated and with some professional experience.
As such, I'm more inclined to take suggestions from a KDE contributor that is a "has an education and is a professional" than someone who is not a KDE contributor.
My most common refrain within KDE / Open Source is "We have no shortage of good ideas." Really, KDE is developed by a small community of people with TODO lists growing faster than the things there can be completed. Intrusive, developer-oriented suggestions that lack some more tangible willingness to help simply can't be accomedated.
There are some things about the KDE community that you simply won't pick up by reading kde-devel (i.e. that's not where decisions are made generally) and certainly apps.kde.com is not a good place to get a sampling of KDE's design and review culture. Basically is looks like you're basing your analysis of KDE based on the periphery of KDE development rather than the core.
> This isn't to say that users making requests as users are ignored, but users
> that want to make suggestions as a developer and yet not fill the role of a
> developer are ignored.
I'm not sure that I understand fully what you mean.
I see an embedded premise (binary proposition) that makes little sense, but perhaps that isn't what you meant to say.
> i.e. "It would be nice if there was a place to click to make this happen" is
> fine. "Your code is poorly organized, you should be doing this, but I'm not
> willing to help" will meet apathy.
Is this meant as a binary proposition: That input should either be naive suggestions from users with know knowledge of development or ready to apply patches from developers?
But that suggestions from a knowledgeable user are not acceptable.
I note that I have made no comments at all about actual code. And, I did not say that any code was poorly organized. I have only commented on what the code does.
Again, I get back to Deming and the Japanese idea of constant improvement. Is a statement that something can be improved to be taken negatively as a statement that there is something wrong with it? If so, then this *is* a corporate culture issue.
Your example: Does saying that the code could be *better* organized mean that it is *poorly* organized.
And I am willing to help. Some of my work *is* in the current release of KDE 3.1.x!
To use as an example the patch I submitted for the: "startkde" script:
The naive user would simply say that the fonts installed (as usr [i.e. in Basic Mode]) with the Control Center Font Installer don't seem to work.
I know how the stuff works! I know (almost) exactly what the problems are:
Does this mean that my suggestions are:
1. more valuable
2. less valuable
3. worthless
An interesting question. But perhaps I have completely misunderstood you.
Example: I am willing to rewrite the font portion of the: "startkde" script, but I am not going to design it without discussing it with others. AFAIK, the kde-devel list is the place to start.
I note from this example that I am seeing something that nobody has said: There is a clash here. I went to engineering school, and even if (as some appear to think) I acquired no knowledge, I still learned something: a culture and I can see that it is quite different from the Open Source culture. I *know* that I will do much better bouncing my ideas off other developers than I will discussing them with my cat.
--
JRT
"works fine for me"
The question is: is this a high enough standard for programing.
I note that this was (as the hacker's credo) strongly criticized in that article from SIGPLAN Notices (that I still can't find).
The answer is NO -- unless you want Microsoft like code -- a program should be canonically correct and complete.
I offer a totally unproven theory:
1. If software has mysterious problems that you can't find.
2. If software has various things that are not correct but "WFFM"
There is a possibility that there is a correlation between #1 & #2.
I note that Microsoft is my model for the 'hacker culture'. Others may have different definitions but that is mine.
Microsoft's software (DOS & Windows) was designed by hackers that had no knowledge of of CS or Intel documentation. That is why it is such a mess (and yes I know and can discuss the details if anyone is interested).
--
JRT
Unlike Microsoft, KDE can not manage developer resources. Either somebody implements it, or he doesn't. Either it will be accepted into the CVS, or not. Either distributions ship it, or they don't.
And, BTW, I would be pretty happy to have the breadth of technology available in KDE/Qt compatible way that MS offers for Win32/MFC or for .Net. As long as it is working... Free software does not neccessarily be better than the closed alternative, as long as it is free. It just needs to be good enough.
Better software is better, obviously, but first it is important to reach a competitive level. Free software has enough licensing advantages that a functional equivalent would be a very serious competitor to any closed product, even if it is better known.
Sometimes WFM is just a shorthand for "damn - I can't reproduce that bug, and until I do,
fixing that bug will be much harder than if I *could* reproduce it. In fact, I really wish I could
reproduce it, as that would make my life much easier. I *want* to fix the bug, but that's gonna
be pretty hard to do. In the meantime, could you be ready to work with me to see if my changes
fix it for you?"