gray app icons missing, replaced with green

[mossy-nw]

Qubes OS version:

R4.0_rc3

Affected TemplateVMs:

dom0

---

Steps to reproduce the behavior:

set VM label color to gray in VM Settings GUI or by
[dom0 ~]$ qvm-prefs vm-name label gray

Expected behavior:

App icons in ALT-F1 list, menu bar, and in Application Finder (ALT-F3) as well as in Application Switcher (ALT-TAB) should be colored gray.

Actual behavior:

Lock icons and window borders are colored gray, but app icons in ALT-F1 list, menu bar, and in Application Finder (ALT-F3) as well as in Application Switcher (ALT-TAB) are colored green.

General notes:

• also it can take some time before colors and Selected Applications (from VM Settings GUI) propagate to Application Finder

---

Related issues:

perhaps #3102

[marmarek]

What was previous label of that VM? green?

[mossy-nw]

the VM was restored from a backup as gray (and brand new VMs created from GUI or command line with gray labels also have the issue).

[3hhh]

Honestly I would suggest to remove gray as a choice altogether as it can easily be seen as black depending on the screen brightness and most users tend to use black for their most valuable VMs.

For awesome I even recall that gray was used as a color to represent the focus state of the window to the user: Usually colors are made more dark for unfocused windows whereas for black it is made more light (= gray) which leads us to another reason why having gray might not be the best idea.

[mossy-nw]

Users can simply choose to avoid any color, and gray is not set for any default appVMs, so I would say, please leave it in.

[marmarta]

I've found it! The problem is that the gray we use as default is not actually gray; it's a very very de-saturated shade of green. Unfortunately, changing it to actual gray means that we get exactly the same icons as in black. If we keep tinting as we do (changing hue/saturation, but not value, to avoid ruining the icons completely) - and I think we should - I see two solutions:

• keep gray, assume users will not get confused by identical icons (the window frames should be different), potentially get seriously hurt in the future if we ever start tinting something else (I don't like this solution)
• remove gray and replace it (on loading VMs / applying updates / something? @andrewdavidwong , maybe you have an idea) with a new color, like 'cyan' - it's the best solution when looking at possible future problems, but I'm not sure what would be the best way to communicate it to users.

[andrewdavidwong]

remove gray and replace it (on loading VMs / applying updates / something? @andrewdavidwong , maybe you have an idea) with a new color, like 'cyan' - it's the best solution when looking at possible future problems, but I'm not sure what would be the best way to communicate it to users.

This seems like the preferable solution.

The main question is whether changing one of the colors of users' icons on them is a security risk. Probably not, especially since those same icons are randomly going missing. In that case, it can be applied just like any other update, and we can make a normal announcement to inform users of the change.

If, on the other hand, we think that this change could be harmful to some users (doesn't seem like it, but I could be missing something), then we should probably not push it onto stable releases. It would be a bug fix that goes into 3.2.1 and 4.0.1, and the explanation would be the release notes (and elsewhere too, probably).

What do you think, @marmarek?

[marmarek]

It would be a bug fix that goes into 3.2.1 and 4.0.1, and the explanation would be the release notes (and elsewhere too, probably).

3.2.1 or 4.0.1 is nothing different than 3.2/4.0 with updates installed.

Since gray was broken and in some cases looked like a different color (green), I don't think changing it is a bad idea. But IMO it should be clearly communicated to avoid confusion about new color when someone have used gray label anyway. We are not changing it to any existing label, so risk of confusing it with any other label (which would be a security problem) is small.

[hueybah]

New-ish user here, 4.0 has me committed to your platform , great stuff!!

Would writing a new qvm-tool allowing users to create their own label colors [set; hex/hue/etc] avoid this sort of issue in the future?

No idea how much work that would be, or if most end users would benefit from feature like that.

[andrewdavidwong]

@hueybah:

Would writing a new qvm-tool allowing users to create their own label colors [set; hex/hue/etc] avoid this sort of issue in the future?

Probably not. See #2523 and #2646.

[GammaSQ]

Just wanted to mention that qvm-create --label gray (obviously) have the same issue.

I'd support dropping gray as option under these circumstances.

[marmarta]

So, after years of inactivity and some improvements on things like displaying window borders, grey being grey is now acceptably distinguishable in use in everything except the icons. To not break existing installations, I've made a fix that I above considerd bad idea (well...).
Perhaps we could also add warning in graphical tools that grey and black labels are hard to tell apart.

[andrewdavidwong]

Perhaps we could also add warning in graphical tools that grey and black labels are hard to tell apart.

They are currently easy to tell apart on my system. Does this new fix make them harder to tell apart?

Edit: Never mind. I found the comment above: #3471 (comment).

[marmarta]

No - but the colored app icons look pretty much the same, while the qube icon and window frames are different.

…

On Sat, Aug 15, 2020, 08:50 Andrew David Wong ***@***.***> wrote: Perhaps we could also add warning in graphical tools that grey and black labels are hard to tell apart. They are currently easy to tell apart on my system. Does this new fix make them harder to tell apart? — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#3471 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABXIEOVXIL4RXYRPFOL56PLSAYV43ANCNFSM4EMCRRYA> .

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.1.16-1.fc32 has been pushed to the r4.1 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.53-1.fc25 has been pushed to the r4.0 testing repository for dom0.
To test this update, please install it with the following command:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.1.16-1.fc32 has been pushed to the r4.1 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update

[qubesos-bot]

Automated announcement from builder-github

The package qubes-core-dom0-4.0.55-1.fc25 has been pushed to the r4.0 stable repository for dom0.
To install this update, please use the standard update command:

sudo qubes-dom0-update

Or update dom0 via Qubes Manager.

Changes included in this update