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

List:       kde-core-devel
Subject:    Re: What to do after 2.2?
From:       Simon Hausmann <hausmann () kde ! org>
Date:       2001-07-14 15:37:25
[Download RAW message or body]

On Sat, Jul 14, 2001 at 09:00:40PM +0200, Marc Mutz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Friday 13 July 2001 16:25, Lars Knoll wrote:
> <snip>
> > Binary compatibility would be broken by such a step anyway, and is
> > actually rather unimportant. Source compatibility is what matters,
> > and I'm pretty confident we can do such a move without breaking
> > source compatibility in more than one or two places.
> <snip>
> 
> Actually, I think we should break SC at quite a few places:
> (some things I remember in random order)
> 
> - - QRegExp3 is significantly different from QRegExp2 and in a way that 
> is uncheckable by a compiler (regexp syntax). Also, QRegExp's are used 
> in quite a few places implicitely. E.g. this small, innocoent-looking 
> line will break:
> 
> QString str("Hello (World)!");
> str.replace("(World)", "World");
> 
> because arg0 or QString::replace is actually a QRegExp....
> 
> - - KRegExp should be nuked in favour of QRegExp3.
> 
> - - KProcess should be nuked in favour of QProcess
> (Qt multi-threading should also at least be be considered though I 
> personally don't see a need for it)
> 
> - - I don't know much about this stuff, but it seems KDE uses a custom 
> libloader where we should use Qt3's for KDE3 instead.

We better stay with libltdl.
 
> - - KDE's KPart's need to be ported to QLibrary, QPluginManager et al.
> 
> - - KDE's KConfig should be replaced by QSettings

Nope. QSettings does not support KStandardDirs. Long live KConfig! :)
 
> - - ...
> 
> At least the KPart and KConfig changes should be pretty deep if we want 
> to make use of the full Qt3 potential in that area. And they affect a 
> very large part of the core source code base.
 
All these changes are not necessary at all to run KDE based on Qt3.
If we want to implement all these then it

  a) takes a lot of time

  b) pisses off third party developers because we break SC

It might be technically interesting to make some of these changes, but IMHO
the disadvantage are bigger than the advantages. However if we go for a straight
source compatible port then we 

  a) can do it fast

  b) gain the i18n improvements for free

  c) have a mostly SC kdelibs

Just my 0.02 cents.

Bye,
 Simon

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