Re: UrShape definition Part I

[John Palmieri <johnp martianrock com>]

Hey Andre, check out my UrShape and GObject post.  I think this will solve a
lot. They are basically non-gui Gtk objects.

Andre Kloss wrote:

> Hi again.
>
> > Could someone give a brief overview of what the ObjectOps and ObjectType
> > stuff do?  Is this still used or is it depricated in the StdProps code?
> Well, I don't know. I just found it in the source and it looked
> reasonable to me. Cyrille? James? Someone?

GObjects makes our code easier to integrate with other Gtk-2.0 apps much like
Gtk+ makes it easy to reuse gui components in other programs.  The core team
has mentioned their use and if they like it I think it is the way to go
instead of the current home grown code which may lose ground in the future.  I
think the code that custom shapes is built on was set to be phased out in
favor of the StdProps code.  Correct me on this if I am wrong.

> > >   int max_children;
> > We don't need a max_children do we? unsigned int child_count; perhaps.
> Well, we _may_ need it. What if some UrShape can contain exactly 2
> subshapes and no more? Or exactly 1 subshape? And child_count will be
> optional, since the child is a pointer to the first child and you can
> follow the next_sibling pointers unto the last child, where the
> next_sibling will be NULL.

I see your point.

> > Also some way to store an arbitrary structure (i.e. Gtk Widgets - This
> > is where I wish we were using an OO language).   And how are we going to
> > handle attributes?  Should we use a hash or hard code them in a
> > structure?
> I like the idea of a hash, since it gives use some ease of extension.
> If I want to have a "save-to-some-format"-function in my UrShape, I
> can easily add it to the hash (And maybe trigger by name in a dialog?)
> What is this Gtk Widget stuff? And where? I can think OO in C, so
> that's no prob. ;)

GObject takes care of all of this.  It has the idea of polymorphic types and
signal and slots for hooking up callbacks.  There was also something about the
signal and slots having the ability to be language independent.  It wasn't
elaborated on too much but if that is true then problem solved with scripting.

> > This is a good start.
> Why, thank you.
>
> > Is there any other code that you guys are working on that you just
> > havn't shared yet?  I think we need to see more progress.
> That's why I started so humble. I don't really know where you guys
> want to go with this stuff,
>
> > -J5

--J5