bug-gnustep
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]