RE:

[gtk-app-devel-list amnesia accessgate com sg]

On 12-Feb-2008 Markus Müller wrote:
        .
        .
        .
> The widgets will be nested: The train-widget provides a array of vehicles
> which provides a array of waggons with an array of cameras...
> Accessing the object properties can be done with references/pointers to the
> data variables (the "normal" access to struct-members e.g.:
> train.vehicle[1].waggon[4].camera[3].colour = green)
> One of the biggest questions therefore is the structure of the necessary
> manipulating functions: How can i best handle e.g. the redrawing of a camera
> when its de-/selected (In C++ i would create a member-function to the
> camera-object!?). I think to create a function set for every widget which can
> always provide the interface for the upper "parent" instance!? Alternative
> there could be a set of "top level" functions, but therefore the parameters
> are getting kind of nasty !?

it would be much the same in the gtk environment. You will associate a callback
when the object is deselected. Depending upon the type of object, you will have
a callback on, e.g. a "clicked" event. My initial reaction is that you might
draw your camera on a button, and associate a clicked event with the button,
and the callback would redraw the object w/ the appropriate colour.

If you need the redraw to be done when ANOTHER event happens (e.g. some OTHER
object is selected/deselected, then obviously you need to store a handle to the
camera object somewhere. How this is done is left as an exercise to the reader.
Common ways are: g_object_set/get_data(), creating a "class like structure",
and passing the handle to that structure (or that structure instance, as the
case might be), as the callback arg, global arrays/structures, etc. I find the
last to be too dirty for my tastes (I like encapsulation). I find the first to
be messy (but quite common, and convenient, in gtk code). At the moment, I'm
gravitating towards the 2nd approach, and passing a structure pointer as the
callback arg, which allows me to pass as much/little information into the
callback as I need to (and it's more "class like" in it's approach).

(I should hasten to point out that while I listed only 3 approaches, I'm sure
that creativity can come up with others... :)

I think, at the end of the day, how you organize your data will be key in how
you will be able to access it, and pass it around. That is to say that your
data organization will more or less dictate your choice of parameter
accessability (or vice versa. if you eant to enforce from the accessability
point of view, then that will dictate how the data must be organized).

best rgds,

-Greg


+---------------------------------------------------------------------+

Please also check the log file at "/dev/null" for additional information.
                (from /var/log/Xorg.setup.log)

| Greg Hosler                                   greg hosler per sg    |
+---------------------------------------------------------------------+