Wrapping mir::graphics::Cursor doesn't work as expected on a nested server

Bug #1513883 reported by Daniel d'Andrada
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Mir
Confirmed
Undecided
Unassigned
mir (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

I wrapped the_cursor() (mir::graphics::Cursor) and intercepted all move_to() calls, not forwarding them to the wrapped cursor.

I expected the cursor not to move at all, but it moves normally.

I call Cursor::hide() on initialization, but every time the nested server creates a new surface (for a new display that comes up), the cursor image property of that surface is set to default and therefore the host server shows the cursor when it's above that surface.

So at the very least I've to call Cursor::hide() again (or Cursor::show(someImage), every time such event takes place to ensure the cursor has the visibility/image state I want it to.

Clearly this interface is disjoint from what's happening.

If a nested server call Cursor::hide() or interceps all Cursor::show() calls, not forwarding them to the wrapped cursor, a cursor should never appear on the screen.

As alan_g said, mir::graphics::Cursor on a nested server is working more like a listener.

When a nested server wraps mir::graphics::Cursor, its intention is to achieve full control over the cursor state. But that doesn't happen. qtmir needs this behavior.

If Mir denies giving such control to a nested server, this API should be removed and a CursorListener should be added in its place (which would be of no use for qtmir, by the way).

Tags: cursor nested
description: updated
description: updated
Revision history for this message
Alan Griffiths (alan-griffiths) wrote :

I'm unclear what behaviour is intended, so I don't know whether this is a "poor naming" bug or a feature request to allow clients more control of the cursor[1].

[1] For a nested server to directly control the cursor implies a client API for doing so - which doesn't exist, and we may not want to support. The alternative would be to be able to upload parameters that allow the (host) server to implement the desired functionality.

Changed in mir:
status: New → Confirmed
Revision history for this message
Daniel d'Andrada (dandrader) wrote :

The problem with the "upload parameters that allow the (host) server to implement the desired functionality" approach is that I fear we end up solidifying into a C API ephemeral requirements coming from design.

The nested server being able to have full control over cursor state allow us to constrain all those Unity 8 specific UI design rules (such as screen edge barriers for mouse, that are overcome after some amount of pushing against them) into QML language, which is the perfect medium to codify such things.

tags: added: cursor nested
description: updated
Revision history for this message
Michał Sawicz (saviq) wrote :

Syncing task from Mir.

Changed in mir (Ubuntu):
status: New → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.