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
