Re: Mouse pointer appearance problem

[Andreas Höschler]

 Fred Kiefer wrote:

> > It is merely a matter of X-Windows configuration and the environment 
> > you
> > have. On OSX the WindowServer process itself changes the cursor when 
> > the
> > active window stops responding for more than 2 seconds. On X-Windows 
> > I'm
> > sure there is one of the gazillion extensions to do it (or your 
> > session
> > manager is supposed to do that). WindowMaker doesn't take care of
> > changing the cursor's appearance automatically.
>
> I am not sure, if I understood the original request correctly. So let 
> me
> try to rephrase it and Andreas may correct me where I am wrong:
>
> We are talking about an application here that performs some potentially
> long running background task.

How do you define background here? For me background would be a 
subthread. That's not what I am talking about since the mainthread 
would be able to handle events (NSEvent,...) and everything would be 
fine.

I am talking about the normal event loop of the main thread.  A user 
clicks on a button that triggers the execution of a method that takes 
20s to complete. During these 20s the main thread is busy and can't 
handle events (at least no NSEvent).

Under MacOSX this is detected somehow and the display system converts 
the mouse pointer to a hour glass to give the user visual feedback.

> The application programmer doesn't want to
> set and unset the cursor for this specific action, which would be the
> most obvious solution for me.

Obvious IMHO would be to raise some kind of NSProgressPanel with an 
Abort button and executing the long running task in the background, 
giving the user feedback how much is finished and the opportunity to 
cancel the execution. But implementing that is too much work in most 
cases. You wouldn't want to do that for the many actions in the 
application that take between 3s and 60s, e.g. a complex database fetch.

> We are also not talking about the case
> where an application is stuck in an infinite loop. For the latter case
> (infinite loop) there is the _NET_WM_PING extension for X Windows, 
> which
> GNUstep partly supports. That way the window manager that supports this
> protocol could tell that an application stop to respond to events.
>
> This just leave us with the automatic detection of the case, where X
> events still get answered by the application, but where there is a long
> ongoing task.

Are X events answered while the main thread is busy with a time 
consuming task (no NSEvents are processed)? I would say no.

>  I don't see who a programmer could expect GNUstep or the
> windows system (or window manager) to handle this case. To both
> environments the application seems to be behaving normally.
>
> So what is it that I missed?

Regards,

  Andreas