Xdg-list digest, Vol 1 #432 - 11 msgs

[George Staikos]

On Sunday 20 July 2003 13:54, Linas Vepstas wrote:
> > 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 not a desktop tolkit. I've used it in GUI-less servers (running
> on machines that don't have X11 or kde or gnome installed on them).
> It's generic, it doesn't use or know about graphics or desktops or
> anything like that.  It just provides some nice containers and
> memory management functions & etc.

  Sure.  I didn't say it was a gui toolkit.  Anyways, you're missing the 
point.  Why should KDE, which uses C++, XPDE which is written in Kylix, 
foXdesktop which is written in C++, UDE which uses only Xlib in C (custom 
containers), EDE, or -any- other desktop have to write a compatibility layer 
from its native container set to glib and back simply because that's the 
choice du jour?  The goal is to take the parts that are common to all the 
desktops (for interoperability purposes) and share code, using common 
libraries right?  It's extremely unfair to choose the library used by one or 
two desktops, providing those a native interface to the library and no 
additional code to load, meanwhile adding these requirements elsewhere.  The 
point is to share code that everyone will use.  If I have a say, it will be 
to rewrite the library using the native containers.  Kind of defeats the 
purpose, doesn't it?  Why even bother starting then?

  You have to understand that there are fundamental reasons why there are 
multiple desktop environments.  People want choice.  They want to choose what 
their code will look like and how it is maintained.  Users want more/less 
features, more/less configurability, faster, smaller, ....  the list goes on.  
I'm sure that some of the desktops will consider even 100kb of duplicated 
code completely unacceptable given their focus.  They chose to not use Qt, 
not use glib, not use STL, or whichever other library of the day was 
available.  If you want everyone to share code, you have to be sensitive to 
this.  Notice how many libraries out there (openssl, openldap, ...) don't use 
any of these container libraries.  Granted most of them make a mess out of 
their own internal implementations, but I think they realised that using a 
third party library was just not going to work and would probably be quite 
annoying for developers.

  I could easily ask:
  - Why not use TinyQ?  - licence isn't acceptable to some
  - Why not use STL?  - some desktops don't like C++?
  - Why not use assman's IT/m? http://www.gsyc.inf.uc3m.es/~assman/libtool/
  - libUTL++?
  - glib?
  - Some other desktop's containers?
  - Linux Kernel data structures?
  - any of the other packages on freshmeat.

  What it boils down to is that you have to be very sensitive when choosing 
this.  Choosing the tools of one desktop over another to declare the common 
denominator is completely unfair, especially when they are not part of the 
common denominator.  You may happen to know glib well, but many people do 
not.  You have to broaden your view when working in the scope of a project 
like this.  I argue against all the choices I listed above.  Someone loses in 
the end, and as I said earlier, it will probably result in people simply 
rewriting it for their own purposes. (Imagine the bugs, and the lag time for 
each desktop to catch up to new versions of the specs.  We already have this 
problem with vfolders.)  Be fair.  Make everyone share the same burden with 
the base library.  It could still result in projects rewriting the library 
with their own toolkit, but at least everyone is on equal ground from the 
start.  Anything less is a farce.

(As far as I can see, the GCD in this case is C, with no external libraries.)

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