glib in kdesupport: yes or no?

[Havoc Pennington]

Hi,

Here is my standard .02 on this issue -

Choice vs. Fragmentation
===

FWIW, in my FOSDEM talk and other presentations about freedesktop.org
I find it useful to describe interoperability as follows:

 - the applications should be orthogonal to the user environment

or perhaps another way to put it:

 - choice is good, platform fragmentation is bad

Platform fragmentation exists when a user must choose one bundle of
apps vs. another bundle of apps - they are forced to use IE, not
Netscape, when using Windows. Choice exists when a user can choose any
app.

Or put in terms of developers: fragmentation exists when a developer
must choose one bundle of users or another bundle of users. Choice
exists when a developer can choose either Qt or GTK+ (or Kylix, or
whatever) but still get access to all users.

Fragmentation means that if Linux reaches critical mass on the desktop
with 6 million users (making up a number), then either GNOME or KDE
must get to 6 million. Choice means that GNOME and KDE combined must
get to 6 million.

So, I would suggest that it's useful to have both GNOME and KDE when
having both offers choice, and harmful to have both when that means
fragmentation.

Not all or nothing
===

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.

Wrappers of wrappers of wrappers are of course silly (I love schemes
to do things like run GGI over GDK over Qt over SDL...) 
and the solution to that is a hub-and-spoke design rather than a
"rat's nest" design, here is a picture:

 http://people.redhat.com/~hp/proposal/ratsnest.png
 http://people.redhat.com/~hp/proposal/hub.png
 (this is from http://people.redhat.com/~hp/runtime.html)

Those pictures are about a grandiose and star trek shared runtime
scheme, but the same thing applies to simpler stuff such as
fontconfig; we have the one fontconfig layer and map Qt, GTK, etc.,
APIs to that, we don't have mappings between Qt<->GTK font systems
directly.

Of course for many simple problems a spec is good enough, you don't
even need shared implementation.

Finite problem
===

At this point I think the list of areas where we need to have
interoperability and shared implementation/specs is fairly finite and
fairly well-known. I also think there are clear, feasible courses of
action for every area: MIME system, DND/clipboard types, message bus, 
themes, help system, etc.

The one area I still find very hard to come up with an answer for is
the kioslave/gnome-vfs mess. Well, the answer is clear (a robust
shared implementation), it's just Hard. Unfortunately, this is an area
where I think interoperability is especially important and not sharing
implementation has high user impact. Sucks.

But if we can solve everything except vfs, I'm confident we'll solve
the vfs thing someday also.

Docs and specs good
===

Over the long term, we need to keep the interface between applications
and the runtime environment compatible. This means they need to be
well-specified and well-understood. Most arguments that simply
standardizing on an implementation is 'faster' hinge on the fact that
by picking an implementation you can cut corners and not really
document/specify/discuss things. Well, we shouldn't cut those corners
anyhow.

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.

Or look at Windows - Microsoft has itself reimplemented large bits of
the toolkit over time. i.e. future progress means you have to be able
to keep compatibility while evolving the API/implementation.

Basic point is, even if only one of GNOME/KDE existed, you would still
have this huge need to be able to interoperate with the desktop
without sharing all its implementation, if only so you could evolve
over time and be interoperable *with your own stuff*. In fact one
could argue this is the whole point of COM on Windows.

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

However, if you don't, there is still value in ensuring that the apps
interoperate - same help system, font system, MIME system,
etc. i.e. even if we offer *choice* of user interface, we should avoid
*fragmentation* of platform.

I don't have a single problem with choice of user interface; no one
has ever minded that Linux has 30 window managers and 10 shells and so
on available. Everyone *likes* being able to choose between several
different mail clients. People *like* choice.

So I don't think it's clearly right or wrong to merge KDE/GNOME.  That
just comes down to whether the people involved have the same UI ideas
and want to work on the same code, or don't. It makes total sense to
me to have different desktop shell thingies for different
tastes/audiences, if they are truly interestingly different.

However, IMHO, it's essential to ensure that we offer choice, not
fragmentation.

Havoc