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

[Damien Sandras <dsandras seconix com>]

Hi,

Not much time to enter a lengthy discussion right now. 

My generic answer would be that "it just works", which is already a good starting point.

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

You are right, I will provide a fix.

> (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.
You don't have to play with the ActionStore, it is an internal variable. Just play with the Actor code.

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

Yes, and I tend to disagree with that design which is too restrictive. I have already discussed this design with many people
whose job is to program and design object-oriented code and they all told me that it was really a weird design. However, it 
just works, so that's ok for me now.

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

iirc an ActionProvider can provide Actions to Actors.

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

Indeed, that needs to be changed and it is in my personal TODO.

--
Damien SANDRAS

Ekiga Project
http://www.ekiga.org