Xdg-list digest, Vol 1 #432 - 11 msgs
staikos at kde.org
Mon Jul 21 08:27:19 EEST 2003
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/
- 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.)
KDE Developer http://www.kde.org/
Staikos Computing Services Inc. http://www.staikos.net/
More information about the xdg