next level of freedesktop.org

[George Staikos]

As Havoc said, this is something he would rather deal with later.  However I 
want to put forth this bit of information from the point of view of a 
developer who will have to use freedesktop packages.  Just consider this for 
the future when the time comes to really answer these questions.

On Thursday 17 July 2003 13:45, Mike Hearn wrote:
> >    The g has no stigma problems.  The problem is having 3-4 different
> > implementations of each type of container linked into apps, and even
> > worse, having apps that use all those containers internally.
>
> Well, I can think of only 3 - Qt, STL and glib (assuming we stay in the
> bounds of C and C++). I expect there are more, but those are the most
> popular.

   There are very many more, as some libraries use their own toolkits 
internally already.  I touch code in all areas of KDE, and I wrote some of 
the code that had to interface with third party libraries using their 
toolkits (or containers or whatever you want to call them - it doesn't change 
what they are).  I think I am qualified to speak on this topic as someone who 
will be affected by it as well.

> > The common
> > libraries that use it, should use it internally and provide C primitives
> > in the public interface.  Then each desktop can wrap this in their choice
> > of toolkit if desired.  It's not fair to make all desktops use one
> > desktop's toolkit.
>
> glib is no a toolkit than STL is a toolkit. I can't think of a
> compelling reason why exposing a GList in a function prototype would
> cause difficulty, no more than a C++ lib exposing a std::string would
> cause difficulty. At some point if you don't want the API exposed, it
> must be wrapped into another one, the exact underlying API would to me
> make little difference.

   I don't think -anyone- wants to have something like STL exposed in the API.  
In any case.  Writing O(n) code to convert GList->{QPtrList,std::,...} etc 
would be:
a) unfairly slow
b) annoying because other developers would have to learn all the details of 
GLib
c) more time consuming to implement

   So you say, big deal, use GLib whenever you use data types coming from 
these libraries.  Well first, the idea is to slowly grow a common base, 
correct?  So slowly more and more of *.desktop != Gnome has to convert their 
code to GLib.  Well, those desktops explicitly made a decision to -not- use 
GLib.  You are forcing them to do something they did not want to do to begin 
with.  Oh, or they could suffer the consequences of longer development time, 
slower code, more messy code, bigger binaries, and a requirement to learn a 
new container set.

   "Well, this is all just FUD/suspicion then!"  KDE has experience with this.  
It is painful!  We had a long debate because a major module in KDE decided 
that they wanted to use GLib, and not only their internal copy, but move to 
an external dependency.  My claim: "You do not maintain your code, you don't 
even need GLib because you already use STL and Qt, and we don't want to have 
to maintain this."  Their claim: "We will fix our bugs and it's our code."  
Now, do you want a link to the bugzilla reports to see what has happened to 
the most unstable part of KDE?  I am not pleased that I have spent so much 
time trying to understand and fix this stuff, but no-one else is willing to 
touch it.  It is for this reason that we have coding standards, and GLib (and 
STL) don't fit in.  The last thing we need is to tell all the volunteer 
programmers (yes KDE has only a few programmers who are paid part-time to 
work on KDE, myself not included) that the project they agreed with and 
signed up for will now require them to learn and work with another entire 
container set.

   Note: It took 10,000 lines of C++ to encapsulate OpenSSL and get it into a 
usable form for KDE, hiding away the grotesque API.  That's really sad, and 
what's worse, they keep breaking BC anyways.

   The goal is to get all desktops to agree to this, and as Havoc already 
knows, glib is a huge sticking point.  You can't force the desktop groups to 
accept this.  Unless you intend to develop, maintain, and support the code 
for all these platforms, under their deadlines, coding standards, financial 
arrangements, and quality control standards, you have to find a real common 
denominator.  I think you will find that a primitive C interface is the only 
one.

-- 
George Staikos
KDE Developer				http://www.kde.org/
Staikos Computing Services Inc.		http://www.staikos.net/