next level of freedesktop.org

[Mike Hearn]

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

>    If glib has to be required, then it should at least be a sufficiently old 
> version that it is already available in binary form for all the platforms 
> that these desktops support without requiring extensive hunting.  

How extensive is extensive? And if there is a desktop platform that the
various groups adhere to, then surely no hunting would be required for
normal users.

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

thanks -mike