At 16:26 13.03.02 -0600, Lars Clausen wrote:
>On Wed, 13 Mar 2002, Hans Breuer wrote:
[...]
>> You apparently haven't noticed, that there already is a TARGET_GTK_2_0
>> branch in cvs. [...]
>
>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.
>
>From its ChangeLog:
[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
_______________________________________________
Dia-list mailing list
[EMAIL PROTECTED]
http://mail.gnome.org/mailman/listinfo/dia-list
