Consider support for different cursor shapes

[marmarek]

https://groups.google.com/d/msgid/qubes-devel/20151226141511.GA95308%40cowbell.employees.org

Something I've noticed when using a web browser is that the cursor shape never changes,
always staying as a simple arrow pointer.

Having control over cursor shape it may mislead the user actions. While it shouldn't be a problem inside the same VM, it may be complex to do it right - to not interfere with windows of other VMs.
In short: without prior proper design, which would be simple and simple to implement, we don't want to have such feature, at least not by default.

But generally it is something to consider, because:

Cursor shape is a functional part of the UI, to the point of being critical
for certain apps like spreadsheets and drawing. If Qubes deems this a possible
source of confusion then it should explain the threat model for cursors
(having already done so for windows).

[mfc]

at congress it was suggested that cursor changing be allowed when a vm is in full-screen mode as a UX/security compromise.

[mfc]

at congress it was suggested that cursor changing be allowed when a vm is in full-screen mode as a UX/security compromise.

[bnvk]

While it shouldn't be a problem inside the same VM, it may be complex to do it right - to not interfere with windows of other VMs.

Getting the cursor to change within the same VM will be a significant UX improvement. A whole range of GUI apps like graphic design programs, IDE's etc... all suffer from this fixed pointer cursor which make simple things like re-sizing a window pane hard to do!

at congress it was suggested that cursor changing be allowed when a vm is in full-screen mode as a UX/security compromise.

Disallowing in full-screen, but allowing in non-full-screen mode, is still a significant UX improvement. However, if we are able to (and proceed) in doing that, we should try to trigger an overlay that communicates this to user when toggling between full-screen and non mode!

[bnvk]

While it shouldn't be a problem inside the same VM, it may be complex to do it right - to not interfere with windows of other VMs.

Getting the cursor to change within the same VM will be a significant UX improvement. A whole range of GUI apps like graphic design programs, IDE's etc... all suffer from this fixed pointer cursor which make simple things like re-sizing a window pane hard to do!

at congress it was suggested that cursor changing be allowed when a vm is in full-screen mode as a UX/security compromise.

Disallowing in full-screen, but allowing in non-full-screen mode, is still a significant UX improvement. However, if we are able to (and proceed) in doing that, we should try to trigger an overlay that communicates this to user when toggling between full-screen and non mode!

[v6ak]

In-window cursors

What about just providing a way to hide the cursor when it is on app's window? Custom cursors would be then implemented on top of this feature in the VM agent.

• + Simple design for dom0.
• + Cursors do not open a way to show arbitrary content outside of the window, as they are shown within the window only.
• - Having mouse at edge of some window would cause clipped cursor.

Cursor classes

Another option is having some predefined cursor types (e.g. hand, standard pointer, cross, …).

• + Simple design for dom0.
• + Cursors do not open a way to show arbitrary content outside of the window, as they come form dom0 and are trusted.
• + Unifies cursor set.
• + No issues with cursor at edge.
• - No support for custom cursors.
• - Might require some more effort for various systems in AppVMs.

[v6ak]

In-window cursors

What about just providing a way to hide the cursor when it is on app's window? Custom cursors would be then implemented on top of this feature in the VM agent.

• + Simple design for dom0.
• + Cursors do not open a way to show arbitrary content outside of the window, as they are shown within the window only.
• - Having mouse at edge of some window would cause clipped cursor.

Cursor classes

Another option is having some predefined cursor types (e.g. hand, standard pointer, cross, …).

• + Simple design for dom0.
• + Cursors do not open a way to show arbitrary content outside of the window, as they come form dom0 and are trusted.
• + Unifies cursor set.
• + No issues with cursor at edge.
• - No support for custom cursors.
• - Might require some more effort for various systems in AppVMs.

[marmarek]

On Fri, Jan 08, 2016 at 12:43:44PM -0800, Vít Šesták wrote:

In-window cursors

What about just providing a way to hide the cursor when it is on app's window? Custom cursors would be then implemented on top of this feature in the VM agent.

• + Simple design for dom0.
• + Cursors do not open a way to show arbitrary content outside of the window, as they are shown within the window only.
• - Having mouse at edge of some window would cause clipped cursor.

From the security point of view, I like this idea. But from the
usability POV I'm afraid it would be horrible. Even small lag of cursor
position would be really frustrating. In early Windows Tools we had both
cursors visible (dom0 and windows) and it was bad - VM cursor was
lagging, even when click events were delivered correctly.

Also some technical problem would be that cursor is not part of the
window composition buffer (this is what is directly mapped as window
content in dom0). So it would be quite complex at VM side - not
affecting security, but most likely performance.

