On 24 Nov 2000, Lars Gullik Bjønnes wrote:
> "Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:
>
> | You have to distuingish between GUII and model/view separation.
>
> I really do not see the difference between mvs and guii when only one
> toolkit is supported, except that with only one toolkit it is just
> _too_ easy to cheat.
John, Angus, Allan and Lgb now all said that there is no significant
difference between GUII and model/view separation when it comes to
complexity.
That is thus the main argument for continuing the GUII direction, rather
than a sole model/view direction, as I propose being inspired by
Matthias' comments.
I'm sure I can't convince you to change your mind, but I'll try
anyway since it's almost Friday(?!?).
I'm sure you'll learn by yourself at some point, but let me give you a
hint: You ain't seen nothing yet.
You argue that GUII is easy, because you have tackled one bit of GUII:
The dialogs. This took a long time, and several tries to get
right. Considering that the dialogs are easy because the communication is
very simple, and the performance does not matter, this should be the first
hint that GUII is more difficult than model/view. Now you say: Hey, but
if we did model/view only, the result would be the same!
That's not true. If you did model/view only, the result would be
simpler. As an exercise for your own sake, please have a look at the
structure and think how it would be simpler in a one toolikt environment.
I knew you wouldn't do this, so I have to bring out some heavier
ammo: The menus and toolbars. These, you are beginning to tackle, but
you haven't quite yet. You have a vague idea that it should be easy, but
haven't really done it yet. You have many reasons why this is so, but are
convinced that it's only a matter of getting it done.
You'll be surprised. The menu and toolbars are only moderately more
complex than the dialogs, but I think you will get more respect for this
when you tackle the dirty details:
- You want your framework to be flexible enough to have fully dynamic
menus and toolbars that are configurable at runtime
- You want to handle tooltips
- You want to handle icons
- You want the menus and toolbars to come and go according to different
events, such as entering a math inset or a table
- You have to handle special menus, such as the live TOC, the
documents and recently used files items, and so on
- You want to handle keyboard short-cuts. (You have had a big discussion
on how this should work, but it's hard even to agree on how it should
work.)
I warn you again: This is hard to do in a model/view setting. It's very
hard in a GUII setting. I anticipate that you'll end up with N front-ends
that to many of theses things they own way, and that the sharee model in
the LyX core will be fairly small. In other words: By trying to do the
big GUII step, you'll have to reduce the code reuse goals, and end up with
a worse structure than you could get with a more realistic goal.
(Allan already argued in this direction: There is nothing to prevent a
front-end from doing things it's own way. So much for code reuse and
components in the software. So much for reduced complexity: We just
shove it into the front-ends, and hope nobody will notice.)
I'm sure I have not convinced you yet. So I have to bring out the big
ammo:
The canvas.
The canvas is without doubt the most complex GUI component in LyX. It is
highly dynamic, has complicated communication both ways, and it has to be
*damned* fast. And did I mention that it has to be stateless, because
obviously we want sevearal views in different frames?
We have started to address one tiny part of this complexity with the
Painter, but don't kid yourselves: The painter is the easiest part of
this component. It's no coincidence that we attacked this first, because
that's about the only thing we could figure out!
You'll find plenty of fun when you have to implement the abstractions that
can handle the mouse clicks, the keyboard pressed, the focus handling, the
updating, the double buffering, the fast scrolling, etc.
It's an overwhelming task just to implement model/view separation for this
component. Now, to do it in a GUII setting: It's take you years.
I can only talk from my own experience. Maybe I'm a bad designer, or
maybe you are just much more clever than me. Maybe you just do not have
thought so much about it yet.
My advice is clear: Small steps. The first step is model/view separation
for one toolkit. Honestly, I doubt that you can handle even that
task. But please: Don't try to do the big one in one go, or you'll end up
with a new 1.1.x.
Greets,
Asger
