Not much time to enter a lengthy discussion right now.
My generic answer would be that "it just works", which is already a good
> (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
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.
ekiga-devel-list mailing list