Re: NSProgressIndicator movement inside a loop

[Fred Kiefer]

Richard Frith-Macdonald wrote:
> Yes ... the reason this is all working is that the -incrementBy: method 
> does not actually do
> any drawing.  It just marks the progress indicator as needing display 
> (calling -setNeedsDisplay:).
>
> Fortunately, -setNeedsDisplay: checks which thread it is executing, and 
> if it's not in the main thread, uses 
> -performSelectorOnMainThread:withobject:waitUntilDone: to call itsself 
> in the main thread.

I would like to stay on this topic for a little bit longer, although the 
original problem should be resolved by all of us coming to the same 
conclusion.

Why do we need to make sure GUI methods only get executed in the main 
thread? As far as I see for two reasons:
One is that GSCurrentContext() will only work there, as the context is 
held in a thread specific storage (similar things apply for 
GSCurrentServer() I wont go into details there). Here it would seem 
worthwhile to extend this helper function to report on errors. When the 
context is not set for the current thread we should check if we are on 
the main thread, if so report that the backend hasn't been initialized 
and if we aren't in the main thread report that the surrounding method 
should be called on the main thread.

And the other reason is, that this way we get an automatic 
synchronisation of all GUI calls. If calls may only be done by one 
thread, we are always on the save side. This is fine for me, but we 
really should think, if this is the most efficent way to synchronise 
simple access. For example in [setNeedsDisplayInRect:] we would need to 
make sure that the view hierarchy does not change in any way, while 
executing the method. For this we would need a global lock, so the 
thread trick doesn't look that bad to me.

Just thinking for myself

Fred