Re: [Ekiga-devel-list] Lecture de lib/engine/action/



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 !
--
Damien SANDRAS

Ekiga Project
http://www.ekiga.org


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