Le lundi 05 janvier 2015 à 20:35 +0100, Julien Puydt a écrit :
> Le 05/01/2015 11:46, Damien Sandras a écrit :
> >> (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.
> Uh... they never heard of separating the interface from the
> implementation? They never found it useful to quarantine code behind an
> interface so deps don't spread to the whole code base? They never used
> an interface to make polymorphism work?
No, they tend to disagree on other parts of the design. That is,
frequently, overly complex for
what we try to achieve, or overdesigned with too much abstraction.
Separating some parts of the implementation from the interface is useful
when the code is templatized
as it makes the compilation lighter than having the template directly in
the base class.
There are also other flaws to the approach like the fact that the
interfaces are sometimes too basic and
leave the job to the specific implementation. In some cases, there is
only one method in the interface.
That does not make much sense.
> I don't mean the idea of an action system is bad, it's just that I'm not
> convinced the current framework is sound. Notice that the current
> LiveObject framework with the MenuBuilder is already making it possible
> to export actions in a very dynamic way, so it has good things. It does
> lack centralization... I think the answer to my question (1) would help
> me understand more precisely what you want.
MenuBuilder was tied to the concept of menu. We are now architecting
things behind Actions,
I propose to keep the current Action code intact and to work on the
parts of Ekiga that really need
As a second step, and after the current release, I would like to work on
the improvements and simplifications
of the engine.
To make it clear : I won't discuss further about the engine before we
release 5.0. And I won't accept any big change
to the current code. We need to make progress and concentrate on what
ekiga-devel-list mailing list