glib in kdesupport: yes or no?
staikos at kde.org
Mon Mar 10 01:58:14 GMT 2003
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
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
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
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:
> 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
> 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
> 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:
> (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
> 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
> 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
> 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
More information about the kde-core-devel