Thanks very much for your prompt and surprizingly thorough discussion
Andre' (given your very brief skim of the documents and code involved).
On Tue, 16 Nov 1999, Andre' Poenitz wrote:
[...]
> > I think we should do both. The first, we should do for
> > the canvas area. This is already what is implemented in=20
> > the defunct LyX-devel branch with the abstract painter.
>
> Could well be you are right ;-) In 'my' project, the canvas is the main
> part, so the menu stuff is pretty basic. Maybe the 'the painter tells
> everything' method does not work at all for complicated dialogs...
The dialog scheme is argueably a mix of push and pull techniques. The
push part is just having LyXFunc activate the appropriate dialog, then the
dialog pulls whatever it needs via Communicator. We also have tripwires
that cause automatic updates of certain dialogs -- again via signals/slots
although these should perhaps be hidden further by a lyx-function.
Actually, we don't push much info to dialogs. It's mainly telling them
they need to update themselves because the current buffer has been
replaced by another or that its now read-only. And just about everything
that can cause this is done by the user via the user-interface.
I agree with Asger that we need a combination of the two. Welcome aboard
looks like you volunteered yourself for the canvas side of things ;-)
> Anyway, all the time I wonder how the development should proceed. Moving
> around large chunks of code in a code base full of dependencies is No Fun...
That's why we are breaking things into modules (again). After the lessons
of the original development branch we now have a chance do a better job
this time.
Allan. (ARRae)
