From: Joaquín Cuenca Abela (cuenca@pacaterie.u-psud.fr)
Date: Fri Aug 02 2002 - 14:33:08 EDT
On Fri, 2002-08-02 at 20:19, Patrick Lam wrote:
> On Fri, Aug 02, 2002 at 02:34:05PM +0100, Tomas Frydrych wrote:
> >
> > We have got a problem in the mechanism that blinks the cursor. The
> > blinking is done via a timer and if we happen to be in another timer
> > context, the auto-update gets blocked until the timer-triggered code
> > finishes execution, and so the cursor does not blink.
> >
> > A current example of this is the background spell checker. To avoid
> > the cursor disappearing while doing the background checking, on
> > entry into fl_BlockLayout::checkSpelling() we flick the cursor off and
> > then flick it on again just before we leave. This results in erratic
> > blinking since the interval of the blink is dictated by the time it takes
> > to spellcheck the current block, which is considerable for long
> > blocks and virtually null for short blocks (load a reasonably long
> > document, say 50 pages, and watch the behaviour of the cursor
> > immediately after the loading of the document finishes).
> >
> > Now, I could improve the code in fl_BlockLayout::checkSpelling() so
> > that it does not flick the cursor more often than every 500 ms, but
> > that seems like treating the symptoms, not the problem. It would
> > seem to me that the proper solution would be to have the cursor-
> > blinking timer running in a separate thread, so that it does not get
> > blocked by other timer events in the main thead. This way we could
> > remove all the cursor-handling stuff from the spellchecking code,
> > and would not need to worry about the cursor if/when in the future
> > we implement other timer-driven stuff.
>
> Sounds good. More specifically, the fv_Cursor class should have a
> lock and a boolean (which is protected by the lock) indicating whether
> the cursor is on or off. The fv_Cursor class should also have a thread
> with a timer; its only purpose in life is to set the boolean every 500ms.
>
> We don't strictly need an fv_Cursor class, we just need a bool 'n' lock
yeah, you can still work in C...
btw, I don't get your lock business. What is your lock locking?
The only sane thing that it can lock (if we're speaking of a thread
lock) is the period between when the cursor starts to hide/show and when
the cursor ends to disapear hide/show. The "lock" that I mentioned in
my last email has nothing to do with that, it was just a "construction
is acquire" kind of object (like my XftFaceLocker).
How can foreign code show or hide the cursor in your scheme?
Start replying these questions in a sane way, and you end with Mike code
Cheers,
-- Joaquín Cuenca Abela cuenca@pacaterie.u-psud.fr
This archive was generated by hypermail 2.1.4 : Fri Aug 02 2002 - 14:39:15 EDT