Re: gtk-2.0



At 16:12 11.03.02 -0600, Lars Clausen wrote:

So GTK-2.0 came out over the weekend[1].  I've spent some time today trying
to get Dia to compile with it.  There's a bunch of smaller things, but now
I'm hitting the big stuff.  Major changes would include using ATK instead
of XIM and changes to redrawing.  I'm currentl;y stuck at changing
GdkColorContexts into Gdk_RGB_* stuff.  My notes on changes are attached
below. 

You apparently haven't noticed, that there already is a TARGET_GTK_2_0
branch in cvs. It does compile and work quite nice, but has fallen a 
little behind with respect to full UTF-8 conversion (and there are no 
plans to do direct FT2 rendering (The Text rendering IMHO should be 
converted to straight Pango and when limitations in Pango arise
it first should be tried to get the Pango API extended instead of
reinventing the Font/Text wheel once more ...)

The main question now is:  What do we do about Gtk 2.0 in Dia?  Do we make
a branch for the conversion?  Do we use a HAVE_GTK_2_0 macro (as I have
done so far)?  Do we ignore it till it stabilizes a bit?

There was some off-list discussion to first do a stable Dia release
based on Gtk+-1.2 (early Gtk+1.3 on windoze) before creating a 
'stable' branch and switching cvs HEAD to Gtk+2.0.

Though I'm not sure how much time people (including me) are willing 
or able to contribute to one or both projects at the moment.

One major goal of mine is to _not_ introduce anymore #ifdef mess 
to any Dia branch (at least not for the GTK+2.0 branch). 
In fact if there really is the need for different implementations 
of the same functionality (like rendering with differnt Font/Text 
Systems) it should be tried to first build an abstract interface 
where both (all) implementation can live with and after that 
keep the implementations as separate as possible. 
[Printing code comes to my mind as an example as well.]

Maybe the different 'plugable' implementations can even be 
run-time selectable ...

Regards,
        Hans


[1] And they still didn't improve the file dialog.  *grumpf*

But finally it is there. And the file selector very high on
the todo list (see recent posts to gtk-devel-list). 

[..., see TARGET_GTK_2_0 branch]

Overall:  Our redrawing mechanisms may have to be reconsidered.

Not really. Only the default double buffering of Gtk+2.0 needed
to be switched off to avoid nasty flickering quad buffering.


-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]