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

[Julien Puydt <jpuydt free fr>]

Hi,

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,

Snark