On Fri, 8 Sep 2000, Marko Vendelin wrote:
>
>
> On 8 Sep 2000, Jean-Marc Lasgouttes wrote:
>
> > Let's face it: if you want to a tearable menu to change when the
> > cursor moves you will have to do _something_. What I would try to do
> > if I were to write the gnome frontend is first to build the menus at
> > update() time and see whether it causes performance problems. If it is
> > the case (and it might be), I would create the menus in set(), cache
> > the status of each lyxfunc used and, at update() time, change the
> > state of the entries of the existing menu (like for the toolbar) on a
> > case by case basis. For OptItems, one would have to insert/delete
> > entries in the existing menu (which should be possible). And with a
> > bit of double buffering, this should work well enough.
>
> The problem is whether menus and toolbars should have their own means to
> track the state of LyX actions or there should be some general way to
> inform about the change of the status to all interested parties. At
> present, we have to check the status of each lyxfunc used in the menus and
> toolbars during update. I think that this leads to duplicated code and to
> unnecessary CPU load.
You could start by grouping checks -- various menu entries aren't
available for readonly docs, different menu entries are available when no
buffers exist. That sort of thing. Then you can deactivate a bunch of
stuff based on the LyXFunc status (or was that a LyXAction enum I can't
remember).
> The other solution is to implement some kind of state machine which will
> completely describe the current state of LyX (which documents are open,
> cursor positions, TOC, LOF, LOT, LOA, bold on/off, emphasize on/off, ...).
That sounds like a terribly large and hideously ugly state machine.
The mother of all state machines?
> Every time when some state is changed this machine will notify all GUI
> elements (menu, toolbar, status bar, programs connected through lyxserver)
> by distributing a signal to all interested parties with exact description
> of the change (for example, title of section 3.1 is changed). I think this
> solution should lead to faster and cleaner code, but maybe I am wrong...
If you're going to distribute info like "title of section 3.1 has
changed" you are passing the wrong info -- or at least the wrong detail.
Pass "the current character attributes have changed" and "the current
paragraph attributes have changed" instead. In fact it would be possible
to edit the section3.1 heading and not generate either of these signals
since there would be no new info if you didn't change the attributes of
the text.
What I was envisioning (and I'm sure it's even mentioned in the gui-indep
doc which I still have to update) is that we have character and paragraph
based callbacks. These would be similar to the
Dialogs::updateBufferDependent signal except at character and paragraph
scope. We could make something like:
Signal1<void, CharacterStruct const &> updateCharacter;
That way anything that wants to know what the current characters
attributes are will connect to the signal and will get that info sent to
them when it changes (this means sprinkling activations of the signal
around the source).
For paragraphs, we could just send out what the current paragraph style
is. There may not be much else generally needed -- or just send a copy of
the ParaParams struct since that seesm to have everything in it.
Paragraphs will affect menus. Characters might affect menus (c-s menus
that included bold/emphasize etc. would be affected -- however since you
can't open a menu and move the cursor at the same time you would be better
off checking this explicitly (okay, tearoffs need signals, but regular
menus don't)) -- toolbars would be affected if they had bold etc. buttons
on them.
> The second advantage is that we can store the state of this machine during
> GNOME (KDE) logout and load it during login. Maybe something like this is
> implemented in LyX already and I just don't know anything about it or it
> has been discussed and rejected already. If true then sorry for spam.
You can instead store the current documents name and current cursor
position and get it all at startup when the document is reloaded.
I'll try to look at the menu code but I'm thinking it could/should be
handled via the Dialogs (just like another dialog -- we've had this
arguement before so don't tell me toolbars aren't dialogs. I've heard it
all before. We just reuse the same abstraction (show, hide, update)).
Allan. (ARRae)
