On Fri, 23 Feb 2001, Hans Breuer wrote:
> 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 :-)
I agree with Hans here. The glib 2.0 properties API is very flexible, and
has a lot of useful features (property change notification, much more
convenient API, etc). When we move to gtk 2.0, it would make sense to use
it (switching a lot of the Dia data structures over to being GObjects
would also allow for a lot of cleanup).
However, getting a stable 1.0 release working with gtk 1.2 is a good
target (gtk 2.0 is not ready yet, and people will be using 1.2 for a while
to come).
>
> >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) ?
This will definitely happen when we move to GObject (also, a large amount
of the language binding could be automatically generated using the tools
developed to wrap GTK). I don't know how much code changes would be
required to add ref counting to the current code.
> - 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)
Maybe having a varargs property setting routine would be good.
>
> >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 ?
There are a lot of cleanups that I would like to do that use glib/gtk 2.0
features (converting objects, layers, diagrams to GObjects, using
signals for some of the notification stuff, converting the layers
dialog to a GtkTreeView using a custom model that represents both the
layers, groups and objects in the diagram).
I don't know if it is the right time to start a branch though.
>
> >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 ...
Using GObject and related APIs in the current version is not really
acceptable, as they aren't in glib 1.2, and you can't link to both 1.2 and
2.0 simultaneously.
>
> 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.
I would prefer to wait til gtk 2.0 is closer to release. It is stil
changing, which doesn't make it a good target to develop against yet.
James.
--
Email: [EMAIL PROTECTED]
WWW: http://www.daa.com.au/~james/
