[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NSApplication bug
From: |
Nicola Pero |
Subject: |
Re: NSApplication bug |
Date: |
Tue, 30 Oct 2001 05:19:47 +0000 (GMT) |
Hi Ludovic,
with this (and other private emails) I think you pretty much described why
the blinking cursor patch woudln't work ... excellent investigation.
I suggest, as a fix, that we call [NSApp updateWindows]; after marking the
cursor area as needing a redraw.
> Hi,
>
> In NSApplication: -run we have:
>
> ..
> while (_app_is_running)
> {
> IF_NO_GC(pool = [arpClass new]);
>
> e = [self nextEventMatchingMask: NSAnyEventMask
> untilDate: distantFuture
> inMode: NSDefaultRunLoopMode
> dequeue: YES];
>
> Where distantFuture == [NSDate distantFuture]. I don't think this does
> make sense since were are going to block if we don't receiving any events
> and that will prevent windows to get updated.
yes - correct - only I do think it makes sense :-)
if we don't get any event - then nothing it's happening.
if nothing is happening, there is no reason to update the windows :-)
and the less we update the windows, the better and faster.
> I found this bug while writing my 'blinking cursor' patch. The cursor
> won't be redrawn if you don't generate any event - which is quite wrong.
the blinking cursor is setting up its own timer to call its own selector
outside the event framework. I think it makes sense to assume that if you
fire timers to call you outside the event loop, you call [NSApp
updateWindows]; directly after marking anything as needing a redraw.
This would be a very efficient way of implementing it.