Le lundi 05 janvier 2015 à 20:35 +0100, Julien Puydt a écrit :
> lack centralization... I think the answer to my question (1) would help
> me understand more precisely what you want.
"(1) An action name has a global meaning... but one can have one "call"
action per presentity, so how does one know which one the global one is
about? The last which was clicked and declared it provided it?"
There are two different things:
1) The Ekiga Engine abstraction: An Actor provides Actions. Actions are
local to the given Actor. They are not global and there is no central
"store". This is very similar to what the LiveObject was doing. A bit
later, we could turn the LiveObject into an Actor and get rid of
MenuBuilder. A presentity is thus an Actor, and each presentity declares
its own Actions.
2) The GLIB implementation (GActorMenu): You simply construct a
GActorMenu by constructing it with an Actor as argument. The GActorMenu
then registers the actions into the GLIB GUI abstraction system where
they are global (or local to your specific window).
This is very simple to use and has one big advantage : it is automagic,
and you can use GUI actions anywhere you want if you know they exist
(like "Call", "Transfer", ...).
Yes, we finally have a Call button users can click when a Contact or a
Presentity is selected without the need to right-click on the
Contact/Presentity and select "Call" in the MenuBuilderGtk. That's one
of the many improvements !
ekiga-devel-list mailing list