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
_______________________________________________ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
