Re: gtk-2.0

[Lars Clausen <lrclause cs uiuc edu>]

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?