View Source being updated more often than necessary?

[Scott Kostyshak]

When "Automatic update" is checked, the source view updates whenever I
move the cursor. I think it would be nice if this did not happen when
moving the cursor within the same paragraph (when "Current paragraph"
is selected), unless we plan on tracking where in a paragraph the user
is and scroll accordingly. Similarly, when "Complete Source" is
selected, we should not update unless there's a change to the
document.

I'm guessing this is inefficient but also annoying because if I had
scrolled on the source window it will jump back if I move the cursor.

Does anyone else think this is something worth addressing? If so, any
ideas on implementation?

Inside of ViewSourceWidget::updateView is it possible to tell whether
it was called because of a cursor movement or because of an
insertion/edit? For example, can I just check whether the buffer is
dirty and then compare the beg and end CursorSlices to their previous
values to see whether we have changed paragraphs since the last time
updateView was called?

Scott

[Richard Heck]

Post by Scott Kostyshak
When "Automatic update" is checked, the source view updates whenever I
move the cursor. I think it would be nice if this did not happen when
moving the cursor within the same paragraph (when "Current paragraph"
is selected), unless we plan on tracking where in a paragraph the user
is and scroll accordingly. Similarly, when "Complete Source" is
selected, we should not update unless there's a change to the
document.
I'm guessing this is inefficient but also annoying because if I had
scrolled on the source window it will jump back if I move the cursor.
Does anyone else think this is something worth addressing? If so, any
ideas on implementation?

There are all sorts of inefficiencies in how the dialogs, etc, are
updated. I'm not sure if
it's best to address them one at a time, or else to try to figure out
some global way to deal
with it. Of course, the latter is a lot harder.

Post by Scott Kostyshak
Inside of ViewSourceWidget::updateView is it possible to tell whether
it was called because of a cursor movement or because of an
insertion/edit?

I don't think so. You'd need to get this information during the
dispatch, I think, which is
likely to make this kind of hard. I think in this case, the ViewSource
window gets updated
as a result of a call to GuiView::updateDialogs, which is coming from
GuiView::restartCursor,
called from GuiApplication::updateCurrentView, which itself gets called
at the end of the
main GuiApplication::dispatch routine. The dialog update happens because
the flag
saying we need to run updateBuffer got set. Which it should as a result
of resetting the
cursor since e.g. the TOC needs updating to reflect the new position.
Indeed, not all dialogs
need updating, but we don't have such fine-grained information.

Richard

[Scott Kostyshak]

Post by Scott Kostyshak
Inside of ViewSourceWidget::updateView is it possible to tell whether
it was called because of a cursor movement or because of an
insertion/edit?

I don't think so. You'd need to get this information during the dispatch, I
think, which is
likely to make this kind of hard. I think in this case, the ViewSource
window gets updated
as a result of a call to GuiView::updateDialogs, which is coming from
GuiView::restartCursor,
called from GuiApplication::updateCurrentView, which itself gets called at
the end of the
main GuiApplication::dispatch routine. The dialog update happens because the
flag
saying we need to run updateBuffer got set.

Thanks for the detailed explanation, Richard. I understand more why it
works the way it does. I think this would be too ambitious of a
project for me at the moment but maybe I'll come back to it.

Which it should as a result of
resetting the
cursor since e.g. the TOC needs updating to reflect the new position.
Indeed, not all dialogs
need updating, but we don't have such fine-grained information.

Is there an example of a dialog that needs to be updated even when the
cursor does not change paragraphs? Even if not, there might be one in
the future though. Would a virtual in the Dialog class make sense? The
virtual could return an enum that says under which circumstance
updateView should be called.

Scott

[Richard Heck]

Post by Scott Kostyshak

Which it should as a result of
resetting the
cursor since e.g. the TOC needs updating to reflect the new position.
Indeed, not all dialogs
need updating, but we don't have such fine-grained information.

Is there an example of a dialog that needs to be updated even when the
cursor does not change paragraphs? Even if not, there might be one in
the future though. Would a virtual in the Dialog class make sense? The
virtual could return an enum that says under which circumstance
updateView should be called.

The TOC is an example. We reset which is the "active" item.

It wouldn't be hard to add members to DispatchResult that would tell us
what sort of thing
has happened. The main issue is how to get the information to the
dialogs about whether the
paragraph has changed, or whatever. If you look at updateDialogs, it
just cycles through the
dialogs and updates them all. So it needs that information, and we have
to figure out how to
get it to it.

Richard

[Scott Kostyshak]

Post by Richard Heck

Post by Scott Kostyshak

Which it should as a result of
resetting the
cursor since e.g. the TOC needs updating to reflect the new position.
Indeed, not all dialogs
need updating, but we don't have such fine-grained information.

Is there an example of a dialog that needs to be updated even when the
cursor does not change paragraphs? Even if not, there might be one in
the future though. Would a virtual in the Dialog class make sense? The
virtual could return an enum that says under which circumstance
updateView should be called.

The TOC is an example. We reset which is the "active" item.
It wouldn't be hard to add members to DispatchResult that would tell us what
sort of thing
has happened. The main issue is how to get the information to the dialogs
about whether the
paragraph has changed, or whatever. If you look at updateDialogs, it just
cycles through the
dialogs and updates them all. So it needs that information, and we have to
figure out how to
get it to it.

OK, thanks for the info, Richard.

Scott