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

List:       kde-core-devel
Subject:    Re: Qt-only KDE applications (Rekall)
From:       Mike Richardson <mike () quaking ! demon ! co ! uk>
Date:       2002-01-23 10:46:42
[Download RAW message or body]

Rats, why did this have to come up on the day I'm away ....

First off, I think KDE<->QT-only cross-platform portability is a good thing, 
and anything that makes cross-platform apps consistent with the platform they 
run on is a good thing. Actually, I'd prefer a kdelibs->windoze port more 
than a Qt->KDE wrapper, although the latter would also be good.

As Shawn has repeatedly said, if apps can run on both Windows and Linux (I 
use "LInux" to cover Linux/Unix and KDE/QT) then they will reach a bigger 
audience. Since there are vastly more Windows desktops than "Linux" this has 
to be a net benefit in encouraging Windows->Linux migration - people can try 
the "Linux" app without burning their boats. Maybe they will then be 
convinced enough to go the whole way. And I think that there will be a bigger 
gain to "Linux" by better integrated apps than there will be a KDE->QT-only 
loss.


Anyway, some techie stuff - Rekall

We can build Rekall in (basically) two ways

	- QT only
	- KDE native

We do this with a wrapper library which defines a set of TKxxx classes and 
methods which map either to QT or KDE as required. But the build for each is 
distinct. We would have preferred a link-time shared library (in the sense of 
installing one of a pair of binary API compatible libraries) so that the rest 
of the app is unchanged.

But this is, I think, impossible to do. The problem is with any class that 
you use by subclassing. KMainWindow is the obvious example; you can't define 
a wrapper class which contains a pointer to a KMainWindow since then you 
can't override virtual methods, hook events, connect signals and so on (well, 
you could, but the wrapper would have to hook _everything_ in and below 
KMainWindow, and expose them as its own methods  .... but even then there 
have better be no protected variables)

I don't buy the arguments about performance overhead, I would seriously doubt 
that the app would spend a significant amount of its time inside the wrapper 
library code. I'm more sympathetic to the patch argument (ie., the one that 
says that WIndoze is the mess that it is because M$oft always stick a patch 
on top rather than fixing the fundemental problem), though saying that a 
wrapper library round QT patches QT problems is not very different from 
saying that KDE is a patch round QT to fix QT problems[*]


Last point, QT apps are more portable, and can help the 
multiple-linux-distribution problem, but I'm not quite so optimistic that it 
will help in the long run. Rekall, for instance, uses Python as a scripting 
language, so which we can provide a QT-only Rekall, it will be 
distribution-independant at the GUI level, but not necessarily when it comes 
to interfacing to Python <rant>RedHat: why (a) does 7.2 ship with Python 
1.5.2 as the "default" python and (b) RedHat+Mandrake why the **** does KDE 
have to be installed with a /usr prefix and not /opt/kde - if Suse would just 
ship with sensible RPM file names, all in one directory, i'd probably 
switch</rant>




[*] But don't, as someone suggested, drop KConfig for QSettings - QSettings 
is a poor shadow of KConfig

Regards
Mike
[prev in list] [next in list] [prev in thread] [next in thread]