Re: GUI updates do not show even from separate thread

[Fred Kiefer]

Am 12.07.2016 um 13:47 schrieb Richard Frith-Macdonald <address@hidden>:

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

Thank you Richard,

with that change the old code works again as expected.

Fred