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

List:       kde-devel
Subject:    Re: Richard Stallman On KDE/GNOME Cooperation
From:       Maks Orlovich <mo002j () mail ! rochester ! edu>
Date:       2002-02-20 1:04:44
[Download RAW message or body]

Waldo Bastian wrote:

> On Monday 18 February 2002 03:10 pm, Andy Goossens wrote:
>> Following story appeared on /.
>> "For the first time that I remember, RMS is encouraging collaboration
>> between the GNOME and KDE projects. He offers a concrete idea: Unifying
>> the themes between KDE and GNOME. Matthias Ettrich once went far enough
>> to propose a default unified 'Linux' theme that both Qt and GTK+ could
>> support."
> 
>> Comments on this matter?
> 
> This is certainly a good idea. Although it will be hard to make truly
> advanced themes without relying on the toolkit being used (making such
> themes is hard anyway, and only a very few people have shown that they are
> capable of doing so) 

I have carried out an experiment sometime ago trying to create a KDE3 style 
that calls Gtk+-1.2 routines to do the drawing. It was "mostly" working, 
but revealed a number of differences that make creating a common C or C++ 
API pretty much impossible.

The #1 is that Gtk style APIs are, to best of my knowledge, not documented 
anywhere. The only way of understanding what they do is to go through the 
Gtk style source code and that of style engines. And no, the headers don't 
work, since 80% of the work goes through a gtk_paint_box entry point, 
passing strings to detail parameter to determine what to draw.

(Note: Thus, everything else I say is based on code reading, so I might be 
wrong on some points; if any Gnomes are passing by and see anything wrong, 
please correct me)


Technically, there are many significant differences in the drawing model 
-- Gtk1  draws pretty much everything directly to the screen, with no 
support for drawing to pixmaps -- gtk_style_attach fails if given a pixmap 
drawable, as it expects to manipulate a colormap. Because of that, shaped 
widgets are handled by simply not drawing certain pixels.

Qt, on other hand, has lots of code drawing to pixmaps, and uses separate 
masks to handle round objects, etc. 

Thus to handle this in a UI-neutral fashion, one would have to abstract 
away drawing in a manner that's at least as powerful at Qt's, supporting 
drawing to pixmaps, widgets, and the printer at least. And re-implementing 
all that would be tons of work.

On the other hand,  Gtk has only very rudimentary and experimental support 
for metrics --  basically at a pixel metric level, it seems, but I didn't 
study enough  relevant code to be sure.  Qt has ridiculous power here, as 
illustrated by the fast that KStyle can layout the scrollbar in 4 different 
ways. So if one is to have a common style level, the widgets would have to 
be laid out in a way that matches Gtk.  Also, AFAIK Gtk1 doesn't support 
RTL, although Gtk2 likely does.

Anyway, I am strongly considering writing a layer-based   KDE style engine 
that uses Qt-native ports of Gtk engines as plugins, but I am not sure I'll 
have time to do that, so please don't count on it being there... It's 
probably at most a 25% thing right now..

> it shouldn't be too hard to make a standard for
> toolkit independent pixmap based themes. Although those will be somewhat
> less advanced, they tend to be much more popular since they are much
> easier to make. (t.i. you don't need to know C or C++ in order to make
> them and users don't have to compile them first)

This is likely to be more practical, as are native ports of selected 
engines; but it would also require a consistent definition of widgets, 
metrics, look n'feel, etc., and will likely have less power than either 
native pixmap engine.. For instance, Gtk's pixmap engine can scale 
background pixmaps. I know of no way of doing that with Qt that's not too 
hacky to even contemplate. 

> 
> But as with so many good ideas, the problem isn't the idea, the problem is
> finding someone who actually makes it happen.

(Nod).
I hope RMS simply forgot to include that patch, though ;-)

-Maks Orlovich

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