On 11 Sep 2000, Jean-Marc Lasgouttes wrote:
> >>>>> "Allan" == Allan Rae <[EMAIL PROTECTED]> writes:
>
> Allan> You could start by grouping checks -- various menu entries
> Allan> aren't available for readonly docs, different menu entries are
> Allan> available when no buffers exist. That sort of thing. Then you
> Allan> can deactivate a bunch of stuff based on the LyXFunc status (or
> Allan> was that a LyXAction enum I can't remember).
I was in fact referring the possibility of just passing an enum as the
parameter to a signal. I thought that enum was called status.
> Have you ever read LyXFunc::getStatus()? It does exactly that, if I
> understand you correctly.
Yes but it shouldn't be doing that (menu changes etc.) unless in a
gui-indep manner. And then only if it needs to be done. How often does
it [de]activate stuff now that isn't visible on the screen and could be
checked as its built?
IIRC LyXFunc::status was mostly occupied with changing read-only stuff and
deciding what output/export stuff should be set to.
> Allan> I'll try to look at the menu code but I'm thinking it
> Allan> could/should be handled via the Dialogs (just like another
> Allan> dialog -- we've had this arguement before so don't tell me
> Allan> toolbars aren't dialogs. I've heard it all before. We just
> Allan> reuse the same abstraction (show, hide, update)).
>
> Yes, it is (as I already mentionned) certainly possible to use signals
> to at least connect GUI-I menus to their frontends. This would
> certainly be cleaner than using a Pimpl. However, I doubt it would be
> worth bending their semantics to fit the Dialogs framework... We could
> maybe have a common framework for toolbars and menus, though.
If I ever find time I'll rewrite it all the way it should be done ;-)
There shouldn't need to be much if any bending. As Marko pointed we could
end up with a TOC in a menu, a toolbar and a dialog. They all still need
updating. I'd prefer that they were triggered by the same update()
signal. A TOC menu that isn't visible, and a dialog that is closed won't
be connected to that update signal so we won't be wasting time updating
something that the user can't see. The toolbar TOC is likely to be just a
copy of the menu TOC (Marko?) so it would only need to be updated when the
user opened it (it's not a tearoff as well is it?). A torn-off menu and a
dialog would both be connected to the signal and need the same update
info. Probably shouldn't pass "section3.1: The new title" that is likely
to difficult to do anyway (maybe get away with passing a Paragraph
const&), just say "update yourself" instead.
So we can at least share the same update signal between the different
items.
Where do you activate that signal from? We should hopefully only need one
or two places in the kernel for any given signal. The cursor movements
should only need one place for example. The paragraph update signal could
probably be in the same place but with a test to see that we have crossed
a paragraph boundary. Triggering an updateTOC signal should be possible
from some common area of code -- everything that causes a change to the
contents of a paragraph will ask for a redraw of the paragraph won't it?
Then put the update signal there with a test to make sure the paragraph
would appear in the TOC to avoid unnecessary calls.
I'm not sure I like the way this thread is heading -- we could end up with
a big ugly mess if we don't try to share more stuff between similar things
like menus, toolbars and dialogs.
Allan. (ARRae)
