GNOME Bugzilla – Bug 749178
quartz: Support css cursor names
Last modified: 2015-05-16 21:13:03 UTC
We want these to work across platforms, so do a best-effort approximation. We could do much better here by copying what webkit does.
Created attachment 303169 [details] [review] quartz: Support css cursor names
Created attachment 303396 [details] [review] Patch to implement most of the named cursors. Wrote up a patch to handle all but two of them. This was a fun one. The only two that are not handled are "busy" and "all-scroll". OS X doesn't provide these in their public or private APIs for some reason (and I wonder if OS X even has scrolling cursors at all). "busy" right now is equivalent to "progress"; "all-scroll" equivalent to "move" (since it looks alike). Note that according to WebKit the zoom cursors and one or two others are only available as of OS X 10.7.3. Hopefully this will work.
Review of attachment 303396 [details] [review]: Very cool, thanks a lot for doing this.
From what I figure from information on the net, the only way to trigger the official wait cursor on os x is to block the mainloop...
(In reply to Matthias Clasen from comment #4) > From what I figure from information on the net, the only way to trigger the > official wait cursor on os x is to block the mainloop... Do you mean the spinning beach ball? A way around that is to use another cursor as wait cursor, I have seen other applications do this (most notably LibreOffice).
yes, the beach ball. and yes, of course we can use another cursor (provided we can figure out how os x loads animated cursors)
Potential entry point: CGSForceWaitCursorActive()
(In reply to Pietro Gagliardi (andlabs) from comment #7) > Potential entry point: CGSForceWaitCursorActive() I am not sure if you should be going down that path. It's actually quite a tricky issue. Mac OS X does actually not have the notion of a "wait cursor" and therefore no such cursor is defined in the Cocoa API. In the user interface guidelines Apple strongly recommends to use UI elements like for example progress bars to indicate "waiting time" instead of using a wait cursor. The spinning beach ball is set by the window server in case an application cannot keep up with the event stream and or is not responding. Some people argue that the spinning beach ball often indicates "something is wrong". So there's not a cursor or method in the Apple APIs to which a wait cursor can be mapped. I think the best solution is to introduce our own wait cursor. As far as I can see, LibreOffice is doing exactly the same: http://cgit.freedesktop.org/libreoffice/core/tree/vcl/osx/saldata.cxx See for instance line 117 at time of this writing.
I agree with Kristian. If OS X treats the beach ball as special, we should respect that and bring our own wait cursor.
Very well. You can decide what to use as a wait cursor; if you apply the patch as is it will be equivalent to the "progress" cursor. Later I'll do a quick look into scrolling cursors; we might have to provide that one ourselves as well though :/ Not sure what WebKit does for that.
Thanks, pushed