Review of attachment 154298 [details] [review]:

Looks OK to me.  Though I would write the commit message as:

"Allow plugins to set the cursor."

Review of attachment 154298 [details] [review]:

From IRC earlier:

<zaspire>       owen: Is it a good idea to make meta_screen_set_cursor public?
<owen>  zaspire: Hmm, I think making it public would have trouble with interference with startup notification
<owen>  zaspire: what if you setting it from gnome-shell overlaps with startup notification setting it?

To elaborate, if you set the cursor using meta_screen_set_cursor() then the a startup notifications happens then the cursor setting will be overwritten.

What is the use case here? If we want to change the cursor for something in the overview, we probably want to change the cursor of the overview window not of the root window; then when we are done we can unset the cursor and the root window cursor (what meta_screen_set_cursor sets) will be shown again.

(In reply to comment #2)
> we probably want to change the cursor of the overview window
Do overview have own window?

> then when we are done we can unset the cursor and the root
> window cursor (what meta_screen_set_cursor sets) will be shown again.
May be add function like push_cursor/pop_cursor?

How about an API like:

push_busy_cursor ()
pop_busy_cursor ()

Where push_busy_cursor does:

if (cursor == BUSY)
  busy_cursor_level++;
else if (cursor == default)
  set_cursor (BUSY)
  busy_cursor_level = 1;
else
  return

and pop_busy_cursor:
if (--busy_cursor_level == 0 && cursor == BUSY)
  set_cursor (default)

(In reply to comment #4)
> How about an API like:
> 
> push_busy_cursor ()
> pop_busy_cursor ()

What about other types? (For example: bug 607821 need META_CURSOR_MOVE_OR_RESIZE_WINDOW).

I suggest make cursor stack with api:
id push_cursor(type)
pop_cursor_by_id(id)

Also modify set_cursor to use this api.

(In reply to comment #3)
> (In reply to comment #2)
> > we probably want to change the cursor of the overview window
> Do overview have own window?

If you set a cursor on the Clutter stage window, that should be the cursor that is seen when the pointer is over the overview or other reactive elements of our user interface. (The stage window always takes up the entire screen, but has an input shape so that mouse clicks are let through to windows when we aren't in the overview. The cursor of the stage window will be the cursor seen when the pointer is over the input shape of the stage.

Stacks are better than blindly overwriting, but still would result in a busy cursor replacing the drag cursor if a startup notification occurred while you were dragging a window between workspaces.