Re: Non-technical Glib advise needed

["John (J5) Palmieri" <johnp martianrock com>]

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.  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. 

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.

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. 

> I'm not a master programmer, that's why I'm asking. I hope I'm not
> asking for too much. If I'm not clear enough, ask me, and I might be
> able to clarify further what I want to do.
>
> Best regards,
> Aron Stansvik
>
> _______________________________________________
> gtk-app-devel-list mailing list
> gtk-app-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list