Christian Ridderström wrote:
> What is this controller you're talking about all the time... my
> controllers usually stay in the robot.. not the document processing
> software :-)
>
> Seriously.. could someone (please) write a few lines explaining what
> it's about, and point me to the relevant source?
See the patch ;-)
Seriously, things will be much, much easier to understand once this patch is
applied. But in brief:
We have tried to implement what is known as a Model-Controller-View split of
the code in LyX. The LyX core is the Model. It defines everything needed to
manipulate your document (what LyX calls a 'buffer'). The GUI-independence
project started life as a desire to move GUI code out of the LyX core. This
core would issue a series of commands to a 'black box' saying 'Open a
dialog' or 'draw this Pixmap'. The core itself would have no idea what was
actually doing the drawing, (or indeed if this drawing took place at all.)
In turn, the 'black box' would request information from the LyX core to
complete the task it was expected to perform.
Essentially, what I'm describing is an API for communication between the LyX
core and its frontend.
As things evolved and interest grew in supporting more than one frontend, it
became clear that the communication between a dialog and the LyX core was
independent of the GUI toolkit used to implement the dialog. That is, the
various dialogs could be written to have a 'Controller' and a 'View',
ultimately passing the altered data back to the lyX core or 'Model'. Asger
introduced us to this MCV concept and I tried to implement it a couple of
years ago.
These 'controllers' are to be found in src/frontends/controllers. (At the
moment the code is pretty impenetrable; Friday's patch changes that I
hope.) The framework has made it very easy to create dialogs for Qt with
similar functionality to their xforms cousins. Ie, to write different
'Views' for dialogs with a common 'Controller'.
The downside has been that it often feels that, till now, only I have
understood the controller code ;-) That's because I was learning as I was
going and the code is a nasty, nasty mess of derived classes and templates.
It also does things that it shouldn't, like alter insets direct, rather
than pass the proposed changes to the LyX core, requesting that the changes
be made.
So, my patch attempts to make the code in src/frontends/controllers
understandable to a wider audience and also pass control over what actually
happens to your document back to the LyX core where it really belongs.
> About the source code... is realistic to print it (printing on both sides
> and using psnup -4)?
You be the judge:
$ files=`find src -name "*.[Ch]"`
$ echo "$files" | wc -l
1550
$ wc -l $files
...
250109 total
Personally, I would say that 1550 files and quarter of a million lines of
source code was too much...
> I'm guessing one of the things the controller do, is to take
> requests from the GUIs to modify the document. Is the controller
> bascially the thing that has a queue where events and requests are
> placed, and it's the controller that parses these?
Yes. Note finally that we have succeeded fully in splitting the LyX core
from the frontends. That is the split 'Model', 'Frontend' is complete. In
turn, it is theoretically possible to split the 'Frontend' code into a
'Controller' and a 'View' for each of the different dialogs, for the
Menubars, for the Toolbars and for the main LyX screen itself. How could a
job we have made of this separation is a matter for debate and is an
on-going process.
--
Angus
