Re: NSCursor changes not sticking
Re: NSCursor changes not sticking
- Subject: Re: NSCursor changes not sticking
- From: Jeff Harrell <email@hidden>
- Date: Mon, 9 Jun 2003 02:08:00 -0500
I know you're not looking for opinions here, Andrew, but if you're
interested I'd like to throw a nay vote your way. While your
justifications for why a mixed-state cursor is a good thing make
perfect sense, my personal and completely unsolicited opinion would be
that it's unnecessary, and needlessly complex. In particular, the whole
underlying paradigm with the Mac OS X cursor is that it reflects
information about the thing being pointed at at the time: a hyperlink
gets a hand cursor; selectable text gets an I-beam cursor, and so on. A
wait cursor doesn't reflect any bit of status about the UI element
being pointed at, but rather the status of the underlying application
or window. I think that runs counter to the established Mac OS X
convention, albeit in a pretty nit-picky way.
If you were taking a poll--which I understand you are definitely not--I
would vote enthusiastically no on the question of a proposed busy
cursor such as you've described.
That's what ya get for having this exchange in open forum. ;-)
On Sunday, June 8, 2003, at 11:07 PM, Andrew Thompson wrote:
On Sunday, Jun 8, 2003, at 14:36 America/New_York, Daniel Zitter wrote:
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.)
Interesting. That would certainly explain the symptoms. It is
interesting that it seems to happen regardless of where the cursor is
on the screen, inside the Window or out. From looking at the source
code I doubt Camino is setting up so many cursor rects explicitly. I
wonder if the WindowServer assumes you want the standard arrow cursor
if you don't specify anything else? If that's the case though, why
have -[NSCursor set] at all? It would never do anything useful as the
WindowServer would always be clobbering whatever you chose to set.
The rects thing also doesn't explain why it works flawlessly in my
small test application, or why it works if I don't use an NSTimer to
set the cursor. I think you're right, the WindowServer must be the
invisible hand, but I don't know why it only sometimes gets involved.
Incidentally one can work around this by defining your cursors using
good old fashioned CURS resources and calling ::SetCusor() from > Carbon.
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
Well, evidently the design does take a cue from Windows, which has a
mixed state cursor. Ultimately the problem I'm been trying to solve
here is to get the cursor to animate. Whether its displayed at all is
another decision.
On that subject I can observe 2 things: no one's complained in the 2
years since that (non animated version of the cursor) went in, and
secondly I've found as I use it its very useful to have a central
visual indication as to whether the page has loaded. Specifically the
throbber (the animation in the top right) is nice to have, but
ultimately it takes up a lot of space and its questionable whether its
effective. I believe neither Camino nor the new Mozilla Firebird
browser shows the throbber by default. In short, the throbber is in
the corner in my peripheral vision, so I don't really see it. The
cursor is pretty much where I find myself looking, so I personally
find it effective. It warns me that application may not be fully
responsive so I may need to slow down and take some care with the
controls.
Thanks for the help.
AndyT (lordpixel - the cat who walks through walls)
A little bigger on the inside
(see you later space cowboy ...)
_______________________________________________
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.
_______________________________________________
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.