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

[George Staikos]

On Monday 21 July 2003 04:30, Mike Hearn wrote:
> 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.

  If the glib is so trivial, the implementing such structures again is also 
trivial.  Come on, I've done it dozens of times.  I know what the effort is 
and it's minor.

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

  We're talking about the interface here.  If you think glib should be allowed 
internally, so should any other library that developers of this software want 
to use that is licence compatible.

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

   You just said that it's trivial to re-implement.  I ran a system without 
glib for quite some time to prove it was possible.  Computing resources are 
-very- important to our users, and your attitude is atrocious regarding this.  
We spend very much time on optimisation.  You either don't care about our own 
human resources as long as it saves you perceived resources, or you see no 
value in the work we do.

> this being a huge deal. Forcing *everybody* to the lowest common
> denominator (when C is already pretty low) seems more unfair.

   Great, so you accept that other options are also fair.  Proposal: Qt based 
libraries as part of the freedesktop spec.  Oh doesn't sound so good anymore?

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

   In the scope of KDE, I'll do everything I can.  I am stuck maintaining the 
crap in aRts now, full of STL, glib, and Qt.  It's a nightmare.  I am not 
responsible for a single bit of it, but the developers have just written a 
mess of code with those three libraries and then dumped it in CVS.  I am sick 
of maintaining this stuff and I basically convert what I can to Qt as I 
encounter 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

   What other part do you intend to use exactly?

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

   It took you far longer to write this email than it would take to make a 
linked list.

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

   Yes we are.  The interface is about coding style, and coding style saves 
-me- time.  I am a user of this stuff.  You want to save yourself 20 minutes 
at the expense of 10 other people's 20 minutes each.  Your desktop's X kb of 
memory added vs all the other desktops X kb of memory added.  How clever.

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

  Not all developers agree that glib is clean or easy to maintain.

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

   I argue that glib decreases the quality of code.  Can you call me wrong?  
No, you can disagree, that's all.

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

   No, because it incurs performance penalties for many, lengthens development 
time, and_makes_us_maintain_ugly_and_inferior_code.

> 	- I fear linking against another library to use certain data
> 	  structures, like linked lists, or unicode strings.

   Considering we already link to several libraries that do these things.

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

   Correct.  You would not accept if I wrote such a library in Qt and required 
every desktop to link in Qt, even if it was used internally only so GPL was 
acceptable.  Be honest.

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

   No, I would personally rewrite them in the native toolkit in the case of 
Qt.  Time permitting.  Shouldn't be hard, according to your statement above.  
It just results in a fork.  Fork at the beginning of the project, that's a 
good sign.

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

   Clearly.

   My views on this are clear, and I really don't intend to waste more time 
arguing this.  If you can't see that the purpose of something like 
freedesktop is to provide standards, and secondarily implementations that all 
desktops will want to use, then you are indeed missing the point.  Declaring 
standards seems to be a trend amongst certain organisations lately.  Very 
reminiscent of what people complain about Microsoft doing.  At least some 
groups have the choice to ignore the "standards" though.  If you want 
everyone to cooperate, you have to be sensitive to all of their views, all of 
their requirements, and understanding of their points of view.  I personally 
want every desktop to be on an equal footing, and every user to be able to 
choose which one he wants to use.  Not everyone wants this it seems.  The 
most ironic trend in free software seems to be "free, as long as it agrees 
with my point of view."  I don't buy that.  If it's free, I can choose to use 
it or not to use it, or do something completely different.  Since I am free 
to choose, if you want me to use your stuff (do you even write any of this 
personally?), you have to -convince- me.  Convincing me, in this case, well I 
have already outlined what I believe is fair to use.  Otherwise I say fork 
away.  (Wow, I don't think I've ever heard of forking projects before they 
are even released.  That's a great sign.)

   This thread is getting far out of control, and I have code to write.  As I 
said, my point of view should be perfectly clear.  There's no point wasting 
more time on this.

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