[Ekiga-devel-list] Populating menus and using them off-process


let me try to explain how menus are made gui-independent in the engine, and how that can allow doing things off-process.

Let's consider an object in the engine, which wants to make some actions available. It will do so by having a method populate_menu, which will receive a single argument, of type Ekiga::MenuBuilder, to which it will feed enough information (see lib/engine/framework/menu-builder.h for details).

Why does it make the engine gui-independent? Because you can write a new implementation, which will be gui-dependent! For example, we already have two implementations in ekiga at the moment, which are ToolbarBuilderGtk and MenuBuilderGtk (found respectively in lib/engine/framework/gui/gtk-core/toolbar-builder-gtk.* and glib/engine/framework/ui/gtk-core/menu-builder-gtk.*) ; they are both for gtk+, but allow action with objects through either a toolbar, or through a menu (for example a popup menu).

If you want to implement a new gui, for example for a text-based ekiga, then you only have to implement new versions of Ekiga::MenuBuilder and use it to get access to the very same object.

The object you can act on needs to have an 'updated' signal, and that your gui will have to act on it : dump the menu/toolbar/whatever it had, and request one anew.

It also needs a 'removed' signal, which means "Drop everything you know about me, don't ask any questions, just do it *NOW*" : the object is perhaps already dead, you can't do much more than use its now-invalid address to find any reference you have to it and get rid of it. This includes of course any menu. (Memory management will be the subject of another mail... when I find the time to complete the draft)

There is a very special case of user interface I would like to discuss : an off-process one, done through any RPC system you want (DBUS comes to mind). The Ekiga::MenuBuilder will receive something like (icon, label, callback), associate an identifier to the callback (a string, for example), and store both.

It will send (icon, label, identifier) through the wire, for the remote user interface to display and choose. And once the other side tells to trigger the identifier, we can then either trigger the associated callback, which will do what we want, or the identifier is now invalid (the object was updated/removed since!) and we just send back an error message.

Hope this helps,


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]