On 22 Jan, Lars Clausen wrote:
>
> For the object (middle button) menu, I'd like to always send along the
> event, so the object can figure out e.g. a nearby handle or edge. One way
> to do this would be to wrap the normal callback and data up in a structure
> that becomes data for a generic callback. The generic callback then calls
> the normal callback with its data and the event (in fact, it might as well
> send the whole structure, including the callback pointer, so the callback
> can modify itself). Can you think of any reason this would be a bad idea?
> Any better implementation?
Umm, it's not *perfectly* clear what you mean. Lets try to decipher.
First a few general comments about Dia's architecture: All control flows
and events goes from the app to an object. An objects never
asynchronously generates an event. (You seem to follow this, i just
mention this.) Anoher important thing is that Objects don't know
anything about windows. They just know about floating point
coordinates in the diagram space.
Soo, lets see. Object menus it was. How do they get configured then.
You press the middle button, if you hit an object you call an method
like ObjectMenu *get_object_menu(Object *object, Point *point) which
returns a structure describing all object-specific menu items and their
callbacks. The app then creates a menu that combines the objects menu
items and some (maybe) general menu items that's always there.
A callback is registered for the menu items that proxies the callbacks
so that they have a nicer argument list, no GtkWidget *, but instead
something like object_callback(Object *, gpointer callback_data).
What about this? It seems quite close to what you suggested.
> -Lars is beginning to understand why Gtk is well-liked.
Yeah, Dia is actually my first ever Gtk program, it's very easy to
learn and work with.
/ Alex
