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. 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
> 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 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?