glib in kdesupport: yes or no?

[George Staikos]

Hi Havoc,

  I fully agree that choice and interoperability are far preferable to 
fragmentation.  Believe it or not, I do agree that pkg-config is in general a 
good thing.  What I don't agree with, however, are the approaches and 
implementations we see presently.

  1) Communication, here in The Internet Age, gets an F.  Most KDE developers 
have never even heard about DBUS, at least not until this past week.  How do 
you expect people to accept such things if they are left out of it until the 
last minute?  These hundreds of developers are being asked to change the 
foundation of the core of their system to code not written by them, not 
designed by them.

   1b) This "system" is a system developed by hundreds of individuals, 99% in 
their spare time to suit their own purposes.  There is no governing body, no 
pay-cheque.  No-one can impose changes or regulations on these people.  Even 
if you try, these people will surely revolt and relocate [fork] the project.  
This is no small proposal.

   2) Implementation issues.  At the present time, from what I have seen 
personally and what has been conveyed to me by others, there are problems 
with the existing implementations.  For instance, the conversion of so many 
libraries to pkg-config from bin/foo-config can force people to update large 
numbers of their packages - in some cases I suspect most of the base system - 
just to install new KDE/Gnome releases that will depend on it.  This of 
course assumes that we don't duplicate all the pkg-config checks for 
non-pkg-config systems, which of course defeats the whole purpose and begs 
the question "why use it?"  This loss of compatibility reminds me of g*c 
2.96.

   3) Control.  When the desktop begins to rely on external libraries, the 
developers start to lose control over the system.  We have severe problems 
with this already.  Example: OpenSSL - breaks binary compatibility every 
second release, and source compatibility regularly as well.  We are at the 
whim of the people controlling the common elements.  Conversely, we don't 
want everyone who uses the libraries with their fingers all over it.  Quite 
frankly I've seen more bad code than I have good code.  (I am guilty of some 
of that bad code too, of course.)  Exactly how is this supposed to be 
administrated, especially considering that KDE - arguably the largest user of 
this technology if adopted - has no real budget or steady developers.  Even 
if 

   4) Containment.  One of the most annoying things about installing software 
is having to search all over for dependent packages.  KDE has generally kept 
these at a minimum, and in fact where we have them, they are often optional.  
I can't say the same for other projects.  I'm not sure that I want to give 
this up, and I am quite certain that other KDE developers would agree with 
me.  Perhaps one solution (but please, this is just a proposal and must be 
discussed thoroughly with all parties involved) is to package up all of these 
components as freedesktop.tar.gz.  This could include vfolder, pkg-config, 
etc.  This suits our purposes, but would probably irritate those who only 
want parts of it.  Not my concern.  I will not be pleased if I have to 
download 10 -other- source packages to install KDE on my minimal Linux 
install.  I don't have to do that right now.

   5) Wrappers.  In the end, someone will be using wrappers.  I object to 
having to obsolete existing and working C++ code to use C code simply because 
that's the lowest common denominator.  KDE is fundamentally a C++ desktop and 
as such we want to use the power of C++.  Compiling C code with a C++ 
compiler just gives us the inefficiencies of the C++ compiler of the day, 
with the loss of power that was available.  Are the other desktops prepared 
to accept C++ as a core requirement, and use C wrappers to the C++ code?  Or 
is KDE to be the one to bear the burden of wrapping C code with C++ to fit 
the development model?  Will we even have to use C# backend code at some 
point?


   Standardization and sharing technology are noble goals indeed.  I do infact 
support this.  I do not support the means to this end right now.  I need 
answers, procedure and compromise, and I think the rest of the desktop 
developers need this as well; KDE, Gnome, XPDE, and more.

   I sincerely hope that we can discuss these issues more at OLS and perhaps 
even come to some agreements.


On Sunday 09 March 2003 18:59, Havoc Pennington wrote:
> 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

-- 

George Staikos