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

[Julien Puydt <jpuydt free fr>]

Hi,

I finally found some time for ekiga yesterday evening and this morning. 
It turns out my chat_opal_v314 branch was dead : it didn't rebase 
cleanly and anyway it was not working and I don't remember anything 
about it. I'll just start from scratch.

I saw my loudmouth code didn't compile anymore because of a new action 
system : this morning I tried to understand it... so I have questions 
(and critics...) :

(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?

(2) An action has two signals : enabled and disabled... which means it 
can get back and forth to both states. But how is it related to the 
lifetime management of objects? We don't want a dead object to be called 
through an action, or a would-be-dead object to be kept alive because an 
action somewhere still has a callback on it...

(3) I really think it is very bad that the base class Ekiga::Action has 
enable/disable methods : the loudmouth presentity knows if it can be 
called or not, nobody has to dictate whether or not this is possible! 
The only thing a UI can ask is to trigger an enabled action, it doesn't 
get to decide more than that! The UI's job is be pretty : let the 
serious code handle the serious work!

(4) I really don't get what this private on_activated is about...

(5) Ekiga::ActionStore is too stupid : how can one put an UI on that?! 
There's no signal to know when an action is 
added/removed/enabled/disabled... for the last two I can get around that 
by putting callbacks directly on the child actions (but then I have more 
connections to manage), but for the first two? The Ekiga::RefLister api 
is better in that respect : it was meant for dynamic situations.

(6) The fact that a base class isn't purely virtual is annoying... In 
the rest of the engine, a base class Ekiga::Foo is purely virtual for 
100% of cases, and an Ekiga::FooImpl is provided with an implementation 
to cover 99% of use cases. Don't get in the way of the last percent!

(7) The difference between Ekiga::Actor and Ekiga::ActionProvider eludes 
me...

(8) Ekiga::Actor has a friend on GActorMenu : that is a huge design 
flaw, as that means the base code isn't GUI-independent anymore!

It's hard to get back :-(

Snark