[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:       Sirtaj Singh Kang <ssk () physics ! unimelb ! edu ! au>
Date:       1999-05-05 13:12:56
[Download RAW message or body]


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?

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.

> 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.

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".

> 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
kapp					Singleton
<everywhere>				Iterator
signals/slots				Observer
standard programming practice		Adapter
khtml					Composite
Use of Qt implicitly shared objects	Flyweight

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.

My humble attempt at this was the C++ tips for new programmers, which I
have on my developers centre page. But I hope to write more documentation
when I find some time.

-Taj.

Sirtaj S. Kang       taj@kde.org         ssk@physics.unimelb.edu.au
Univ of Melbourne	
			"I'm a commercial operating system."
				-Doug Michels (CEO SCO)

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