Explore options to signify VM ownership of windows/widgets/functionality, other than color

[ninavizz]

Problem

VM ownership is clearly a very important thing in Qubes. 20% of all humans are estimated to have some degree of color-blindness. Disambiguating between green, red, and blue, is very difficult, for most of that crowd. Likewise, there are currently only 8 colors—and it's a known cognitive limitation that even if more colors existed, the human brain can only track so much.

Solution

Let's use this Issue to track the task of finding a better solution than color!

For this Task, no code allowed—just explorations of how to do this well via mockups, critique, Invision prototypes, and feesability insights w/ possible code explorations.

Cross-referenced Issues/Discussions

• Tray icon in KDE5 doesn't have colorful border #2042

[SaswatPadhi]

For windows, the titlebars also have a [AppVM] prefix along with the colored border.

But yes tray icons, popups (such as notifications etc.) seem to signify ownership only via color. For this reason, in all my VM scripts I also print qubesdb-read /name before the actual notification messages.

[hexagonrecursion]

It's not just popups. Some apps use windows with an "override redirect" flag to implement fullscreen mode, menus, context menus, popups and possibly other features. Right now the ownership of an override redirect window is signaled via a 2-pixel color border. Until someone figures out a better way to handle the flag we have to have some way to signal ownership of a rectangle that a qube can put anywhere on the screen, make as big or small as it wishes and that the user does not expect to have a title.

[ninavizz]

Sooo... backing-up from the intent of the colored windows feature, an important consideration I feel the current approach and many contemplations of improvement have not considered, are the limitations of Human Working Memory. Limitations that could never, ever meaningfully track security concepts associated to dozens of "threat classes" of VMs.

While I have not had the time to dig deeply into this, it has stood-out to me as a consistently absent reality-check that is badly needed to better align the reality of human cognition with the goals of "give meaning to everything so we can know everything" that Qubes has been built with.

Even if/when everything is clearly and consistently labeled in an appealing fashion: the human brain has its limits with how and what it can meaningfully track. At what point is it sought to allow a user to track all the things versus to discipline users to only track what they can meaningfully work with? How to do that, is a gnarly design problem I would actually like to get funding to properly tackle within Qubes.

This article from Scientific American provides a good overview to the concept of Working Memory. The theory's Wikipedia article is here.

Quoting Jeff Goldblum's character from Jurassic Park: just because you can (build something a certain way) doesn't mean that you should. Which is rarely a straight-forward conundrum to resolve, because there will always be compelling reasons to build something. The should has to consider effectiveness within limitations, however—and with the goals of this central attribute to Qubes, the greatest limitation is the brains of new and experienced users, alike. Not the technology itself.

[rootnoob]

1) Custom icons for the VM
1.1) Which the user can then choose to display in the window border (via XFCE settings, as per screenshot), and ALSO in the window menu. Some users may assign a custom icon and a custom overlay. And they don't need the custom icon in the window menu. (Window menu refers to window menu on the XFCE panel).

So you could display the VM specific icon here.

And it would show up here, instead of the stock generic icons which don't differentiate. (The icon would be subject the same as the current icons, and could be overlayed with a colour or custom SVG/transparent gif style as per 3).

2. Option for a 'dashes' border option. So I could have two qubes on a blue colour, and one qube - say my ultra sensitive qube would be blue but dashes (i.e: colour, transparent, colour, transparent).

3. Custom SVG/animated 'wallpaper' options. Not only custom colours, as already mentioned. But something e.g. images attached (rainbow/wallpapers). The rainbow option attached is a poor example, but I'm thinking some sort of reflective/glossy looking rainbow coloured style which moves/goes through the colours diagonally. This would work exactly as now, applied as an SVG style (or gif overlay), on the icons and on the window borders. The wallpaper is an example of a repeating logo, in reality e.g. the kali logo or something related which could then be overlayed as a single logo or repeating on the icons, but repeating on the window border (single icon on the appicons may be pointless, as it eseentially duplicates 1) in terms of recognisability functionality, it ceases to be an overlay in purpose then if it's not a background).
   
   

4. Let the user customise it. @deeplow on the forum mentioned that changing colors manually is difficult because they are hardcoded. please make them dynamic. Add a warning if you need to, keep the stock options clear, but please let us customise our install easily.
   
   

5. Let us display the VM name of the application in the XFCE window-menu on the panel. I would like to make it double height, (as picture displays), and be able to show the VM name on the top. The current color limited options and just the app icons can make it confusing, I am only clear which VM I'm using by actually reading the name on the window border, quite irritating.
   Then, in the XFCE settings pictured above, (where you can move around the text/icon/min maximise etc options, add a second row to be able to add the vm name above the existing app icon and window text in the window-menu on the panel).
   
   See above ^ It doesn't matter how tall it is, you can't display the VM name, very irritating, can't trust the limited colours and appicon alone.

[deeplow]

I don't think this one was implemented yet @andrewdavidwong. What has changed sinced? VM ownership is still represented by color mainly and those colors are rather limited. Maybe it makes sense to close this in favor of other issues (like #6752, #2523 or #6526)

[andrewdavidwong]

I don't think this one was implemented yet @andrewdavidwong. What has changed sinced? VM ownership is still represented by color mainly and those colors are rather limited. Maybe it makes sense to close this in favor of other issues (like #6752, #2523 or #6526)

The action for this issue is "explore options." It looked to me like the options had been explored and that exploration had ceased some time ago. If there's some follow-up action (like "decide which option to pursue" or "implement the chosen option"), I reckon that should be a separate issue.

[deeplow]

By explore options, I assume the tasks is not just to explore options but also to decide on one or more to pursue. As such I think if this is to be closed, it should have some decision as to which options will be implemented or maybe a even a WONTFIX, if that's the case.

[andrewdavidwong]

By explore options, I assume the tasks is not just to explore options but also to decide on one or more to pursue. As such I think if this is to be closed, it should have some decision as to which options will be implemented or maybe a even a WONTFIX, if that's the case.

That's a fair point, but in that case, this seems more like a "discussion issue" that's unsuitable for qubes-issues. It seems like this should instead be discussed on qubes-devel or the forum until there is some actionable proposal, then that actionable proposal can be filed as a legitimate issue.

[github-actions]

This issue has been closed as "not applicable." Here are some common examples of cases in which issues are closed as not applicable:

• Help and support requests (please see Help, support, mailing lists, and forum)
• Questions (please see Help, support, mailing lists, and forum)
• Discussion issues (please see Help, support, mailing lists, and forum)
• Bug reports for behavior that is already working as intended
• Enhancement requests to improve things that are already working as intended
• Issues that rest on mistaken assumptions or misunderstandings
• Issues that do not provide enough information
• Issues that are not actionable

We respect the time and effort you have taken to file this issue, and we understand that this outcome may be unsatisfying. Please accept our sincere apologies and know that we greatly value your participation and membership in the Qubes community.

Regarding help and support requests, please note that this issue tracker (qubes-issues) is not intended to serve as a help desk or tech support center. Instead, we've set up other venues where you can ask for help and support, ask questions, and have discussions. By contrast, the issue tracker is more of a technical tool intended to support our developers in their work. We thank you for your understanding.

If anyone reading this believes that this issue was closed in error or that the resolution of "not applicable" is not accurate, please leave a comment below saying so, and we will review this issue again. For more information, see How issues get closed.