Re: gtk-2.0



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?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]