> I think this patch should go in! This is something that I wanted to
> do a long time ago, but never had the time for. Also, hopefully
> that will keep Andr=E9 morale up to send in lots of other pathces ;-)
Well, I don't think you know what you are saying ;-}
*grin* erm...
Since it is Friday I think I could try to start a discussion.
At work we have a smallish software project (about 25k lines) that's going
on for... about six years now (i.e. it was already there when I started).
The project was handed over from developer to developer quite a few times
and now I am more or less the only one really working on it (part time of
course).
One thing I *really* like is the modularity of the whole stuff.
Admittedly, this is the work of my predecessor, but it is nice nonetheless ;-)
You could throw in a new module in five minutes (not joking!) including
incorporating it into the gui. I believe LyX development could benefit
much if there were a similar structure.
So what is so special? Actually there was only one basic rule
"Keep it small, simple and general" with a couple of implications such as
- one interface - one function or
- no handling of special cases if some kind of abstraction could be found.
The resulting structure is something like that
Gui (Tcl/Tk) Commandline-interface
\ ^ / ^
\ \ / /
.... \ "Tk-Painter" / "CUI-Painter"
v \ v /
generic user interface (undo/redo...)
|
|
base library
/ | \
Algo1 Algo2 ..... Algon
It works as follows: By clicking/typing in the gui you tell the gui to
perform some action. This get translated into one ore more basic
commands that are handed down to the generic UI as a single string.
This generic UI is responsible for keeping a state (in case of LyX
this would be the buffers, undo/redo stuff etc). It furthermore converts
the command string to calls into the base lib, and executes these calls,
usually resulting in a change of the state.
There is only one command that has a reponse other than an indication of
errors. When this command 'draw' is called, some UI specific action is
performed. In case of our standard Tcl/Tk-Gui the tk-painter is used
to transform the state into a list of Tcl-instructions. The Gui now
just evaluates these instructions, and if everything went well, the
canvas now shows a picture of the current state (in our case graphs,
if this was used in LyX this would be the visible bit of the current buffer)
The commandline interface does exactly the same, of course the painter
is much simpler in this case, it just produces some text describing the
current state. But this is a way to achieve GUI
independence: Everything up to and including the generic UI does not
need to know anything about GUIs, and everything above the generic UI
does not know anything about the objects that are handled below:
The GUI only knows how to construct commandlines, when to call
'draw', and how to execute the resulting sequence of drawing commands.
If you don't like Tcl/Tk as GUI - no problem. All you have to do is to
to build the actual GUI as a collection of menus etc., implement the
single 'kernel call' and implement a painter. It's more ore less a
client-server-architecture...
So what I am suggesting?
The 'buffer-execute' facility of LyX is really close to the
command-string thingy in our project. If this facility would be declared
as the Right Way(tm) to access 'kernel' functionality (like inserting
characters, running LaTeX etc) some degree of modularization could be
obtained at almost no cost (parsing 20 character strings in an
interactive environment is really 'no cost')
I would even volunteer to work on it, but of course I will not start
if all of you think that this is completely useless ;-)
Any opinions?
Andre'
PS:
> Now, let's be a little productive instead, huh?
I knew it was Friday ;-)
--
Andre' Poenitz ...................... [EMAIL PROTECTED]
