[no subject]

[TARGET_GTK2_0 : branched from HEAD with -D 2002-01-17]

I 'ported' some of the stuff after that date (not noticing any
changes to the properties system) but my time to spend on it
was less than expected ...
 
> > > [...]
> > 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.
Obviously. But at the moment there appears to happen more work on
new features based on Gtk+1.2 code than stabelizing for a new
release. [IMHO - as noted before - even the utf-8 conversion
should have been done - or at least would have been much simpler -
based on GLib 2.0 services]

> > 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.
Agreed. This is what I meant by extending the Pango API.
Even rendering to a bitmap isn't supported by Pango without
introducing a specific backend (pango-ft2). 
I once (gtk-devel-list: Pango Backend Abstraction, 2001-08-26)
tried to get something to avoid this into Pango, but with
some more convincing arguments provide by some working Dia
code it probably would be simpler :-)

> 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.  
Yupp. The whole dia/lib/font.c much of lib/text.c some of
app/render_[gdk|libart].c.
But at least on win32 it should be quite simple to get printing
work with it because of pango_win32_render() which takes a Device
Context either used for display or printing. Don't know about
X11 equivalents (probably they are not there) ...

> > > 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?
Keeping it the old way took me one call to gtk_widget_set_double_buffered()
and the goal was to first get an almost working Dia again. 
Don't know much more about keeping the own double buffering instead of
using gtk+ ones beside not needing to rewrite anything ...

        Hans


-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to 
get along without it.                -- Dilbert