[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: pkg-config, glib2 etc.
From:       Mosfet <dan.duley () verizon ! net>
Date:       2003-03-17 3:09:15
[Download RAW message or body]


On Sunday 16 March 2003 8:22 pm, Pablo Saratxaga wrote:
> Kaixo!
>
> On Sun, Mar 16, 2003 at 03:42:49PM -0600, Mosfet wrote:
...snip...
> Yes, because Qt depends on libqt...
> but what if they were a "libfoo" with some of the functions on Qt
> so you could use them without having a dependency on the Qt toolkit?
>

This is an interesting point for other reasons... I've seen a lot of KDE/Qt 
developers wishing they could use the Qt Template Library when writing non-Qt 
C++ applications. Some have even gone so far as making mini-Qt's with just 
the QTL. The GPL isn't really the problem here, people just want to use the 
templates but not the entire GUI toolkit.

I wonder if Qt would be willing to release these as a separate library under 
the LGPL? I think a lot of people would like to use it. People have attempted 
making packages with just this but they don't go anywhere without official 
support.

Anyways, back to the point.

> > It worries me that the standards being pushed by freedesktop.org went
> > from specifications that people can implement efficently for either
> > desktop to requiring more and more GTK/Gnome depedencies.
>
> libglib isn't GTK/Gnome.
>
> libglib is just some extensions to basic libc, some functions that it would
> habe been nice to have in standard libc from the beginning, but aren't
> because libc implements only standard C, which is quite conservative.
>
> libglib doesn't even require X11, much less gtk; I don't understand why
> you push that false argument that using libglib would be "requiring
> gtk dependencies"; it is just plainly wrong. libglib is not more tied
> to gtk than, for example, libz or libpam.
>

First of all, just to clarify, I didn't say glib requires gtk. Gtk/Gnome 
requires glib.

The problem as I see it is twofold: First, and most importantly, is that 
because it's not a part of standard C very few KDE/Qt developers are going to 
be familiar with glib code. Basically the only people who know it are GTK 
coders. Of course there are some KDE developers who know glib, (I'd say 
probably the Arts guy for sure ;-), but not many. This is a huge problem if 
people start trying to make KDE use it for core components. It's not a 
standard thing we can expect most of our developers to be able to parse.

Currently everything in the KDE's core technology is understandable by most 
KDE developers. Since everything is documented and constructed basically the 
same way you can pretty much look at any part of KDE's code and understand 
what's going on. Many experienced people don't even look at the HTML API docs 
for KDE anymore - they just look at the headers. Of course there are 
exceptions, but even lowlevel things like dcop and the session management 
server are all pretty understandable once you know Qt.

If things were truly desktop neutral and written in standard C, KDE developers 
would still be able to easily take an active role in it's development and 
maintence. If, on the other hand, they are based on non-standard libraries 
like glib the only people who will be able to parse the code are GTK and a 
very few KDE developers. This isn't right. You shouldn't have to learn both 
Qt and glib in order to understand *any *part of core KDE technology, 
although this seems to be what some people are expecting.

Really, I do not think it is unreasonable at all to expect people who want to 
write desktop neutral software that is to be adopted by both projects to 
stick with standards. Standard C/C++, Posix, and X11. These are things most 
developers know and understand. I really feel that this actually should be a 
given and we shouldn't even have to have this debate. I know it's harder to 
write standard C/C++, like I said I'm always wishing I could use Qt templates 
in my non-Qt code, but this is just something you have to do if you want 
something to be considered a standard. KDE didn't make this clear and the GTK 
developers started developing everything using glib and expecting it to 
become a cross-desktop standard.  This isn't the way things work. If you want 
your software to be utilized by both desktops and be a standard you really 
need to stick with standard code both parties can easily parse.

The second issue is of course bloat. To be honest this issue concerns me less 
than the developmental aspects. 

As I said this isn't much an issue with pkg-config because that is only used 
with building KDE - it doesn't bloat the runtime system - but it certainly is 
an issue with a lot of the other discussions going on.

> "passwd", the command to change passwords in the command line on a
> GNU/Linux system, a command line only program, uses libglib; so, on any
> GNU/Linux system, libglib is already a requirement, at the same level
> of basic requirement as having libc or libz: you simply won't find any
> system without it.
>

What are you smoking? Passwd doesn't require glib. I've run many systems 
without glib. No standard Linux utilties require it, it's not a standard 
Linux lib. Are you confusing glib and glibc? Or maybe Red Hat went insane and 
starting linking everything to glib ;-)

Passwd is part of util-linux. I've got 2.11z and there are no glib 
requirements. I just checked util-linux-2.11z/login-utils. Making such 
bizarre claims actually undercuts your arguments. To say glib is as standard 
as glibc is not in touch with reality at all.

> You advocate on writting in raw C instead of using libglib; yes that's
> possible, but it's reinventing the wheel, and reimplemnting again and again
> the same routines on every single program, something which is not only
> a real waste, but also very bug prone.
>
> > KDE really needs to set limits on what and what is not acceptable in it's
> > core packages.
>
> I don't see requiring libglib any more "unacceptable" than requiring libz
> or libpng...

I question if you really know what it is...

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]