Re: Non-technical Glib advise needed

[Aron Stansvik <elvstone home se>]

On Sun, Jan 11, 2004 at 05:09:02PM -0500, John (J5) Palmieri wrote:
> GLib is a C library.  You are free to use GObjects or stick with
> standard C structs.  GObjects imposes an Object Oriented framework which
> can make it much easier to organize your code.  Gobjects are like any
> other object system with its own little twists and turns.  For instance
> most of the boilerplate code that is hidden by OO systems like Java and
> C++ must be hand written for GObjects.  If you feel more comfortable
> with C++ you might want to check out gtkmm bindings.

Okay, I'm more comfortable with C, I'll stand the twist and turns I
think :)

> GObjects supports
> inheritence so it might be a good solution to your dependecy graph.  You
> would basicly be creating a tree of nodes with each node being an
> gobject object.  Each node can be a representation of the objects in
> your scene.  The Gtk widget system is somewhat of a dependency graph
> iteself.  When containers are moved or resized so are the children. 

Okay, hm. In this case, I would want it so that the connection is
two-way. Any attribute on any node should be able to be a key value for
any attribute on any other node. This picture (might) illustrate this:

 +-----------+
 | node1     |
 |  * attr1 ---------------     +-----------+
 |           |             \    | node2     |
 |  * attr2 <--------------------- * attr1  |
 |  * attr3  |               `---> * attr2 ----+
 +---- ^ ----+                  +-----------+  |
       |                                       |
       |       +-----------+                   |
       |       | node3     |                   |
       +--------- * attr1 <--------------------+
               |  * attr2  |
               +-----------+

Above, attr1 in node1 controls attr2 in node2, which in turn controls
attr1 in node3 which in turn controls attr3 in node1. attr1 in node2
controls attr2 in node1. Would something like this be possible using
inheritance, as you suggest? I might be confused here, I'm just having
the picture of the Alias|Wavefront Maya Dependency Graph in my head, in
which you can connect anything to anything (basically).

> If you want to get even more advanced you could write an object that
> implements the TreeModel interface and itterates over your dependency
> graph.  This would allow you to attach it to a TreeView and have a
> GtkTreeView widget display the struture of your scene without having to
> write your own Tree widget.

Hm, I'll think about it. What I had in mind for visualisation of this
graph was an orthographic OpenGL view where you can move around and zoom
in on the nodes, not a regular GtkTreeView. But that is all too far ahead,
I'll focus on the absolute basics first :)

> more comments bellow.  
>
> On Sun, 2004-01-11 at 15:58, Aron Stansvik wrote:
> > Hi Gtk folks.
> >
> > I've used a lot of 3D software on and off over the last 4 years, and although
> > I know I might never make a working 3D modeler (for a number of reasons),
> > that's what I'm trying to do now. I've been playing around with Gtk+ and
> > GtkGLExt for a while, and it seems to do what I need for a frontend, and
> > for scripting (which will probably be the primary way of controlling
> > objects in a scene for a while), I've found LUA (http://www.lua.org) to
> > fit my needs. What I'm looking for now is something to aid the managing of
> > the data structures within the scene. The internal representation of
> > objects, materials and lights should be something like a graph with
> > interconnected nodes (with their attributes). For example, like this:
> >
> >           +-----------+
> >           | material1 |
> >           |  * colorR |
> >           |  * colorG |
> >           |  * colorB |
> >           |  * ...    |
> >           +-----------+
> >             |          \
> >             |           \
> >           +-----------+  +----------+
> >           | sphere1   |  | cube1    |
> >           |  * colorR |  | * colorR |
> >           |  * colorG |  | * colorG |
> >           |  * colorB |  | * colorB |
> >           |  * ...    |  | * ...    |
> >           +-----------+  +----------+
> >
> > I hope you see what I mean here. The three attributes in the node
> > material1 will affect the three corresponding attributes in the two
> > nodes sphere1 and cube1. This is how a scene is represented in
> > Alias|Wavefront Maya, if anyone is familiar with that program, and there
> > it is called the Dependency Graph. I wish to do something similar for my
> > little modeler, although much less sophisticated. So, finally, my
> > question is: Is Glib a good choice as a library to build this kind of
> > data structure? I've read some about the Glib Object system at:
> >
> > http://le-hacker.org/papers/gobject/index.html
> >
> > but I thought I'd ask here, it's better to hear that what I'm thinking
> > is whack from someone on this list than finding it out the hard way.
> > Could the interconnections between the nodes be implemented using
> > signals? Is it a Good Idea(tm)?
>
> Signals are used for events.  So if a user clicks on an object an event
> would be triggered and sent to the object.  Signals are usualy used when
> an object wishes to notify the outside world something has happened but
> does not know specificly who they are notifying.  If however they need
> to talk to an object directly a good API and refrence to the object is
> more efficent. 

Ok, I guess so.

Thanks a lot for your long answer.

Best regards,
Aron Stansvik