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

List:       kde-devel
Subject:    Re: Fundamental KDE Library Problem..
From:       Bernhard Rosenkraenzer <bero () redhat ! de>
Date:       2002-07-02 17:58:11
[Download RAW message or body]

On Tue, 2 Jul 2002, Matthew Tedder wrote:

>     By far the most difficult thing about KDE programming is the lack of 
> backward compatibility.

WHAT lack of backward compatibility?

Porting from KDE 2.x to KDE 3.x: Recompile, change a couple of lines in 
the code if necessary.

Porting from GNOME 1.x to GNOME 2.0: Rewrite all UI code.

Porting from Mac OS 9 to Mac OS X: Either use a compatibility layer or 
rewrite all UI code.

Windoze doesn't have this problem to the same extent (though you do have 
to rewrite UI code if you want to use XP's theme engine), but that's 
because it's stagnant, not because it's a feature.

>     Many good programmers who have been enticed by the technically superior 
> fundamentals of KDE.  However, few of those have stayed the course...  Most 
> give up as soon as they discover how frequently changes occur breaking 
> backward compatibility.  

So far, twice.
Once for real (1.x -> 2.x, which was necessary because 1.x really wasn't 
that good design-wise, though it's still years ahead of the current 
gnome), and once making a couple of mostly minor changes (2.x -> 3.x).

3.x will be around much longer than 2.x was because 2.0 was very late 
(compared to Qt 2.x), KDE 3.0 was relatively early (which is a good 
thing).

And I don't think 3.x -> 4.0 porting will be any more complicated than 2.x 
-> 3.0.

>     One of the best programmers I have ever known once determined that Open 
> Source will never effectively work on the desktop, because it's far too 
> unstable.  He meant that you can't meaningfully program for it without great 
> cost in time/money to babysit the software for the constantly changing 
> platform.  

Or you just open source the software and let others to that work for you. 
Seems to work pretty well for everything else.

>     If KDE libraries were as developmentally stable as glibc,

This simply can't be the case.
glibc is an implementation of a standard that has been around for ages. 
glibc doesn't invent new APIs or anything, it just follows what has been 
around forever.

KDE and Qt on the other hand sets the standards itself, and if something 
is broken by design, it's fixed.

If you just stay with whatever you have API-wise, you end up with 
something that just looks obsolete (take Xlib or Motif as examples) when 
other things make progress.

>     As for the article's praise of the GNOME Foundation, I totally disagree.  
> Perhaps the KDE League needs a jumpstart but putting corporate executives in 
> control of the future of KDE development would be a serious mistake. 

Exactly.

Look at GNOME 2.0 for proof - Sun pretty much killed off all 
configurability. 1.4 was preferrable in many ways (and even 
KDE 0.1 is preferable over that).

LLaP
bero

-- 
This message is provided to you under the terms outlined at
http://www.bero.org/terms.html

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]