Add seven new colors #2523
Comments
andrewdavidwong
added
C: gui-virtualization
enhancement
help wanted
|
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. 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. 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. 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. 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/
|
|
On Wed, Feb 22, 2017 at 8:40 AM, Oleg Artemiev <[email protected]> wrote:
Sorry - two ctrl-enter sent before I finalized my letter
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.
Colour perception is very much influenced by background, so the users
ability to differentiate similar colours may be adversely affected by their
choice here.
When some popup razes on top of current application, most often it is not
hovering background - it is hovering current VM window and foreign to Qubes
application picture is not what we could control or should alter.
Coloring is good to differ popup from some other VM to popup from current
VM. There're two color separation context - one VM to another VM and two
similar full screen or non-full screen programs opened on difrent desktops.
Software developers can't make users "never misbehave". When you set green
background and can't see green window captions that is not developer
problem.
And this doesn't seem to be design problem - programmers allow users delete
their data. If user misbehave and deletes his data - is this a developer
problem? If developer made a confirmation note - no - this is exactly user
misbehave.
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
>
I'm not sure I'll make a patch, but I'm sure I need ability to separate
more contexts than I'm able now. I'm not claiming that should go via
coloring - binding VM activities to desktops is another alternative.
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.
>
I guess beter ides is not a single color for those people, but a different
"zebra/pedestrian" styles (i.e color blind people are okay w/ contrast and
thus should be able to differ a set of black and white shades like
"|\|\|\|\|" and " | | | | ",
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.
>
We need strict bindings VM<->desktop from VM configuration in Qubes VM
manger then.
Restricting background color for a desktop should be optional - full screen
mode windows hide background at all (at least I usually do full screen).
…--
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.c
om/tag/
--
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/
|
|
For R3.2 this probably will remain as is. For R4.0, the list of labels is in |
|
On Wed, Feb 22, 2017 at 9:05 PM, Wojtek Porczyk ***@***.***> wrote:
For R3.2 this probably will remain as is.
Means useless to try to make a patch within nearest 2-3 months?
For R4.0, the list of labels is in qubes.xml and only the initialisation
is hardcoded: https://github.com/QubesOS/qubes-core-admin/blob/core3-
devel/qubes/app.py#L852-L861. There is however neither tool nor API to
change that, apart from directly editing XML. @andrewdavidwong
<https://github.com/andrewdavidwong> Is there a reason to change that
approach? If not, we can close this bug.
My +1cent: this should definitely be switched from "bug" to "feature
request" for 4.0 and got documented.
My idea is a standard-looking color picker . If it's too effort-costly to
add it in Qubes VM manager - make VM color picker to be a separate dom0
tool + note it in documentation.
…--
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/
|
|
On Wed, Feb 22, 2017 at 10:44:34AM -0800, grey-olli wrote:
On Wed, Feb 22, 2017 at 9:05 PM, Wojtek Porczyk ***@***.***>
wrote:
> For R3.2 this probably will remain as is.
>
Means useless to try to make a patch within nearest 2-3 months?
For R3.2, yes. This work is already done, so there is no need to duplicate
that. And no-one would find that of much use anyway.
> For R4.0, the list of labels is in qubes.xml and only the initialisation
> is hardcoded: https://github.com/QubesOS/qubes-core-admin/blob/core3-
> devel/qubes/app.py#L852-L861. There is however neither tool nor API to
> change that, apart from directly editing XML. @andrewdavidwong
> <https://github.com/andrewdavidwong> Is there a reason to change that
> approach? If not, we can close this bug.
>
My +1cent: this should definitely be switched from "bug" to "feature
request" for 4.0 and got documented.
My idea is a standard-looking color picker . If it's too effort-costly to
add it in Qubes VM manager - make VM color picker to be a separate dom0
tool + note it in documentation.
Not at all. This is intentionally obscure for reasons extensively summed up by
@unman. I'd label that "wontfix".
|
|
We need to defer to the UX experts on this one. Since we don't have any to offer a firsthand analysis of this problem, I'm inclined to defer to @unman's report. |
|
For what it's worth, I want to acknowledge that the problem @grey-olli is experiencing is a legitimate one. With a large number of VMs, it becomes difficult to distinguish them, given a limited number of colors. However, it doesn't follow that adding more and more colors (or even building a tool that allows the user to do so) is the correct solution. For the reasons @unman points out, that's likely to backfire and ultimately harm the user instead. This calls for a more creative solution. |
|
I've created #2646 to encourage ideas for such a creative solution. |
|
Now that we have an actual UX expert around: @ninavizz, what do you think? |
|
From my point of view, these colors are nice 👍 |
|
I'd exclude gray and possibly white, to avoid problems like #3471 |
|
Yes I agree. Also, as far as I can see in the components, it would be easy to implement these colors. |
|
It seems like a core problem that needs to be solved in order for this Issue to find an elegant resolution, is: WHO are Qubes users, quantified. Not just "who actually uses Qubes, today" but from a product strategy POV the project leads need to make a clear decision around who to optimize the product for—and to base all decisions around that. Digital forensics analysts, gov ops employees, our parents, FinTech workers, journalists, sex workers. Hackers. Who uses the product today, vs who does the team want to use the product, tomorrow? What will help make the project at least revenue-neutral? When everyone's a priority, nobody's a priority. I feel this issue needs to be put on hold until some concrete decision-making happens around product strategy and well-defined, prioritized user personas. |
mfc
added
the
accessibility
andrewdavidwong
added
the
P: default
|
I Created A Script For More Colors :::::::::::::::::::::::::::::: https://github.com/cheznewa/MyGist/blob/master/morecolorqubesos.bash |
|
@ffsec shared:
A number of folks are requesting more colors on the current app-menu survey. I honestly don't see the exploratory work around aesthetic devices to help distinguish security that could then result in a rich new custom window something for Qubes being developed, happening anytime soon. Re-considering this, now, and thinking that a number of the above colors could easily be adopted into
Off the cuff, all of the ones from the above list except for Brown, Beige, and Teal, seem good. Those colors I exclude, mostly because they are either too similar to other colors, or just ugly. That would yield 18 colors, total. Quite an upgrade, from today's 8. Or, a segment of those colors. Thoughts? It would also help accessibility and distinction of windows by color a lot, if a custom XFCE window theme for Qubes could be created and ship OEM, per #6414. Or with |
|
Laughing with you, @ffsec. I appreciate the exploration, a lot—and doubly appreciate your sharing the 2y/o adventure, here, for others who might be keen to take this on (I'm not a developer). I also did a similar exploration before opening #6414 ... and found that between the focus/background states that most of the XFCE themes impose upon their window styling, as well as overly busy control icons on most of them, and my own bias against the weird gradients and rounded corners on most windows in their themes, we really need a custom XFCE theme for Qubes. Separate from the coloration stuff, is also the legibility of window texts. I love the idea of giving users control of their own colors, as that would also enable colorblind folks to work with their own unique impairment/ability. But that would require the window manager to then be able to recommend a high-contrast color for the text, that would work in both focus and disabled mode. I can think of many ways to "cheat" that with background gradients and blocks, but then those detract from the colored frames—and we're back to the same issues that exist with existing XFCE themes. |
andrewdavidwong
changed the title
|
Since @ninavizz has opened #6752 for adding three out of the desired 10 colors and is leaving this issue open to consider adding the remaining seven, I've updated the title accordingly. See #6752 (comment). |
|
Custom label names and icons would be nice to have in 4.2 as well! |
|
It is on my to-do to make the icons and post them here (and on the other issue) as I'm able to. Unless someone wants to take on this issue now in which case I'll make all requisite assets pronto! The label names imho should match what is in the color chart (and reflected in the Figma). The master file for the Qute Qubes in Figma is here. Cutting the art will require a small amount of fine-tuning on my end, so as soon as someone is ready to take this on pls just let me know! |
|
i hate a service required a sign up to all action access, @ninavizz you can upload your work ("Qute Qubes") to internet archive or openclipart (public domain) or in this platform? please. |
|
Also, could anyone explain why our Red / Black usage is a reversal of the traditional Red / Black signal lines concept? For years before, "Red" was "classified sensitive" and "Black" was "clear to connect to transmitter because it is encrypted already". |
Qubes OS follows the Biba Integrity Model much more closely than it follows the multilevel security model. “Red” means “danger, do not trust” and “Black” means “safe, you can trust this”. Qubes OS does not attempt to prevent covert channels, as this is not practical on commodity hardware. |
Officially, Qubes takes no stance on what the colors mean: https://www.qubes-os.org/doc/getting-started/#color--security
|
|
A recent survey was done to understand how people use colors in Qubes, and it affirmed that indeed use of colors is all over the place. Some people follow the model Demi proposed above, but many also just use it to "theme" their qubes; like, cool colors are personal and warm colors are for work. Stuff like that. Hence, the addition of new colors needs to follow a model of adding colors more distinct from each other and other colors, ahead of anything else. @cheznewa Are you interested in taking this work on? Yes, I will be cutting and sharing the final art files, here, in this issue—with no expectations that others create Figma accounts (you also don't need an account to access or work with the above file). I still have work to do on my end to finalize the artwork, and because that is many hours of work and I'm juggling many things, I've made the request that folks interested in taking this on let me know, here—which will hasten my attending to this matter. ALL of the qube colors will need to be updated, with updated art, when these new seven new colors go live—so it's not a small task. I'd be delighted if you'd want to take it on tho, and I thank you in advance! |
ghost
mentioned this issue
|
For anyone who wants to add their own colors while this is still a work in progress, I made my own script that lets you add custom colors and (unlike the other script floating around on the internet) also automatically generates the appropriate icons for all the different types of VMs, in all the needed sizes and even in svg. You can find it here |
Qubes OS version:
R3.2The text was updated successfully, but these errors were encountered: