Documented way to override the icon without recompiling

[ssokolow]

Description

Provide and document a way to customize the icon used in taskbar entries

Who's implementing?

• I'm willing to implement this feature myself

The problem

Before you changed Ungoogled Chromium's icon to the current stop-light-red one, Firefox was the most eye-catching thing on my predominantly black, white, blue, and green desktop.

This will become even more true because I'm about to switch Firefox out for LibreWolf and affected more than most people by the whole "stop signs and fire engines are red because they're supposed to distract you from what you're doing" thing.

Possible solutions

Please provide a documented means to let users override it.

(eg. A "this is known to work" FAQ entry for replacing the icon with something less distracting based on an implementation of the XDG icon theming lookup mechanism and confirmation that it listens to the appropriate environment variables so that Flatpak's approach to exposing the system icon theme to applications doesn't break it.)

Alternatives

I suppose you could add something under chrome://settings/ instead if you want a single implementation that works across all platforms.

Additional context

No response

[dumbmoron]

This is likely an issue for https://github.com/flathub/io.github.ungoogled_software.ungoogled_chromium, ungoogled-chromium does not have a red icon on any of the platforms I used it on so far.

Anyways, changing the icon depends on your platform (which is not specific to any one program), and I personally don't see the benefit of introducing a feature like this globally. If you wish to change the icon, the easiest way would probably be to check what handles icons on your platform/machine and override it there.

[ssokolow]

Huh. I know they changed it to comply with Flathub's policy, but I didn't realize they only changed it on Flathub.

Still, allowing the user to change the icon used in taskbar buttons and window decorations without recompiling is something that needs to be implemented in the upstream project.

[dumbmoron]

Still, allowing the user to change the icon used in taskbar buttons and window decorations without recompiling is something that needs to be implemented in the upstream project.

I agree that the upstream software project responsible for handling icons on your desktop should support overriding them.

I suppose it would make sense to document something like:

#!/bin/sh

cp /var/lib/flatpak/exports/share/applications/io.github.ungoogled_software.ungoogled_chromium.desktop \
	~/.local/share/applications/

wget -O ~/.local/share/icons/chromium.png \
	https://raw.githubusercontent.com/chromium/chromium/refs/heads/main/chrome/app/theme/chromium/product_logo_256.png

sed -i "s|Icon=.*|Icon=$HOME/.local/share/icons/chromium.png|" \
	~/.local/share/applications/io.github.ungoogled_software.ungoogled_chromium.desktop

since it seems to be a common request (when looking up how to do this in general, the first search result was someone on reddit asking specifically about changing ungoogled-chromium's icon)

[ssokolow]

That part's fine. The existing .desktop file has this line:

Icon=io.github.ungoogled_software.ungoogled_chromium

...which means it's already relying on the launcher's XDG Icon Theming resolver and all the user needs to do is drop a file named io.github.ungoogled_software.ungoogled_chromium.png or io.github.ungoogled_software.ungoogled_chromium.svg into the appropriate place under ~/.local/share/icons/<ThemeName> and it'll get picked up.

It's the lookup internal to Ungoogled Chromium, not the lookup internal to the launcher (eg. Plasma), which this is about.

Heck, even without that, if you've got something like kmenuedit (available in the context menu of Plasma's launcher widgets), you can do your proposed approach graphically.

[PF4Public]

Heck, even without that, if you've got something like kmenuedit (available in the context menu of Plasma's launcher widgets), you can do your proposed approach graphically.

That's true! I highly doubt that it is worth it to implement this feature as a part of ungoogled-chromium if there exists such a straightforward solution.

[ssokolow]

@PF4Public As I just said, that's for altering the launcher menu, NOT the taskbar button and "Use system titlebar and borders" titlebar.

kmenuedit alters the .desktop file which is read by your DE to draw launchers. What I'm asking about is set by actual code inside Chromium equivalent to APIs like Qt's QWidget::setWindowIcon.

Without participation from the application, the only way for the user to change that is to implement something akin to Privoxy or Greasemonkey in Plasma and KWin which substitutes file X when it detects that it's received file Y from the application... and that requires writing C++ code and maintaining a custom build of the KDE packages in question.

