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

[Mike Hearn]

On Mon, 2003-07-21 at 14:56, George Staikos wrote:
>   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.

It is trivial yes, but reinventing the structures each time is still
effort that could be better spent elsewhere. Also each time you reinvent
the linked list, people can make mistakes. I fixed a couple of linked
list bugs in the RPC runtime of Wine the other day, that could easily
have been avoided if people weren't constantly writing new iteration
code, copying and pasting it all over the place etc.

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

OK. That is good. I was thinking for a moment you wanted to restrict
usage of it entirely.

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

Good for you. However, most people don't do 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.

I fail to see the resource usage problem. It will be loaded, at maximum,
once, as the linker will ensure it is shared.

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

No, I said simply "more unfair". Qt for libs - licensing issues, come
on, you know that.

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

If you're trying to draw a connection between badly written code and
glib, I don't see it. Anybody can abuse libraries. I'm sorry you have to
maintain arts, it does sound horrid, but it seems irrelevant to the
matter at hand. Probably, you would not need to maintain these
libraries, as they'd be shared infrastructure.

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

The full list of data types can be found here:
http://developer.gnome.org/doc/API/2.0/glib/glib-data-types.html

Very few of them would probably be in an interface. If internal use only
isn't a problem, then really the matter boils down to, are these data
types allowed in an interface or not?

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

I personally am not really involved in the matter. I've used glib in my
own (non-gui) apps, and it saved me time. I'm probably not going to be
writing these libraries. I am just trying to understand your objections.

I still don't understand why the usage of glib in an interface causes
you difficulty, or more pain that not having it used. You will want to
wrap it into Qt anyway, so it makes sense to use a library and set of
interfaces designed with that in mind.

I'm not sure what you mean by "my" desktop. I don't work on Gnome, I'm
just an observer here.

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

Most that I've met prefer it to raw C. In the absence of it, they tend
to invent their own such utility libraries.

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

You would have to back up this claim with some pretty good arguments.
Like I said, I've already fixed several trivial bugs related to data
structures in Wine that could have been avoided if we weren't tied to
using only Win32 as an API.

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

Performance penalties are nearly non-existant. libglib-2.0.so.0.200.1 is
425k. It's loaded once, and all symbols are lazy linked. The space
savings gained by reusing code is almost always worth it, that's why
dynamic linkage is used so much. Function naming style should not be a
big problem, only the person wrapping it has to use that style (assuming
they wrap it into InterCaps). I don't know why you think the code is
"inferior". I'd note that the Xr vector APIs, aka Cairo, use
underline_style, because the developers believe it's easy to read. Parts
of the STL use that style, too, iirc.

>    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 personally as a developer would not have any such problems. I can't
speak for others. But the GPL license is unacceptable, because it would
mean that the given library is not usable by proprietary software
without license fees to TrollTech. Qt is also a lot larger than glib.

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

If you are resolved to rewrite every library produced using Qt, then I
don't see why you've taken an interest in this conversation anyway. You
would clearly want to rewrite, even if only pure C was used, making the
goal of shared code meaningless.

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

Please drop the unhelpful comparisons. As far as I'm aware, all the
standards in use by free desktops today, are either de facto standards
such as X11, or have been hammered out in public along with the
co-operation of KDE developers, right here in these forums.

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

Of course they do. You've turned this from a simple technical issue of
whether to allow library developers to use a utility library into a
poltical issue of "desktop independance and choice".

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

It's simply a matter of saving time. As a practical example Jody pointed
out that KSpreads MS Excel importers would be better if they used a
shared library that has had a lot of work put into it. If KSpread
doesn't use that library, then it'll either recreate a lot of work, or
have worse importers. That's a shame.

If you are determined rewrite the libraries, then I guess I don't know
how to convince you otherwise. Meanwhile I hope other desktops will try
and share code, despite their differences.

thanks -mike