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

Reply via email to