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 [EMAIL PROTECTED]
