Re: GUI updates do not show even from separate thread

[Richard Frith-Macdonald]

> On 12 Jul 2016, at 10:43, Fred Kiefer <address@hidden> wrote:
> 
> I made some progress here although I am still not satisfied with the
> result. It turns out that
> 
> [[NSRunLoop currentRunLoop] runUntilDate:[NSDate distantPast]];
> 
> is a NOP with current GNUstep base. It may have been different some time
> ago, but now when the limit is in the past this method returns immediately.
> Richard could you please confirm that this is the intended behaviour?
> 
> If we replace that line with
> 
> [[NSRunLoop currentRunLoop] runMode: NSDefaultRunLoopMode
> beforeDate:[NSDate distantPast]];
> 
> we get the expected behaviour. You could use this code for now to get
> your application working correctly under GNUstep. But on MacOSX none of
> this hacks should be needed. Riccardo, could you please try to run FTP
> with that runloop line removed on a Mac and report back whether the
> progress bar gets filled smoothly?
> 
> To me this looks like we are having an issue with background threads
> that run their own runloop. As this is an area where I am not very
> familiar it would be great if Richard could take over.

It would help to have more regression tests ... we have a lot of code written 
to match the documented behavior, and where that can be interpreted in 
different ways we get differences between OSX behavior and GNUstep.
I added a few testcases for this and tried it out under OSX, and it seems 
-runUntilDate: should cause timers to fire even when called with 
nil/distantPast.  I'v modified svn trunk to do that.
It also seems that -acceptInputInMode:beforreDate: should fire timers (whether 
there is input available or not) ... but fixing that would be a bigger change.