[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 20:53:50
[Download RAW message or body]

On Monday 17 March 2003 11:23 am, Alexander Neundorf wrote:
> On Monday 17 March 2003 04:09, Mosfet wrote:
> ...
>
> > 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.
>
> There is TinyQt which I found only some time ago, but of course it's GPL
> too: http://www.uwyn.com/projects/tinyq/
>

Yep, I found that as well. Without TrollTech's blessing a lot of people don't 
know about it, tho. 

Glib was actually the non-GUI part of GTK that they separated and shipped 
independantly a long time ago. Then they started sticking it all over the 
place like in PAM, pkg-config, and trying to do it to KDE via freedesktop 
software ;-). They are spreading GObjects all over the place and some Linux 
users even think GObject and the other things like Glib trees and hashes are 
more or less a part of standard C on Linux! This is a major problem for 
non-GTK developers, and pretty insane. AFAIK it's not like glib is a normal C 
library like zlib or libpng. It extends C, providing Gnome's "psudeo-object 
oriented C", in ways that touch most of the resulting code. Now people are 
trying to claim this is standard and should be able to use it in 
cross-desktop software.

Qt should do the same IMHO. Seperate the template and non-GUI classes, release 
that as the LGPL, and then release the GUI toolkit on top of it under the 
GPL. I don't believe this will cost them any customers or hurt their business 
model. I seriously doubt that they have any customers buying Qt for non-GUI 
applications. All it would do would be to help adoption in non-GUI 
applications, just as making Glib and Gtk separate helped it's adoption in 
non-GUI applications.

> ...
>
> > 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
>
> I can only agree to this .
>
> I think there are enough people against having kdelibs depend on glib, that
> this should count as a "veto".
>

Yes, but will they listen? ;-) I will reiterate that KDE needs to have an 
official policy on this. Otherwise Freedesktop will continue to make 
Glib/GObject based code and then get all upset and make political noise when 
it is not accepted in KDE. It will be a mess and we'll have less tech-savvy 
users accusing us of not accepting standards when in reality it is because 
the software coming out is not written in standard C that everyone, both KDE 
and GTK developers, can easily understand and maintain. In contrast our 
current solutions make it rather easy for anyone with Qt knowledge to just 
jump in and start hacking core parts of the architecture. Your already 
starting to see this problem in some of the more opinionated and biased 
users. We need a document we can point to that says if you are creating a 
cross-desktop standard component you need to follow standards everyone, both 
Gnome and KDE developers, will understand. This should include standard 
C/C++, Posix that works on both Linux and Unix, and X11 if you need to access 
lowlevel things XRender, libICE, etc.. Otherwise Freedesktop needs to stick 
to specifications that everyone can implement and maintain efficently, not 
software implementations.

> Bye
> Alex

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