glib in kdesupport: yes or no?
manyoso at yahoo.com
Sun Mar 9 20:21:50 GMT 2003
And my 1 cent :-)
We have been seeing quite a bit of posts regarding the merging of GNOME and
KDE in various ways. While I believe that some integration and shared layers
are appropriate, I would like to point out that this will not work for
everything so we might just as well understand that now. KDE and GNOME
share many similar philosophies and motivations and we also *differ* in many
*fundamental* ways. It is all well and good to eliminate the superficial
differences, but fundamental incompatibilities will always remain. We have
one particularly glaring difference (see below).
> This is not an all-or-nothing thing. For example, with fontconfig, I
> have the same list of fonts available in both GTK and Qt apps. That's
> a big win for users, independent of whether or not you solve any other
> problem. Most interoperability or code-sharing opportunities are like
> that; they are a big win by themselves.
> It's clear that things like the MIME system, or D-BUS, or shared
> accessibility setup, would similarly be standalone big wins that are
> worth doing by themselves, whether you can do other stuff or not.
> How to implement
> As both GTK+ and Qt are cross-platform toolkits, and we have promising
> developments such as D-BUS, there's plenty of reason to believe that
> we can avoid fragmentation while still offering choice.
Ok, so here is the crux of the problem. I assume that all of your shared
technologies will not have a Qt dependency. The sticking point to understand
is that Qt is not just a toolkit to KDE. It is the chief underlying basis
for KDE and (hopefully) will remain that way. IMO, the success that KDE has
achieved can not be separated from the initial choice to use Qt. From what I
can see of your arguments and ideas you see Qt as just a toolkit to be
marginalized. The infrastructure that KDE has developed using Qt, you see as
an obstacle to sharing technologies across GNOME and KDE.
> Multiple toolkits will always exist
> One reason we shouldn't cut corners is that WINE, VCL (OpenOffice),
> XUL (Mozilla), and all this type of thing will always exist. Say we
> succeed on the desktop; people are not always going to do native ports
> of apps, they are going to use some Windows compat framework like
> WINE. The large number of apps using GTK/Qt are not going away. Some
> people will use plain Qt or plain GTK instead of the KDE/GNOME layers.
> There are huge legacy codebases out there that use custom toolkits.
> And even for apps that mostly use the native APIs, there are a
> thousand reasons why they sometimes need to reimplement one bit or
> UI unification?
> To me whether GNOME and KDE should "merge" hinges on the question of
> UI unification. Say you merge the human interface guidelines and
> general approach/goals. Then at that point you may as well start
> merging implementation (say porting GTK+ to Qt or vice-versa).
If you and the rest of the GNOME developers are not willing to use Qt in any
of the shared infrastructure then I see no hope that the two projects will
achieve any large amount of integration. I believe that most KDE developers
see Qt as technologically superior to the GNOME counterparts and I don't see
any good reason to start rewriting the KDE infrastructure and removing Qt.
IMHO, it is too much work and would only result in a KDE becoming something
much less and completely different than what it currently is (something I
happen to like very much).
This is how I view the whole glib issue... It seems that some are interested
in rewriting our infrastructure without Qt for non-technical reasons like
licensing or portability (insert reason) and these arguments just do not hold
water for me. arts is just the first piece to go and then it's going to be
some other large piece where we need some shared tool and everyone will trot
out the 'can't use Qt because of blah' issue.
I don't see any technical reason for not using Qt and the functionality it
encompasses. arts today and then what tomorrow? ... or are the GNOME
developers going to allow us the use of Qt at all in any of this shared
More information about the kde-core-devel