At 16:37 20.02.01 -0600, Lars Clausen wrote:
>On Tue, 20 Feb 2001, Hans Breuer wrote:
>>
>> The whole property api should be re-thought, when converting to gobject
>> usage anyway ... And the text handling when converting to Pango usage.
>
>NO!!! Nonononono! Please, please, pretty please with sugar on top and a
>fscking cherry, no!
If seen this film, too. But I'm Mister Wolf :-)
>We've redone the property API twice already, and what we have now is fairly
>useful. What we really need to do for a version 1.0 is make all objects
>use the current API consistently, not start switching to a third API.
What about first identifying the missing bits, which may have blocked the
consistent conversion to the new (second) api until now ?
Converting all the Dia object to Property API version 2 would IHMO be a
big mess of duplicated code, as I have already done for some UML objects,
to get it useable. I've even written an embrionic code generator to get
all the required glue code, but there where still issues remaining to
get the property access right:
- what about reference counting of objects and properties (would be
useful at least for language bindings) ?
- how to create properties which are themselve list/sets of properties
(as needed in the UML class to get access to the function list for
example)
- IMO a Property Setting Api needs to be introduced, because pokeing in
internal structs to change some values appears not to be the right way
to go. If one could use a generic access for this it wouldn't be a big
deal to convert the internal representation (e.g. switching Dia objects
to real (g)object. But if there would be more import filters needing to
directly access the property data, this will open just another can
of worms ...
Something IMO pointing to the right direction is attached (a generic
"Import To Dia Renderer", which currently is mostly a proof of concept)
>I know how alluring it is to use the newest and best all the time, but we
>have a long tail of objects that work inconsistently simply because they
>haven't kept up with API changes.
>
I see the problem of unreliable release times for dependencies like GObject,
but I hope that Dia 1.0 is planned to be compatible with Gtk 2.0 anyway.
The GObject System needs to be stable and useful for Gtk 2.0 (and it appears
to get the missing bits in time). IHMO the right time to do some conversions
would be now, because otherwise the final Gtk+2.0 maybe missing some required
bits to make it totally useful for Dia's object system needs.
What about a Target-Gtk+2.0 branch of Dia ?
>Changing to GObject and Pango should only be consider for a version 1.1,
>IMO.
On win32 there are probably more serious problems with Gtk+2.0 than on *ix,
because of less users / developers. It's simply not the main target. But I
would like to use GObject right now, because IMO it will greatly simplify
the Property API, the object handling, language bindings, split of core
functionality and user interface, etc ...
Obviously I won't do this, if all of it has no chance to get in future
versions of Dia. IMO we should do it right now instead of doing it after
version 1.2 (like The Gimp) because the tools are almost there and there is
currently a relatively small code base to convert.
Regards,
Hans
-------- Hans "at" Breuer "dot" Org -----------
Tell me what you need, and I'll tell you how to
get along without it. -- Dilbert
