> If you haven't already, and your comments
> seem to indicate you haven't, I'd certainly like you to take a look at
> the signal/slot approach I developed.
Indeed I had not. But I just got the 'lyx' branch from CVS and had
a really quick look. I mean 'really' quick, so please forgive me if I am
completely misinterpreting your code.
It looks as your approach is inherently different:
Let me call your code the 'push approach' and 'my' idea the 'pull approach'.
The amount and type of information kept is more or less the same in both
cases. However, when it comes to do some work, things are different:
The 'push approach' does all the work it is supposed to do *and* tries to
make the results visible. It updates lots of stuff quite close to the
user's nose and consequently needs an accurate idea of what the user is
staring at. In terms of linking this means you cannot seperate lyxfunc
from xforms, since lyxfunc needs to know how to inform the user and
consequently on how to grey-out menus, what popup to use etc.
However, the 'pull approach' is just lazy. It does the work it is
supposed to do and that's it. It does not even try to get a result
back. It rather provides (high level) access to the internal state.
Now the (G)UI has to decide when to extract results. If the (G)UI
decides that some re-display is necessary, it calls the apropriate
painter. The painter gets a request to 'paint the state', pulls the relevant
information out of the kernel and builts something the (G)UI is able
to display. (In 'my' project, the tk painter create a sequence
of tcl commands (for drawing lines etc), and the GUI just executes them.
So the GUI is *really* dumb, it always has to ask the painter what to do,
and the painter gives detailled instruction ('ok, listen: draw a line
from ... to ..., put a letter 'A' at ...' etc)
Although the total work done is the same (eventually any major change
gets drawn on the screen, and of course somebody has to implement it)
the pull approach has several advantages (at least I think so):
1. It is possible to seperate the kernel *cleanly* from the (G)UI. No
grey. Black and white.
2. Development is easier/faster.
a) You do not need to have any forms.so or
whatever installed to add and test kernel functionality.
b) You don't even need a C-compiler when you are writing GUIs in some
script language. If I have to add some GUI feature in our project
that does not use *new* kernel functionality (i.e. just GUI stuff
or something that can be expressed in terms of 'old' functionality)
I do not need to recompile.
3. The 'pull' approach might be faster in cases where no immediate
feedback is needed, e.g. when executing scripts. Just pipe a dozen
commands into the kernel and redraw once when you are done.
You'll need to get the 'lyx' branch
> from cvs and the code in question is mostly in Popups.h, Communicator.h
> and in frontends/xforms. Admittedly this is only the popups side of the
> gui.
This is certainly a good shot at independence from a specific *G*UI. You
try to unify graphical user interfaces (and this is a Good Thing ;-)).
I am aiming lower, at the
interface between any user interface and the 'kernel'. In the current
situation where there is just one UI (that happens to be a *G*UI)
this difference might not be obvious and if I think about it, both
could be combined:
xforms GUI2 GUI3
\ | /
LyX server non-graphical UI generic GUI (<-You are here)
\ | /
^---- generic UI ----------^
| (^- I am here)
kernel
> Take a look at the gui-indep document (which I need to update) on
> either the lyx-devel web site or my own. I'd certainly like to hear your
> feedback on this approach.
Ok... let's see:
The 'library of inline function that gather data and return a form'
or Communicator class
that you mention under 2.3 matches 'my' (it's really not my idea as
I mentioned in the last mail) painter at least conceptually.
I strongly support Alejandros suggestion to use an enhanced lyxcommand
for accessing buffer data. I admit some performance penalty by parsing
such a command, but it usually happens in an interactive environment and
the simple interface alone should make this worthwhile.
However, since I prefer the 'pull' over the 'push approach' I don't
think signals/slots are necessary. I think it's up to the GUI to decide
when to redraw (what part of?) a menu/canvas/whatever. Some GUI might
know that the math panel is hidden (or has decided not to implement
the math panel at all), so there is no need to tell it there was a
state change that might affect the math panel (the poor man's GUI might
not even know a beast called 'math panel').
The main idea is that the GUI is stateless. Whenever it see that is has
to draw the math panel, it has to ask the painter how to do it. And the
painter uses its access to the internal state to figure out how the
panel should look like *now* and return detailed instructions how to
paint it. The GUI specific painter can use every bleeding edge feature
the corresponding GUI toolkit supports. You do not have to restrict
youself to the lowest common denominator (although an abstraction into
this 'generic GUI' base class might be worthwhile).
> Also, does your modular system allow multiple painters in an executable?
Sure. A 'painter' just provides a view on a state. Maybe it should be
called an 'exporter' since it translates kernel data to some external
format. It does not modify
the state itself, so you can have as many painters for one state as you
like. And of course you could have a set of states (we don't need that,
but LyX surely should continue to support multiple buffers ;-) )
> Can they run simultaneously or is there some mechanism to choose between
> them?
Currently there is only the 'tk painter' and the 'plain text painter',
and they are used by different frontends since we this is all we need.
But conceptually there is no problem to have different painters in one
executable. I think, the Right Way(tm) would require this anyway: You need
to have a 'gui view', a 'dvi view', a 'ps view' etc. They all provide
just a view on some internal state.
> We've been focussing on supporting only one gui-toolkit in any given
> executable, ie. recompile/relink to support a different platform.
> Although it would be handy to support a gui and a tui in the same
> executable.
> ...
Depends. It makes the executable slimmer if only one frontend is linked
in at a time and it does not create dependencies on libraries you do not
need/want/have. Personally I am in favour of having a 'kernel library'
that contains all real functionality, and seperate UI objects that
are only linked against this kernel lib.
Andre'
--
Andre' Poenitz ...................... [EMAIL PROTECTED]
