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 _______________________________________________ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list