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

[George]

On Mon, Jul 21, 2003 at 01:27:19AM -0400, George Staikos wrote:
>   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?

This is such a nice flamewar I can't resist.  Plus the above paragraph makes
absolutely no sense whatsoever.

Let's take it logically.  You say it's unfair because other desktops have to
write wrapers around glib.  OK.  So if its some hand rolled container, they
don't have to write wrappers?  No, it's exactly the same situation.  So I
don't see where fairness comes in at all?  You want to make it so that
GNOME/GTK+ developers also have to wrap and get the same speed hit.  But
IMO, most such developers would just use those home made pure C containers
or whatnot directly, thus getting again no speed hit.  Damnit, how would we
convince those pesky C programmers to make an O(n) wrapper.

Unless there is some code that returns a HUGE list where wrapping it really
does do add more then a few nanoseconds, then there is absolutely no fairness
question to begin with.  I can't see a case where this would be an issue
anyway.  If you have something like that your interface is likely wrong.

I suppose that this is mostly a problem since glib is named glib and not
'hlib'.  But let's note that glibc also starts with a 'g'.  Hmmm.

If you are already willing to assume that glib is used internally, and thus
is installed, then I can't see what is lost by using it perhaps in the
interface.  Granted, if you want to use glib just for GList's then it may
be an overkill, but glib is a lot more then GList's.

> 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.

Qt is not a container library
STL is not a third party library any more then libc is a third party library

and there are new libraries being written that do use glib.  I would more
attribute the non-use of glib in libraries to the relative newness of glib.

So from the above paragraph you think it's better to have a mess of the
internal implementation especially for something security related.  Good
thinking.  The less understandable the security related libraries are, the
less bugs/exploits right?  Or was that more?  Hmmm.

>   I could easily ask:
>   - Why not use TinyQ?  - licence isn't acceptable to some
>   - Why not use STL?  - some desktops don't like C++?

STL is not usable from C (or most other languages) very easily.  glib on the
other hand is usable from any other language just exactly in the same way as
a pure C interface.  Since most likely if I was writing a pure C interface
I'd just write it in the same way that glib does it, only it would have more
bugs, wouldn't do as much and would have no documentation.

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

As a mathematitian I must disagree with your definition of GCD, and your
usage of it.

George

-- 
George <jirka at 5z.com>
   Beat on the brat, beat on the brat, beat on the brat, with a baseball bat.
                       -- Ramones