Tommaso Cucinotta wrote:
Abdelrazak Younes ha scritto:
GuiApplication). On a related note we have
WorkArea::scheduleRedraw() that was created for the purpose of
delayed screen updates (scheduled to happen at next cursor blink).
I know. Actually, I cannot imagine a use-case in which delaying
screen redraw to next cursor blinking is really useful, probably you
can shed some light. I'm scared that, if the cursor is not blinking
because it is not visible, then you miss the redraw. If you need
delayed redraw, maybe a timer would suit your needs, wouldn't it ?
Not really. We use cursor blinking so as to not bother the user too much
when a graphic preview is generated in the background. Formerly (in
1.4.x), a redraw occurred as soon as an image or an equation was
converted for display. For some users that use the XYpic package, that
was very problematic because LyX remained frozen for a long time at
first load.
With the scheduleRedraw() solution, we don't redraw immediately but at
the next cursor blink, so that multiple redraw requests are merged into
a single one.
In my case of parHeights updates, I need something that is as fast as
possible without disrupting user operation, i.e. smth. that gives
priority to user operations and requests w.r.t. my background
activity, and the singleShot() semantics is perfectly what I need.
You are probably right.
I guess you can something similar for the scrollbar updates. In
general I prefer explicit rather than implicit.
Please, explain explicit vs implicit, thanks,
In general I prefer a method that explicitly describes what it does
rather than a too generic template based solution.
Abdel.
