Re: GUI updates do not show even from separate thread

[Fred Kiefer]

Thank you to both you and Sebastian, switching to passive mode made the 
application work. This really should be the default mode.
Now I see that the transfer happens in a background thread while the UI changes 
are made in the main thread, just like it should be. Very impressive, I will 
need some more time to admire this code.

Now I see the wrong behaviour just like you described it. The progress bar gets 
updated but only one or two times whereas the download constantly provides the 
progress information. I am going to add some debug output to the NSWindow 
autoupdate code to see, whether this gets called. Most likely this isn't the 
case, meaning we have a problem with the runtime loop. Maybe we need to add the 
autoupdate to more event modes or there is an issue with having two run loops. 
Some more investigation is needed.

Fred

On the road

Am 06.07.2016 um 12:58 schrieb Riccardo Mottola <address@hidden>:

> Hi,
> 
> Fred Kiefer wrote:
>> Hi Riccardo,
>> 
>> I tried to inspect this issue, but already failed in getting FTP.app to work 
>> against ftpmain.gnustep.org. Are there any ftp sites out there where you 
>> know the code is working correctly.
> 
> That's bad! It works for me right with ftp.gnustep.org which is my favourite 
> test use case!
> In "preferences" what connection mode is set? Port and Passive are the ones 
> that usually do work and both work for me with GNUstep. standard is often 
> blocked or misinterpreted by routers and firewalls.
> may you change to Passive or vice-versa and see if it works?
> 
>> Next I looked at the code and failed to see the point where a background 
>> thread for the file download gets started. There is only one reference to 
>> NSThread in the code and this is at the startup. No idea what this code is 
>> doing there.
> 
> The "connection" is started in a background thread and then lives on in all 
> various operation, not just the single download operation. At least, I think 
> that was my intention many years ago. That way, for example, recursive 
> downloads operate in a single worker thread and don't spawn N threads, N 
> being the depth !
> 
> How to know if I really have 2 threads and the code is not buggy?
> I set a breakpoint in retrieveFile and gdb "info threads" shows me two 
> threads and execution being in #2. I hope this is enough for a proof.
> 
>> 
>> In AppController setTransferProgress: you are most likely referring to the 
>> line
>> [progBar setDoubleValue:percent];
>> This should indeed update the progress bar the next time GNUstep redraws the 
>> window. And even if you don't use a background thread the NSRunloop trick 
>> should be enough to trigger this. Without being able to get this working it 
>> is hard to say anything more. What you could try to find out is whether the 
>> drawRect: method of the progress indicator gets called at all. It could be 
>> that it is in a state where it just doesn't draw anything.
> 
> I do not only update the progress  bar, but also the text fields showing 
> transferred bytes and speed. Those to do not get updated too. I suppose thus 
> that it is not just the progress bar component.
> 
> Riccardo