[PF4Public]

What I'm asking about is set by actual code inside Chromium equivalent to APIs like Qt's QWidget::setWindowIcon.

Applying a patch while building is the solution for this. This feature doesn"t improve anything with respect to project goals.

[ssokolow]

Well-behaved applications running on Linux allow their icons to be themed. End of story. Non-skinned native applications indirect every icon lookup through the XDG icon theming machinery.

EDIT: Hell, Qt bakes support for that into QIcon's constructors and, for window icons, I believe GTK 4 dropped support for anything but specifying a window's icon via a name and letting the desktop provide the contents.

[PF4Public]

Well-behaved applications running on Linux allow their icons to be themed. End of story. Proper Non-skinned native applications indirect every icon lookup through the XDG icon theming machinery.

It would be a great issue to be filled upstream, against Chromium then.

[ssokolow]

Do you really expect Google to do anything but close the issue as WONTFIX when everything based on the Chromium codebase had broken/buggy middle-click paste support for at least half a decade?

EDIT: ...and also solicited feedback on their decision to hide http:// and then locked the thread after a year of people saying they don't like it and asking for details on what research showed it to be superior.

I seriously doubt that they'd consider it their problem that users want to override a given build's branding locally without having to compile a custom build. (Because that icon is basically the only thing that's not part of their skinned UI and, thus, exempt from the rule of thumb for what gets XDG looked up.)

EDIT: I see this as of the same class of fixes as the patch Ungoogled Chromium carries to restore the ability to use a light-mode UI in incognito windows.

[PF4Public]

It doesn"t matter what I would expect or what I think. I was just giving you my feedback on the issue at hand. So once again: You might"ve rightfully claimed this being an upstream issue, thus upstream issue tracker is the best place for it. Implementing it here may add maintenance burden to the project without improving anything significantly in respect of project goals.

I'd say that "UI in incognito" has a direct relationship with the project goals. Tray icon? Not likely.

Please try avoiding emotionally charged statements and blame-game. Those do not add anything useful to the discussion.

[ssokolow]

I certainly didn't have any emotions guiding my phrasing when writing it... though I will apologize for slipping into author mode and putting in some incredulity as a stylistic flourish. (Probably because I'm prone to mistakes like that when I'm tired and I accidentally jet-lagged myself. Sorry.)

I also didn't intend to do any blame-game stuff... just to give a couple of pieces of hard evidence on how the Chromium project prioritizes things.

I will, however, stand by my claim that, if allowing turning off dark theming in incognito mode qualifies as "in line with project goals", then allowing the taskbar/titlebar icon to pick up an icon from the system theme should too.

EDIT: Or, if it already does and I don't know, documenting what icon name it's querying.

[PF4Public]

Well, then let"s keep this issue open, perhaps someone more knowledgeable than me will comment.

[github-actions[bot]]

This issue has been automatically marked as stale as there has been no recent activity in response to our request for more information. Please respond so that we can proceed with this issue.

[ssokolow]

Bad bot.

[github-actions[bot]]

This issue has been automatically marked as stale as there has been no recent activity in response to our request for more information. Please respond so that we can proceed with this issue.

[ssokolow]

Bad bot.

[github-actions[bot]]

This issue has been automatically marked as stale as there has been no recent activity in response to our request for more information. Please respond so that we can proceed with this issue.

[ssokolow]

Bad bot.

[github-actions[bot]]

This issue has been automatically marked as stale as there has been no recent activity in response to our request for more information. Please respond so that we can proceed with this issue.

[ssokolow]

Bad bot.

[github-actions[bot]]

This issue has been automatically marked as stale as there has been no recent activity in response to our request for more information. Please respond so that we can proceed with this issue.

[ssokolow]

Bad bot.

[ssokolow]

Can someone get rid of that "need info" tag if the bot's going to behave that way?

It's clear from the way the bot's configured that what it really means is "Ignore this bug until @ssokolow answers the question", not "the participants are waiting for someone else more knowledgeable to answer the question".