Cursor classes

Another option is having some predefined cursor types (e.g. hand, standard pointer, cross, …).

• + Simple design for dom0.
• + Cursors do not open a way to show arbitrary content outside of the window, as they come form dom0 and are trusted.
• + Unifies cursor set.
• + No issues with cursor at edge.
• - No support for custom cursors.
• - Might require some more effort for various systems in AppVMs.

I know exactly nothing about cursor shapes in X11 protocol. If it is
possible to extract such information, it would be good. If not, that
would require some guessing (OCSR - "optical cursor shape recognition"
;) ), not reliable. Even if that would be possible only at some higher
level (like for GTK based applications), that would be still an
improvement.

Since it is possible to set cursor theme globally, I guess it is
possible to extract abstract information about desired cursor shape.

Quick duckduckgo returns this:
http://stackoverflow.com/questions/6751928/set-x11-cursor-to-arrow

Looks promising. Especially the part about setting it as window property

• it would mean that X server would handle switching its shape, so no
  need to do that manually on enter/leave events (which would be really
  fragile, probably a showstopper).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[marmarek]

On Fri, Jan 08, 2016 at 12:43:44PM -0800, Vít Šesták wrote:

In-window cursors

What about just providing a way to hide the cursor when it is on app's window? Custom cursors would be then implemented on top of this feature in the VM agent.

• + Simple design for dom0.
• + Cursors do not open a way to show arbitrary content outside of the window, as they are shown within the window only.
• - Having mouse at edge of some window would cause clipped cursor.

From the security point of view, I like this idea. But from the
usability POV I'm afraid it would be horrible. Even small lag of cursor
position would be really frustrating. In early Windows Tools we had both
cursors visible (dom0 and windows) and it was bad - VM cursor was
lagging, even when click events were delivered correctly.

Also some technical problem would be that cursor is not part of the
window composition buffer (this is what is directly mapped as window
content in dom0). So it would be quite complex at VM side - not
affecting security, but most likely performance.

Cursor classes

Another option is having some predefined cursor types (e.g. hand, standard pointer, cross, …).

• + Simple design for dom0.
• + Cursors do not open a way to show arbitrary content outside of the window, as they come form dom0 and are trusted.
• + Unifies cursor set.
• + No issues with cursor at edge.
• - No support for custom cursors.
• - Might require some more effort for various systems in AppVMs.

I know exactly nothing about cursor shapes in X11 protocol. If it is
possible to extract such information, it would be good. If not, that
would require some guessing (OCSR - "optical cursor shape recognition"
;) ), not reliable. Even if that would be possible only at some higher
level (like for GTK based applications), that would be still an
improvement.

Since it is possible to set cursor theme globally, I guess it is
possible to extract abstract information about desired cursor shape.

Quick duckduckgo returns this:
http://stackoverflow.com/questions/6751928/set-x11-cursor-to-arrow

Looks promising. Especially the part about setting it as window property

• it would mean that X server would handle switching its shape, so no
  need to do that manually on enter/leave events (which would be really
  fragile, probably a showstopper).

Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

[andrewdavidwong]

Comment/suggestion: https://groups.google.com/d/msgid/qubes-devel/29fb6fa1-1a64-310d-e52d-f21db7c1a4b7%40openmailbox.org

[andrewdavidwong]

Comment/suggestion: https://groups.google.com/d/msgid/qubes-devel/29fb6fa1-1a64-310d-e52d-f21db7c1a4b7%40openmailbox.org

[Joeviocoe]

Does this issue being labeled "Help Wanted" mean that it has the lowest priority and nobody from the dev team is working on it?

[Joeviocoe]

Does this issue being labeled "Help Wanted" mean that it has the lowest priority and nobody from the dev team is working on it?

[v6ak]

I don't think so. It has major priority and assigned milestone. It however seems undecided which way to go.

[v6ak]

I don't think so. It has major priority and assigned milestone. It however seems undecided which way to go.

[andrewdavidwong]

Does this issue being labeled "Help Wanted" mean that it has the lowest priority and nobody from the dev team is working on it?

It does mean that the Qubes devs do not expect to have time to work on it in the foreseeable future. However, "priority" is somewhat orthogonal. An issue can have a high priority even if the Qubes devs can't work on it. In that case, we really want someone to help! 🙂

[andrewdavidwong]

Does this issue being labeled "Help Wanted" mean that it has the lowest priority and nobody from the dev team is working on it?

It does mean that the Qubes devs do not expect to have time to work on it in the foreseeable future. However, "priority" is somewhat orthogonal. An issue can have a high priority even if the Qubes devs can't work on it. In that case, we really want someone to help! 🙂