Low quality icons from applications running in Toolbox

[bkhl]

Describe the bug

When launching a GUI application from Toolbox, instead of using the icon from my ~/.local/share/applications/*.desktop file with the given window class, it shows a fuzzy low quality application icon.

Steps how to reproduce the behaviour

1. Install Emacs in a toolbox container
2. Create a .desktop file in ~/.local/share/applications/toolbox-foo.desktop looking something like this:

[Desktop Entry]
Name=Emacs (foo)
Type=Application
Exec=toolbox run --container foo emacsclient --alternate-editor '' --socket 'foo' --create-frame --frame-parameters '((name . "emacs-foo"))'
Icon=emacs-foo
Categories=Utility;TextEditor;
Keywords=toolbox;
StartupWMClass=emacs-foo

Expected behaviour

Window created with window class emacs-foo to be matched with the above .desktop entry, and use the icon indicated by it.

Actual behaviour

The window is created and based on xprop output, it has the window class emacs-foo, but it is not matched to the emacs-foo icon, instead using a fuzzy version of the default icon.

Screenshots

In this screenshot you also see Emacs running installed with rpm-ostree. If they had the same window class I'd expect them to be grouped. However, even if starting the toolbox instance with the default window class, it appears like this.

Output of toolbox --version (v0.0.90+)

toolbox version 0.0.96

Toolbox package info (rpm -q toolbox)

toolbox-0.0.96-1.fc32.x86_64

Output of podman version

Version:      2.1.1
API Version:  2.0.0
Go Version:   go1.14.9
Built:        Thu Oct  1 02:31:11 2020
OS/Arch:      linux/amd64

Podman package info (rpm -q podman)

podman-2.1.1-7.fc32.x86_64

Info about your OS

Fedora Silverblue 32

Additional context

I'm not sure what the exact desired behaviour here should be, if the application should be grouped with other windows from the same application on the host, or if it should be handled separately by using a different window class. I suspect though that if I can find out what the issue is here, I can maybe fix it.

[bkhl]

Ah, found that if I set the hostname of the Toolbox to match my hostname, get this in the xprop of the window:

WM_CLIENT_MACHINE(STRING) = "$myhostname"

and Gnome Shell actually does apply my .desktop icon.

AFAIK I guess this would work as a workaround for me, although it makes me wonder:

1. Is there some particular reason for setting the hostname in toolbox containers to toolbox, does it cause issues to change it?
2. Is the appropriate fix here a change to Toolbox (like changing the hostname), or should this be seen as an issue in Gnome Shell?

[debarshiray]

Wow, interesting!

Is there some particular reason for setting the hostname in toolbox containers to toolbox, does it cause issues to change it?

Is the appropriate fix here a change to Toolbox (like changing the hostname), or should this be seen as an issue in Gnome Shell?

The reason for setting a different hostname for the container is purely cosmetic, just like the purple hexagon. The intent is to somehow differentiate the prompt from the host to make it obvious that the user inside a container.

However, since every distribution has it's own slightly different arrangement of the shell start-up scripts and how things like PS1 are set, we were wary of doing something too invasive initially. Changing the hostname would mean that all uses of \h would pick up the new name.

However, @allanday and others have been looking at coming up with a slightly nicer prompt, so this might change.

Coming back to your original issue. I honestly don't know off-hand what the right way forward would be. @fmuellner might have some thoughts on this.

[fmuellner]

Does the emacs-foo icon exist outside the toolbox?

[A6GibKm]

You are supposed to export the icon too. I am surprised you actually see it. I have a tool here to export everything https://github.com/A6GibKm/silverblue-tools.

[bkhl]

Does the emacs-foo icon exist outside the toolbox?

Yes, that's an SVG icon that I put in ~/.local/share/icons

As described in my previous comment, the icon does get used if I set the hostname in the container to match the host's hostname.

Similarly, if I just use the icon name and class name emacs, it gets matched with my "main" Emacs icon, but again only if I make the container hostname match the host.

[bkhl]

You are supposed to export the icon too. I am surprised you actually see it. I have a tool here to export everything https://github.com/A6GibKm/silverblue-tools.

With this solution, do you actually get an icon that associates itself with the launced windows, so that if you click the icon again, it activates the window rather than launching the application again?

I would expect that you would run into the same issue as me unless you make the hostnames match also.

[A6GibKm]

Just commenting on the icon. I will see later whats the behaviour.

[bkhl]

Coming back to your original issue. I honestly don't know off-hand what the right way forward would be. @fmuellner might have some thoughts on this.

I should be able to set up some work-around now that I know the issue, running hostname in a file in /etc/profile.d/ or something like that. However, I'll just say what the most convenient solution would be for me:

1. Add a --hostname flag to toolbox that passes along it's parameter to --hostname of Podman.
2. If not supplied, use the current host hostname as the container hostname.

If 2. causes issues with the shell prompt that can't be resolved for now (I guess that's better discussed in the tickets about that), of course I could live without 2. and instead supply that using the mentioned --hostname flag.

[A6GibKm]

This is my desktop file

[Desktop Entry]
Name=Emacs
GenericName=Text Editor
Comment=Edit text
Comment[zh_TW]=編輯文字
MimeType=text/english;text/plain;text/x-makefile;text/x-c++hdr;text/x-c++src;text/x-chdr;text/x-csrc;text/x-java;text/x-moc;text/x-pascal;text/x-tcl;text/x-tex;application/x-shellscript;text/x-c;text/x-c++;
Exec=toolbox run emacs %f
Icon=emacs
Type=Application
Terminal=false
Categories=Utility;TextEditor;X-Red-Hat-Base;
StartupWMClass=Emacs
X-Desktop-File-Install-Version=0.24

It works as expected. You click the icon and it opens the already open instance.

[bkhl]

It works as expected. You click the icon and it opens the already open instance.

That's interesting, I'm wondering what the difference is, are you using a newer version of Fedora than me (I'm on 32 for both the host and container)?

What is the output of running xprop and clicking your Emacs window?

Just to check I installed emacs in the default toolbox (fedora-toolbox-32), and used A6GibKm's .desktop file from above, but I still get the fuzzy icon. If I change the hostname in the toolbox, I again get the icon (and no "(on toolbox)" in the window title).

[A6GibKm]

You WILL get the weird icon if you don't install it in you system, e.g. ~/.local/share/icons.

[bkhl]

You WILL get the weird icon if you don't install it in you system, e.g. ~/.local/share/icons.

I have. And as I say this icon gets used if I manipulate the hostname of the container to match that of the host, which is why I don't think the content of the .desktop file and associated configuration is the problem, but something to do with hostnames and probably WM_CLIENT_MACHINE (which is why I asked about your xprop output).

[A6GibKm]

Did you install the icon located at toolbox:/usr/share/icons/hicolor/scalable/apps/emacs.svg?

[bkhl]

Did you install the icon located at toolbox:/usr/share/icons/hicolor/scalable/apps/emacs.svg?

Yes. I'd be more interested to know what the difference is to your environment. Could you answer about your Fedora versions, and whether you use the Wayland or X11 session [Update: never mind about that one, I tried in X11 and get the same issue there] , and check the output of xprop for your Emacs window?

[fmuellner]

As described in my previous comment, the icon does get used if I set the hostname in the container to match the host's hostname.

Sorry, I had missed that.

That actually makes sense, it means that gnome-shell mistakes the window for a remote X11 client and bypasses the usual .desktop file matching (because the matching .desktop file would be on a different host in that case):

https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/master/src/shell-window-tracker.c#L406

[bkhl]

That actually makes sense, it means that gnome-shell mistakes the window for a remote X11 client and bypasses the usual .desktop file matching (because the matching .desktop file would be on a different host in that case):

https://gitlab.gnome.org/GNOME/gnome-shell/-/blob/master/src/shell-window-tracker.c#L406

I suspect that this is what happens, and that the fuzzy icon I see is the icon from the toolbox environment sent in a non-vector form, which ends up not looking very nice.

[fmuellner]

the fuzzy icon I see is the icon from the toolbox environment sent in a non-vector form

More precisely, it's the _NET_WM_ICON property set by emacs.

[bkhl]

Yup, if I start it with emacs --no-bitmap-icon, I get no icon for it at all.

Apparently, X clients are allowed to set the WM_CLIENT_MACHINE value as well, but I don't see a way to modify it from within Emacs.

However, looking at what that value should be, it's supposed to be the hostname of the machine the client is running on, as seen from the X server (Wayland X11 emulation in this case).

Since the toolbox isn't emulating a separate machine in a networking sense, and there's no hostname for it to give it from the host, I'm leaning towards that the toolboxes should by default have the same hostname as the host, and the PS1 thing be solved in some other way (https://github.com/containers/toolbox/issues/576)

[daquinons]

Ah, found that if I set the hostname of the Toolbox to match my hostname, get this in the xprop of the window:

WM_CLIENT_MACHINE(STRING) = "$myhostname"

and Gnome Shell actually does apply my .desktop icon.

AFAIK I guess this would work as a workaround for me, although it makes me wonder:

1. Is there some particular reason for setting the hostname in toolbox containers to `toolbox`, does it cause issues to change it?

2. Is the appropriate fix here a change to Toolbox (like changing the hostname), or should this be seen as an issue in Gnome Shell?

Hello! How do you set that? :thinking: Thanks! This issue has been driving me crazy :D Happening with VS Code.

[bkhl]

Hello! How do you set that? thinking Thanks! This issue has been driving me crazy :D Happening with VS Code.

If your hostname is foo, just run hostname foo in the toolbox. To make it persist, the only way I can think of at the moment is to set it in your profile, by creating a file named something like /etc/profile.d/hostname.sh with the contents:

sudo hostname foo

You can also edit /etc/hostname to match but I think for most purposes this will not matter.

This is because the hostname is set as a property of the container when Toolbox creates. Thus my request to add --hostname flag to toolbox create as well.

PS. If someone knows a way to change the hostname of an already created container instead, that would be nice, so let me know in that case.

[bkhl]

In case of anyone wanting to do the same workaround for now, here's how I automated changing the hostname of the container after creation: https://gitlab.com/bkhl/toolboxes/-/blob/latest/scripts/toolbox-project#L191-192

[Update: this has to be repeated any time the container is restarted though.]

[bkhl]

noting that since upgrading to Fedora 33, GNOME shows these icons in their native size instead of scaling them, so it looks slightly less crappy.

[debarshiray]

So, did the original problem of low quality icons get solved or at least worked around?

I am asking because I am a bit lost in the back and forth on this bug.

[fmuellner]

It's not fixed, but it can be worked around by setting the toolbox's hostname to the same string as the host's hostname.

Or if possible, set up the app to use wayland, as only X11 windows are affected.

[antonius-dev]

Hello! How do you set that? thinking Thanks! This issue has been driving me crazy :D Happening with VS Code.

If your hostname is foo, just run hostname foo in the toolbox. To make it persist, the only way I can think of at the moment is to set it in your profile, by creating a file named something like /etc/profile.d/hostname.sh with the contents:

sudo hostname foo

You can also edit /etc/hostname to match but I think for most purposes this will not matter.

This is because the hostname is set as a property of the container when Toolbox creates. Thus my request to add --hostname flag to toolbox create as well.

PS. If someone knows a way to change the hostname of an already created container instead, that would be nice, so let me know in that case.

2023 year Fedora SilverBlue 38 X11 VScode Insiders

[Desktop Entry]
Type=Application
Name=VSCode Insiders
GenericName=VSCode Insiders
Exec=toolbox run code-insiders %F %d
Icon=/var/home/user/.icons/vscode-insiders.png
Terminal=false
Categories=Utility;TextEditor;
StartupWMClass=Code-Insiders
MimeType=text/plain;text/x-csrc;text/x-c++src;text/x-java;text/markdown;

Changing sudo hostname yourhostname actually solved problem. Thank you!