On Wed, 13 Mar 2002, Hans Breuer wrote: > 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 ...)
Didn't think of that -- that was started quite a while ago, wasn't it? Has it been kept up to date wrt other stuff than UTF-8? I.e. changes in the properties system etc? I'm in the middle of a major change to the vtable system that should definitely go into both branches. >>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. That sounds like the way to go. The code is a mess right now and needs to stabilize before we start an even greater mess:) > 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. Once we switch to Gtk+2.0 for our head, we probably wouldn't want to do more than bugfixes on the 1.2 branch. > 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.] Indeed. I am thinking the GTK+2.0 branch should not include the freetype stuff (but that is fairly easy to remove). Pango looks like a good thing (though I don't know how it prints yet -- any programs does printing with Gtk+2.0 yet?). Fonts are already somewhat abstracted, but the abstraction and implementations aren't completely split yet. Notice that Pango rendering is a completely different thing than Gtk+1.2 rendering. In particular, it renders a full line at a time in order to do some of the high-level transformations that south-east asian languages have. So we will need to rewrite a lot of stuff anyway. >>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. Well, wouldn't we want to make use of the Gtk+2.0 redrawing instead of doing it ourselves? -Lars -- Lars Clausen (http://shasta.cs.uiuc.edu/~lrclause)| H�rdgrim of Numenor "I do not agree with a word that you say, but I |---------------------------- will defend to the death your right to say it." | Where are we going, and --Evelyn Beatrice Hall paraphrasing Voltaire | what's with the handbasket? _______________________________________________ Dia-list mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/dia-list
