If the distinguishing between different colors is a problem then maybe have an option for users to use basic colors currently provided or the advanced palette if the the user can distinguish between colors.
Yet you say it’s not only a problem with colors, but also with shape, text, texture and in the end the ultimate balance between them, correct?
So if Qubes can’t provide all of these above at this very moment, at the very least adding color palette will do more good than bad.
No, I don’t agree with that (and I don’t disagree either). I try to explain the problems (challenges) related to an increased color palette and the potential negative consequences.
Yet you say it’s not only a problem with colors, but also with shape, text, texture and in the end the ultimate balance between them, correct?
It is important to understand the actual issue. There is the desire for more colors which many express. Why is that? - Because in Qubes OS we work with many VMs. Many elements need organizing to help (1) avoid mistakes, (2) work easier. So, the real issue is organizing, not color.
Why is that translated to “I want more colors”? - Because currently color label is the only visual tool we have. That’s why, it seems to me, people think only about “more colors”. And because most people are not UI designers, they have not faced the actual challenges of what they “just want”. As someone who has, I tried to explain those challenges and their relation to security (the main focus of Qubes OS).
Think of color as just one possible visual dimension. The other visual properties (shape etc.) are other possible dimensions which we currently don’t have (e.g. red circle/square/triangle, red square with yellow border, quickly/slowly flashing red circle, etc - all red but different). So, what I am saying is that we should rather think about using more dimensions, rather than enriching one. This will create more possibilities for organization (the actual goal) without the negative consequences of a rich palette.
So if Qubes can’t provide all of these above at this very moment, at the very least adding color palette will do more good than bad.
Perhaps I don’t understand you well, but it seems like “if all you have is a hammer, everything looks like a nail”, but hopefully you won’t get discouraged me saying that.
Facts are:
This feature has been requested since 2016
Many people want it
Should be fairly easy to implement(unless there’s some specifics)
It contradict Linux’s principles (captive UI)
And many more, that are not less important, such as color perception or that there’s many easy ways to break/compromise the system by a user, but I think these are enough to make a point.
Because currently color label is the only visual tool we have.
Right… So until there’s a solution, people should suffer?
In the particular case, a more correct metaphor would be “if you have a small harmless hammer, don’t turn it into a huge dangerous one”.
Facts are:
This feature has been requested since 2016
What is more important for a secure OS? A shiny colorful thing, or a UI which does its best to protect you from your own mistakes?
Many people want it
Even more people want to use life threatening substances/drugs. Does that make their desire more valid? Does that improve or worsen security?
Another example: It is very easy to stop locking banks. Many people have wanted it for ages. It would make their personal lives easier.
Etc.
Should be fairly easy to implement(unless there’s some specifics)
Many dangerous things are extremely easy.
It contradict Linux’s principles (captive UI)
How exactly? Which particular principles?
GNU/Linux has various flavors (distros). Some have no GUI.
Please also note that Qubes OS is not Linux. Remember: security and usability are opposites in most cases. It is often difficult to approach the balance and great care must always be taken.
Because currently color label is the only visual tool we have.
Right… So until there’s a solution, people should suffer?
I am grateful to all Qubes OS developers who created this wonderful OS. I am happy to “suffer” it!
To the best of my knowledge, nobody here has been elected anyone to speak for “everyone else”, so in what you quoted I speak for myself only.
Nobody is forcing/limiting/repressing/exercising any form of violence against anyone. Adding a feature should not be a form of mercy to someone pretending to be painfully suffering the lack of it. It should be based on careful evaluation of the potential results.
Why not just add color pref that is a hex string? Like F0AB12 (any color in a usual RGB format)? The user can chose any or stick with current very limited number of colors?
Because currently color label is the only visual tool we have.
So until there’s a solution, people should suffer?
I am happy to “suffer” it!
You can continue to suffer, without everyone else having to do the same.
so in what you quoted I speak for myself only.
Not really. Admit it or not, but it actually implies others will suffer.
@balko Actually, that’s exactly how it’s implemented right now, as far as I can tell. And yes, it’s a more user friendly approach to fixed colors.
I personally use KDE, so for me, Qubes generates ~/.local/share/qubes-kde/ directory with all the color files, such as red.colors with RGB values.
I am not following these custom color issues, but I read about this problem for like 5+ years. If it can be addressed that easily and desired by so many, why is it not implemented yet, maybe by third-party contribution?
During creation of qube using GUI or cloning existing one, or changing settings of a qube user should be able to set RGB value with color picker or select from the list of pre-sets, or the list of already used colors, that’s all and seems to be simple.
Does not matter what display/monitor they have, user can adjust color as they desire.
Also I see no security issues, the user can keep strict color difference between VMs, even more strict than we have now, or can use any colors they like and simply read windows’ titles. I do not think it should be considered some security concern at all. Currently user can set all qube colors to black, the same as dom0, what can be worse with RGB?
Me neither, but if you scroll a very tiny bit above our messages, you’ll see we’re actually talking about the same thing
I personally use my own custom theme now and find these colors distracting.
I will not admit it because this is not real suffering. It is a pretense attempting to justify the “But I want it!” hammering, just like the extrapolation of it into “everyone else wants it”. The majority is not always right just because it is a majority. If you would like to have a meaningful discussion with mutual understanding, try meaningful arguments, not trick questions to which you answer yourself.
I wonder if anyone here realizes or even thinks of actual security critical interfaces and the reasons why they are made so. Take traffic for example:
Traffic lights: 3 very distinct colors with fixed positions
Police/ambulance: Usually just red and/or blue
Alarms: Usually just 1 color (+ sound)
Street signs (limited palette combined with shape, symbols and text as cues)
Road surface marking (1-2 colors)
Try adding 16 colors to e.g. traffic lights and watch real suffering.
Now, consider someone working with Qubes OS may be controlling critical medical systems. Would you take responsibility for a mistake resulting from the “different” colors of #FF0000 and #EE0000?
BTW, the current palette should drop gray as it is practically indistinguishable from black when applied to icons. Cyan and magenta can be added.
In many of the provided sizes, in fact, the gray icon is a duplicate of the black icon. In others it’s different enough to be evident. You might just happen to be dealing with one of the mistaken sizes (I wish I could remember what they were). In my qubes-manager, in fact, one of those sizes is “hit” and they all looked the same, at least until I actually fixed the icons. (What’s worse is one package out there in the repository still has the old padlock icons, so they keep cropping up, over and over again. I had to basically create a package of correct icons, and install it on top of that package. Actually, it’s possible this has been fixed and I never knew it.)
I think gray should be made much, much lighter (or even be replaced with white) and of course we need to be sure the icons aren’t just copies of the black icons!
(Edit: the gray icons that look exactly like black icons MAY have been the 192x192, 64x64, 36x36 and 22x22 pixel versions. At least, the dates on those directories in /usr/share/icons/hicolor are newer than the others on my system, an indication I may have edited something in those directories.)
I agree with you, and there needs to be a bigger serious dedicated thread/conversation on this between the developers and UI/UX designers, so as not to make a mess of trying to enrich what for me and probably others find perfectly fine; just using the color dimension to differentiate VMs. In the meantime we need the extra colors since that is currently the visual dimension we use to differentiate VMs.
Thanks for the book recommendation; "Designing with the Mind in Mind” also.
I wish that you could already choose among some interfaces during the installation. I myself come from Windows, have also looked at Linux Mint cinemon and must say I am spoiled. If you want to convince new users who are not IT specialists, you should be able to install your own image quality. I would have liked that, instead of implementing a KDE somehow afterwards. Great would be a selection during installation, depending on computing power from simple to beautiful.
I couldn’t describe what I was thinking before well but long story short what would be awesome is if the Qubes plumbing could be ported to the BSDs so they could be first class PVH citizens like Fedora and Debian. Perhaps to get carried away and really go over the top they could be dom0 as well. I understand its a lot of work to do any of these and I love Qubes for it is today but can always dream.
It’s something that should be done in the operating themselves, and not at Qubes OS level.
NetBSD, FreeBSD and OpenBSD have support for Xen, but maybe not xen vchan. In addition, the packages should be added to the ports tree. It’s not something impossible, but it requires work.
NetBSD can work as a DomU and I think FreeBSD can do it too. NetBSD even used to be an excellent Xen dom0!
Updating window. When clicking to do vm updates, an ‘Update All’ option would be helpful, I feel. Needing to manually check each and every vm checkbox is time consuming, if one wants to update all vms. An option to enable ‘All’ with then the ability to uncheck one or two of the already checked vms, if desired, would be quicker and easier.
