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