[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Next generation of KOrganizer / Call for help: (fwd)
From:       Bavo De Ridder <bavo () ace ! ulyssis ! student ! kuleuven ! ac ! be>
Date:       1999-05-05 14:24:09
[Download RAW message or body]

On Wed, 05 May 1999, Sirtaj Singh Kang wrote:
>On Wed, 5 May 1999, Bavo De Ridder wrote:
>[snip]
>> 
>> 1) Widgets both in the KDE libs and Qt, no single based source, the industry
>> doesn't like not having a single codebase for this kind of fundamental
>> components
>
>How do you propose to fix this? Make KDE libs part of Qt? :) Does this
>"industry" you speak of suggest a solution?
>

Make KDE UI lib a testbed for new widgets. 

>Most KDE widgets that are duplicated in Qt are around because no Qt
>equivalent existed at the time. As Arnt once said, Qt might make up to 60%
>of our UI work redundant, but we need it when we need it and no later.
>

Yes, we need them now and not later. Put them in KDE UI. After some time they
should be offered to Troll for inclusion in the regular Qt. 

>> 2) non-qt widgets often don't use the same specifications or conventions
>> as their qt nephews.  3) the "write-code-as-it-is-needed" gave us a
>> bunch of conventions, often not compatible. This is something one can
>> clearly see in the following projects:  kab (database usage), kmail (no
>> kde-wide uniform messaging api), ... 
>
>> to commercial vendors and companies interested in Linux. Don't forget: Corel,
>
>We will be more interested in these commercial vendors and companies when
>they give us some incentive to do it their way. "We will base our next
>closed source app on your libraries" is not the right kind of incentive.
>Donating updated or nicely written code is the right kind of incentive.
>

If that was reality, it would be nice. However, it is not reality. A lot has
been said about open source and the lot, currently reality is still different.
Or do you think IBM will make the source of DB2 open?

>Like you said, standards are required, but in a project like ours, code
>has to be available to be seen now, because otherwise you cannot employ
>the effort of volunteers. That is why things need to be done iteratively; 
>we do the best we can with what we have until someone comes up with
>something better. Nothing is so sacred that we say "oh but we can't change
>that now".
>

Yes, but you should have least have some whitepapers explaining the main goals,
base frameworks, the layering (if available), ... this doesn't has to be 1000+
pages.

>> As a computer scientist I would at expect some factory classes in the KDE base
>> libaries, however, almost none are available, ... almost no usage of patterns,
>> no frameworks for the most common application types,  ...
>
>???? No patterns? Gee, let's see: 
>
>KApp..::getConfig			Factory

It may look like a factory, but it isn't. This looks more like the Singleton
pattern to me.

>kapp					Singleton

yep

><everywhere>				Iterator
>signals/slots				Observer
>standard programming practice		Adapter
>khtml					Composite
>Use of Qt implicitly shared objects	Flyweight
>

You only mentioned the most common patterns. I won't go into this any deeper, I
mostly critized the lack of frameworks.

>do you want more? I haven't even started on any of the apps yet. "Usage of
>patterns" doesn't mean calling methods or classes things like "Mediator"
>or "Strategy" or "ChainOfCommand", but to actually apply these when
>writing programs. And most good programmers do it without even thinking
>about which pattern they are applying.
>
>As for frameworks etc; well, I think it has been said before - if you have
>a better way, please contribute. Untrained programmers like me (I don't
>have any tertiary degree) depend on computer scientists to show us how
>it's done. ;)
>
>One thing I do agree about is a lack of general coding standards, but you
>have to remember that many people who have joined the project are new
>programmers, and it is the job of more experienced programmers to help
>them along. Especially if the programmers are new to OO design - finding
>good abstractions is hard till you get the hang of it.

Yes, but it shouldn't be an excuse for not-so-good code. I can remember the
days where KToolbar crashed when 2 or less buttons where added. After the
bugfix it only crashed when only 1 button was inserted. The second bugfix made
it only crash when no buttons where inserted.

If someone is really offended by what I wrote, blaim it on my bad english. What
I really miss is the following:

	1) white papers
	2) common frameworks
	3) standards
	4) a trusted, well known and a good constructed base libary set.

Point 3 is less important until point 1 and 2 have been addressed. The only
thing I find more or less difficult are the standards. How should standards be
made in an opensource movement where nobody should be forced into something?
Perhaps a designated taskgroup for each standard. Why not founding a taskgroup
for the construction of a KDE Database standard? This group should have an
openmailinglist (for the world) a closed mailinglist (for internal talks) and a
webpage containing a few white papers, ... This will also take the load of this
list (kde-devel). After a few weeks a fairly good specification and a
prototypical implementation should be available.


BDR

[prev in list] [next in list] [prev in thread] [next in thread]