On 28 Nov 2000, Jean-Marc Lasgouttes wrote:
> Menus and toolbars are read at startup already. It would be better to
> change them on the fly, but this should be doable.
I know the menus and toolbars exist as data structures (after all, we
started this together in Italy), and therefore, it's relatively easy to
get the basic functionality ported to different platforms. In other
words, we have a model for the menus at this point.
In parenthesis, we should add that this has been accomplished by
defining a minimum feature set: We cut out the dynamic part of the menus
that existed previously (i.e. LinuxDoc adaption), and focused on a core
menu abstraction that would cover the basic needs. This was a wise
decision giving that we aim for GUII.
But it only demonstrates what Matthias already said: We are closer to
the lowest common standard, rather than closer to the possible
standard.
For instance, there is no functionality to handle dynamic menus, in the
sense of menus that adapt to the state of the program. For instance, when
you work on a DocBook document, it should reduce the menus to only the
relevant options. (Or at least minimally, disable the non-relevant ones).
Also, you do not have the infrastructure to handle changing toolbars on
the fly.
These things are difficult to implement in a GUII way. In the end,
you'll probably end up with the "solution" where each front-end implements
this on it's own.
In addition to this, you only have the abstraction for the model
part. Each front-end has to implement both the controller and view
separately.
In a "true" model/view/controller architecture, you should be able to
reuse the control and model part, and only implement the view part for
each front-end.
As I see it, the GUII method you are proposing is to only reuse the model
part of the program, and then let each front-end implement both the view
and control part separately.
This is definately an understandable choice, because it's hard to come up
with a good control abstraction that will work for all
front-ends. However, it also illustrates my point: By going for GUII,
you end up with a less structured program, since the task of developing a
good control abstraction is neglected, and shoved away into the
front-ends.
In addition, the model abstraction is trimmed to a basic feature set, such
that it can target many different front-ends. (I know that you argue that
it does not matter whether an application can use the newest GUI
components to get a user friendly program, and I agree. I just want to
point out some of the trade offs that you are doing when you choose to go
for GUII, rather than MVC for one front-end only.)
I also have to add that I understand that it is entirely possible to
develop a fully functional, reusable model component and a fully reusable
control component that will work with all front-ends. However, this task
is much more difficult than developing the same components for one
front-end only.
And therefore, it's more complicated to go for GUII than to go for MVC
for one front-end only.
If you went for one front-end only, it would not be necessary to trim the
model to a basic feature set, and it would be much easier to develop the
proper control component, since it does not have to be reusable across a
spectrum of different front-ends.
> It would probably make sense to implement a canvas in each frontend
> and have that be the heart of the application, which calls the other
> parts.
So once again you argue that both the controller and view should be
reimplemented in each front-end.
I'm sure you'll also find that the reusable model will have to be trimmed
to a basic common ground.
I thus maintain my position: If you went for MVC for one front-end only,
you would be cleaning up LyX faster, because the tasks of developing the
model and controller components is much easier in this situation.
Therefore, LyX could become more functional in a clean way for less
effort.
Greets,
Asger
