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

[Mike Hearn]

On Mon, 2003-07-21 at 06:27, 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? 

Because the effort required to wrap the occasional GList (which is an
extremely trivial structure, I might add) is low, whereas the effort
required to constantly reinvent the wheel is high. Resources are
limited, conserving them makes sense.

Besides, I see few libraries out there that use glib specific structures
as parts of their interface, it's normally used internally. I can't
think of a good reason to deny people the usage of glib internally.

>   It's extremely unfair to choose the library used by one or 
> two desktops, 

... and also X, and various random gnu programs, as well as libraries
that have nothing to do with the desktop, like the GNU Triangulated
Surface Library.

> providing those a native interface to the library and no 
> additional code to load, meanwhile adding these requirements elsewhere.  

Why? In free software land computing resources are cheap compared to
human resources. Given that so much stuff uses glib already that it will
probably be loaded in memory anyway, and therefore shared, I can't see
this being a huge deal. Forcing *everybody* to the lowest common
denominator (when C is already pretty low) seems more unfair.

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

So you ARE willing to veto stuff based purely on which libraries it
links against? The containers stuff is a small and ultimately trivial
part of glib, if you don't use them, people will simply invent their own
linked list structures, which is a pointless waste of time. If they do
use them, it's still just a linked list, which you would have to have
dealt with anyway.

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

That is entirely irrelevant, we are not debating user choice of desktop,
not even coding style. It's ultimately something that will either save
people time, or create lots of new work and waste.

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

Then they will face a hard choice, won't they. Duplicate the shared
library using whatever idioms they prefer, or "duplicate" some structs
and shared library. Whichever they choose, not being flexible over it
will cause them to "duplicate" something.

> 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 think most developers would agree that using a library which has clean
internal code and is easy to maintain, takes precedance over not using a
utility library.

>   I could easily ask:
>   - Why not use TinyQ?  - licence isn't acceptable to some

Never heard of it myself. Nothing out there uses it today, might be
another one.

>   - Why not use STL?  - some desktops don't like C++?

C++/STL has portability issues, AFAIK, and is harder to bind into other
languages.

Only two of those, glib and the STL, would seem to be widely used. I
would note that wrapping C++/STL libraries into C is perfectly possible,
and I've seen it done before. However, it boils down to what the
developer of the library in question prefers to write in.

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

I would argue that glib, is not "the tools of one desktop", it's used so
widely these days, it's merely "a tool". Given the usage of  it in XFree
and I believe the GNU project was thinking of using it in its utilities,
it seems to be more a question of politics and the G letter than
anything else.

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

I would claim the opposite is true. Forcing people to abandon useful
tools that can increase the quality of written code simply in order to
make everybody work harder would be farce. I'd note that glib based
stuff is no harder to wrap into C than something using custom idioms.


What you basically seem to be saying, is this:

- I don't want to use libraries that link with glib, because:
	- It is "another desktops toolkit"
	- I fear linking against another library to use certain data
	  structures, like linked lists, or unicode strings.
	- I feel it is not fair that others who work in the native
	  language of said library would not have to wrap it. If I have
	  to do some work, so should everybody else.

- I will rewrite any library in "pure" C (but still using glibc I would
  guess), using custom containers and data structures (as basic C does
  not provide such things) anyway, no matter what other people think.
  You don't want to see that, do you, so please agree with me.


I can't understand or agree with any of those points, sorry.