More colors in VM settings or possibility to add colors (only 8 at the moment) #2523

ghost · Dec 17, 2016

Qubes OS version: `R3.2`

Could anyone point into source where changes to be impemented?

grey-olli · Feb 12, 2017

Could anyone point into source where changes to be impemented?

Unfortunately there are many places where the current labels are hard-coded, so this is not a trivial task.

I think the master list is intended to be the list in core-admin/core/qubes.py, but simply adding to that list would not be sufficient.

If you wish to work on this, I suggest you start by eliminating the other places in the codebase which hard-code labels. These can be found with e.g. grep -r purple qubes-src from a checked-out qubes-builder repo.

There have also been proposals to add different patterns instead of simply more colors, and I personally think that approach would be more useful for those of us with many VMs.

jpouellet · Feb 12, 2017

Unfortunately there are many places where the current labels are hard-coded, so this is not a trivial task.

I think the master list is intended to be the list in core-admin/core/qubes.py, but simply adding to that list would not be sufficient.

If you wish to work on this, I suggest you start by eliminating the other places in the codebase which hard-code labels. These can be found with e.g. grep -r purple qubes-src from a checked-out qubes-builder repo.

There have also been proposals to add different patterns instead of simply more colors, and I personally think that approach would be more useful for those of us with many VMs.

I would defer to those who specialise in user interfaces. I don't.
But I have worked on a number of projects where we have used expensive consultants who do specialise in that area. Their advice has always been to keep the number of colours to the minimum, particularly where this has significant consequences for the user. The advice has usually been to use no more than 7 or 8 colours.
In Qubes the use of colour obviously has significant consequences.

I'm opposed not just because people are far worse at discriminating between a range of colours than you would think. It's because they are being asked to identify, and give significance to, a particular colour when it isnt part of a range. I mean that if you see a colour as part of a colour chart you may be able to call it out, but when presented with a sample on its own then it isn't so easy to do so.
An added problem in Qubes is that we allow users to customise their desktops by changing wallpaper and/or background colour. Colour perception is very much influenced by background, so the users ability to differentiate similar colours may be adversely affected by their choice here.

For these reasons I would argue against the proposal, but as I've said, I'm happy to defer to those who have expertise in this area.
There is one change that I would like to see, which I think has been mentioned on the mailing lists in the past. The current colour choices are not suitable for those with some degree of colour blindness - it wouldn't take much to change them to a range which was colourblind safe.

Note that, by using different workspaces with colour coded backgrounds, the existing 7 choices (8 if black is included) can be simply extended to differentiate a larger number of VMs. wmctrl is installed by default in dom0 and can be used to help with such a set-up. I'd recommend that as the way to go.

unman · Feb 19, 2017

I would defer to those who specialise in user interfaces. I don't.
But I have worked on a number of projects where we have used expensive consultants who do specialise in that area. Their advice has always been to keep the number of colours to the minimum, particularly where this has significant consequences for the user. The advice has usually been to use no more than 7 or 8 colours.
In Qubes the use of colour obviously has significant consequences.

I'm opposed not just because people are far worse at discriminating between a range of colours than you would think. It's because they are being asked to identify, and give significance to, a particular colour when it isnt part of a range. I mean that if you see a colour as part of a colour chart you may be able to call it out, but when presented with a sample on its own then it isn't so easy to do so.
An added problem in Qubes is that we allow users to customise their desktops by changing wallpaper and/or background colour. Colour perception is very much influenced by background, so the users ability to differentiate similar colours may be adversely affected by their choice here.

For these reasons I would argue against the proposal, but as I've said, I'm happy to defer to those who have expertise in this area.
There is one change that I would like to see, which I think has been mentioned on the mailing lists in the past. The current colour choices are not suitable for those with some degree of colour blindness - it wouldn't take much to change them to a range which was colourblind safe.

Note that, by using different workspaces with colour coded backgrounds, the existing 7 choices (8 if black is included) can be simply extended to differentiate a larger number of VMs. wmctrl is installed by default in dom0 and can be used to help with such a set-up. I'd recommend that as the way to go.

On Sat, Feb 18, 2017 at 9:27 PM, unman ***@***.***> wrote: I would defer to those who specialise in user interfaces. I don't. But I have worked on a number of projects where we have used expensive consultants who *do* specialise in that area. Their advice has always been to keep the number of colours to the minimum, particularly where this has significant consequences for the user. The advice has usually been to use no more than 7 or 8 colours. In Qubes the use of colour obviously has significant consequences.

Currently I can't separate two similar contexts for two different companies neither by desktop bindings nor by colors. If desktop bindings will be implemented, when some activity cannot appear on same desktop w/ another activity separation will be easier. Though, I'd like to have more colors anyway and hope to have time to get this patched at least for myself . AFAIK I'm not the only person who wants more colors.

I'm opposed not just because people are far worse at discriminating between a range of colours than you would think. It's because they are being asked to identify, and give significance to, a particular colour when it *isnt* part of a range. I mean that if you see a colour as part of a colour chart you may be able to call it out, but when presented with a sample on its own then it isn't so easy to do so.

Agree. Though what are alternatives? When I've same colors for different activities that is not better than have a little different colors.

An added problem in Qubes is that we allow users to customise their desktops by changing wallpaper and/or background colour.

And that "problem" I'd like to keep as a nice ability common for all window managers. :) Guess I'm not alone w/ this.

Colour perception is very much influenced by background, so the users ability to differentiate similar colours may be adversely affected by their choice here.

Software developers can't make users "never misbehave". When you set green phone and can't see green For these reasons I would argue against the proposal, but as I've said, I'm

…

happy to defer to those who have expertise in this area. There is one change that I would like to see, which I think has been mentioned on the mailing lists in the past. The current colour choices are not suitable for those with some degree of colour blindness - it wouldn't take much to change them to a range which was colourblind safe. Note that, by using different workspaces with colour coded backgrounds, the existing 7 choices (8 if black is included) can be simply extended to differentiate a larger number of VMs. wmctrl is installed by default in dom0 and can be used to help with such a set-up. I'd recommend that as the way to go. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2523 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ALHcA5RVgsg-ccBCOKV2lyNjq-S0tGhwks5rd6ijgaJpZM4LP65b> .

-- Bye.Olli. gpg --search-keys grey_olli , use key w/ fingerprint below: Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal. com/tag/

grey-olli · Feb 22, 2017