[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