glib in kdesupport: yes or no?

[Adam Treat]

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
> another.
<snip>
... 
<snip>
> 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).
<snip>

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 
infrastructure?

Cheers,

Adam