On Wed, 13 Sep 2000, Allan Rae wrote:
> 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.
Well. If we don't want to mess with each gui toolkit internals and change
the menus only if they are visible then we have to update the status of
each menuitem regardless to its visibility. Its the way it is done in
gnome frontend and the good news is that it is quite fast (at least I
haven't seen any slowdown of LyX due to this constant update). I would
expect the same in KDE frontend code. However, we don't have any lists in
the menus yet in gnome.
> 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.
The patch included with this mail adds a new class to src/frontends. This
class (ListsTracker, any better name???) keeps the copies of TOC, LOF,
LOT, and LOA. If any of this lists changes, the corresponding update
signal is emitted. The update signal says just "Update using XXX list"
without any specific detail of the change. I've used this class to update
FormToc in Gnome frontend and it seems to me that we can remove "Refresh"
button in this dialog :).
The only problem which I see in current implementation is the place in LyX
kernel which should call the ListsTracker update method. I think that this
method should be called only if LyX has nothing better to do and only once
during this "idle" state. I am not aware know such a nice place in lyx
code => it will be nice if someone with better knowledge of lyx internals
will find such a place. At present, it is called in LyXView updateToolbar
and showState methods (makes lyx reallly slow).
Actually, I think we can extend the same technique to track the changes in
all LyX actions. However, taking into account that current implementation
works quite fast it might be not feesable now.
> 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.
to better code?
Marko
tracker.patch.gz
tracker.newfiles.tar.gz
