Re: NSCursor changes not sticking
Re: NSCursor changes not sticking
- Subject: Re: NSCursor changes not sticking
- From: Daniel Zitter <email@hidden>
- Date: Sun, 8 Jun 2003 11:36:50 -0700
Ah, this is for Camino. The situation you face is a bit clearer to me
now (yes, inferences were made based on the method name) and I may be
able to explain what you are seeing, at least at a high level. (Any
gurus out there are welcomed to make corrections where appropriate.)
The invisible hand you spoke of is the WindowServer, and it isn't
contradicting you by switching cursors, rather it is doing its best to
follow your conflicting wishes as defined by the various UI elements in
your application, which set the hand image when the cursor is over a
link or the i-bar image when it is over selectable text, or the arrow
image by default.
This mechanism is implemented with efficiency in mind. The various
rectangles defined by your application are set within the WindowServer
so that it may update the cursor without consulting your application
(fast!). I believe this explains why you see incongruities in the
debugger because the interesting bits are occurring in a different
process.
So, it is not a bug of the OS, but rather a feature.
I don't know of anyone who has reliably and efficiently subverted this
mechanism and I'll wager it isn't possible. (Setting the cursor every
nth of a second is probably not efficient and most likely won't work
100% of the time, such as when your app really is bogged down, because
I suspect the WindowServer will still be applying the cursor rectangle
logic.)
* * *
It may be helpful to note that it is the WindowServer which determines
when running the wait cursor is appropriate: an application is active
AND has been sent at least one event AND no events have been processed
within some number of seconds. This is a subtle point until one
realizes the client-server nature of the OS X event system. AFAIK, this
capability does not exist on any other GUI, and is quite powerful since
it works if an application is bogged down or if the whole system is
bogged down. Unless some low-level hooks are exposed (which I would not
advocate) an application programmer cannot match that.
So, it can be argued that an application-managed busy cursor is not
desirable in any Cocoa application since it is superseded by the wait
cursor.
That said, it seems that Camino will run its busy cursor not only when
it is doing work, but also when it is waiting for (more) data from one
or more net connections. I'm not aware of any precedence for
manipulating the cursor in such a case, but I would strongly question
the need for such behavior in a GUI as spiffy as Mac OS X. (Windows or
X, yes. OS X no.)
As an example of dealing with network delays without altering the
cursor, consider how Finder animates a progress indicator when you
access a network device which is slow to respond. (This will be the
only time I'd use Finder as the example for any GUI hints :-)
Anyway, since I've essentially ignored the root of your question, I'm
probably well over my $0.02 limit, so I yield. Good luck.
Dan
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.