4.2 Issue: Additional Qube colors break a lot of the GUI based utilities

In qubes 4.1 I was able to use these scripts (specifically, qubes-color-add, qubes-color-del):

Which I found by following from here:

to create new qube colors. (I added lime, cyan and magenta as suggested by ninavizz here):

Things worked well in 4.1.

When I tried this in 4.2, a lot of the utility GUIs (and the main xfce menu) wouldn’t recognize the colors. (qube manager works fine.) At first nothing appears wrong except that the xfce menu shows no colors. I logged out and back in to try to get them to show, and the menu still showed no colors. But then, the system tray (in which the Qube Domains runs–by the way why is this limited to 6 qubes including dom0?) would basically “freak out” meaning some item would blink in and out of existence in the tray (causing the whole menubar to shift back and forth) QubesDomains was never visible. UpdateQubes would, when opened, show a small grayed-out window and not function at all. Even salt complained about not having clean data when I tried to run it.

All of this behavior cleared up when I deleted the qube with the custom color. The system tray properly populated and behaved itself, QubesUpdates would actually populate with a list of qubes, and so on.

Something in 4.2 really HATES it when you create a qube with a custom color! My workaround is to make my lime qubes yellow, and my cyan qubes blue, but I’d rather not have to do that.

1 Like

Interesting. I feel like it should work, from a cursory glance at the script? Could you maybe check the output in console from running qui-domains and qubes-update-gui?

Also the domains widget should not be limited to 6 qubes… do you have it in XFCE on the bottom of the screen? (If yes, I will commence screaming at the Gtk void; if no, that’s a bug…)

1 Like

Having created a couple of cyan qubes, qui-domains quits immediately with the last line being “gtk-icon-theme-error-quark: Icon ‘dispvm-cyan’ not present in theme Adwaita” (If you need more than this, I’ve saved a file)

When I ran qubes-update-gui it seemed to work. I tried logging out and back in, still worked. Shutdown and restart…still worked. I don’t know what was going on the other time. (Shutdown seemed very slow.)

XFCE ended up at the top for whatever reason in my install, and the domains widget appears to be in the “tray” there. Right now it’s showing more than six items, but I know while running my salt scripts to build templates, oftentimes a template running because it is having software installed on it would not show up at all. Another thing that happens is that when I started a dvm template to sync the appmenus on it, the qube didn’t want to shut down afterwards; I had to issue a kill. (I eventually just put the kill flag in the shutdown at the end of my salt state that does the appmenus-sync.)

This looks like a script problem, in particular, like either creating dispvm-cyan icon didn’t work or gtk-update-icon-cache wasn’t run correctly. On the other hand, I should be handling missing icons without crashes, and this is something that will happen in qui-domains (I’m pretty sure it’s part of some other fixes I have baking).

This sounds very much like a bug. It really should be working (after roughly a billion iterations of trying to fix the bug you’re mentioning :confused: )

2 Likes

I know the icons do not show on the XFCE menu (but I just switched to KDE last night, and they appear there, at least when I specifically use them for subfolders). Qubes Manager shows them as well.

The menu tells me it’s possible to deal with a “missing” icon gracefully, :slight_smile:

I will have to try to run gtk-update-icon-cache when I am back on that system. It is not called (at least not directly) from gtk-color-add.

Ah, sounds like you’re painfully aware of it! :smiley: (I know that pain…and I’ve even had it with GTK.)

@marmarta

OK, it turns out that simply running gtk-update-icon-cache in a dom0 terminal fixed the problem. I even logged out and went back to xfce (I switched to KDE over the weekend) which didn’t show the icons on its menu and they were there.

I’m going to add that command to the end of the scripts I got from WillyJL

EDIT: it’s not sufficient to just put gtk-update-icon-cache in the script, it must read
gtk-update-icon-cache /usr/share/icons/hicolor

1 Like

That’s good to hear! Yeah, Gtk is… painful to say the least. I still think it’s better than Qt, but let’s be honest, it’s not really a great choice :rofl:

1 Like

And I did my final “reinstall” of 4.2 on the laptop, and can confirm that putting gtk-update-icon-cache at the end of Willy’s scripts completely fixes the issue (it doesn’t need to be done after the fact).

EDIT: it’s not sufficient to just put gtk-update-icon-cache in the script, it must read
gtk-update-icon-cache /usr/share/icons/hicolor

1 Like

And now it’s broken again.

I changed all qubes with added colors to legacy colors and removed the colors (thinking it might be causing a different issue I was having–it wasn’t).

Putting them back in and changing so much as one qube back to one of the new colors, then logging out, puts me right back where I was when I first posted this issue, and yes I know I am issuing gtk-update-icon-cache. I’ve done it in both the script (which is run with sudo) and from the command line (running with sudo).

I thought it might have something to do with having switched to KDE sddm, so I switched back away from sddm and repeated. Still broken.

As i said in this topic:Some noob questions - #12 by Tezeria
I had /usr/share/icons/hicolor it’s ok for changing color of existing qubes and new qubes BUT it’s doesn’t work for Standalone.
I tried by creating, by changing colors. creating new qubes, disconnecting/rebooting.

It isn’t KDE, i don’t install it, i always stay with XFCE.

edit:
I just see that i have /usr/share/icons/hicolor/scalable/apps/standalonevm-'name_custom_color'.svg
but in /usr/share/icons/hicolor/'size x size'/devices/ i don’t have standalonevm-'name_custom_color.png'
There’s definitely something to change in the script, I’ve been looking for but I’m not good enough to find it :confused:

I don’t know if you saw it or not but I found out my issue yesterday was that I wasn’t passing /usr/share/icons/hicolor to gtk-update-icon-cache. I had the command at the end of my label-creator script but somehow it disappeared (I must have wiped out the altered version by accident), and didn’t realize it needed that parameter (and nothing I saw looking it up, said it needed a parameter). I must have known this at the time I first dealt with this, but forgot it by this week. (I found it with man, looking for which file it should alter (basically it won’t touch anything but hicolor), and a bunch of confused time.)

1 Like

No i don’t sorry :confused:

I noticed that in /usr/share/icons/hicolor/scalable/apps/standalonevm-'name_custom_color'.svg , there is a <style> section at the beginning of the file that is not in the other files.svg
By manually changing the colors in this section, the color works very well after a disconnect/reconnect for standalones.
for example:

<style>
         <![CDATA[
            .mainColor {
                stroke: none;
                fill:    #XXXXXX
            }
            .outline {
                stroke: #XXXXXX;
                fill:    none
            }
            .shadow {
                fill:    #XXXXXX;
            }
        ]]>
    </style>

This section does not appear to be modified by the script and like as said before, I’m not good enough to find how modify the script :frowning:
The only solution at the moment is to edit the file manually…

Edit:
Can be a lead: When the color does not work in the standalone, by default, color is orange. As in the script in this lines:
for type in scalable/apps/[a-z]*vm-orange.svg ; do
and
for type in $size/devices/[a-z]*vm-orange.png ; do

1 Like