It should be patched manually. This probably happens to other Qt applications as well. No I don't agree that qtgui or qtbase itself should be patched to have /usr/share/icons/hicolor as an added fallback by default. Not unless a use flag is added. Reproducible: Always Steps to Reproduce: 1. Install qbittorrent-4.5.4. 2. Set current them to anything but hicolor. 3. Run qbittorrent. Actual Results: System tray icon doesn't show when current theme is not hicolor. https://doc.qt.io/qt-6/qicon.html#fromTheme Need to test if https://github.com/qbittorrent/qBittorrent/commit/77aa85fbd3af12b319f8f0b8372f4ba186d10c80 has fixed this or if use of patch can be avoided with it.
Created attachment 866758 [details, diff] Patch that adds hicolor as fallback
For the less adept, desktop.eclass uses hicolor as the default install theme: # @FUNCTION: _iconins # @INTERNAL # @DESCRIPTION: # function for use in doicon and newicon _iconins() { ( # wrap the env here so that the 'insinto' call # doesn't corrupt the env of the caller insopts -m 0644 local funcname=$1; shift local size dir local context=apps local theme=hicolor while [[ $# -gt 0 ]] ; do case $1 in -s|--size) if [[ ${2%%x*}x${2%%x*} == "$2" ]] ; then size=${2%%x*} else size=${2} fi case ${size} in 16|22|24|32|36|48|64|72|96|128|192|256|512|1024) size=${size}x${size};; symbolic|scalable) ;; *) eerror "${size} is an unsupported icon size!" exit 1;; esac shift 2;; -t|--theme) theme=${2} shift 2;; -c|--context) context=${2} shift 2;; *) if [[ -z ${size} ]] ; then insinto /usr/share/pixmaps else insinto /usr/share/icons/${theme}/${size}/${context} fi if [[ ${funcname} == doicon ]] ; then if [[ -f $1 ]] ; then doins "${1}" elif [[ -d $1 ]] ; then shopt -s nullglob doins "${1}"/*.{png,svg} shopt -u nullglob else eerror "${1} is not a valid file/directory!" exit 1 fi else break fi shift 1;; esac done if [[ ${funcname} == newicon ]] ; then newins "$@" fi ) || die }
I am unsure about this patch, at the very least it would conflict with prefix installations. You also linked upstream commit that might have fixed it. Let me know if it did, I much rather backport upstream commit until they release a new version with it.
> it would conflict with prefix installations. I'm a bit surprised why that matters for qbittorrent especially just for a system tray icon, but a line in the patch can be changed to this and then you can call eprefixify to the modified source file in the ebuild. + QIcon::setFallbackSearchPaths(QIcon::fallbackSearchPaths() << QString::fromUtf8("@GENTOO_PORTAGE_EPREFIX@/usr/share/icons/hicolor")); > You also linked upstream commit that might have fixed it. Let me know if it did, I much rather backport upstream commit until they release a new version with it. I'll check if it fixes it but I don't think it's worth backporting as it comes with a feature and many modifications. I mainly shared it as a heads up; something that might be worth examining for an alternative solution, and something to look forward to in the next release. But so far I think the solution I contributed already suffice and the additional mental effort to pick the right lines to backport isn't worth it.
I reinstalled qbittorrent using `sudo EGIT_COMMIT=77aa85fbd3af12b319f8f0b8372f4ba186d10c80 FEATURES=-userpatches ebuild /usr/portage/net-p2p/qbittorrent/qbittorrent-9999.ebuild merge`. And ran it from a temporary user shell instance. The system tray icon is showing. Version shows 4.6.0alpha1 in About dialog.
I am unable to reproduce the problem. From what you wrote it would sounds that if there's no hicolor style set, there's no tray icon. I have style Fusion with icon theme Tango and the tray icon is shown in polybar just fine.
> I am unable to reproduce the problem. With 4.5.4?
This is correct, net-p2p/qbittorrent-4.5.4
For some reason running qbittorrent 4.5.4 without the patch displays the correct icon in the system tray, but only with the user I've been testing it with. However, running qbittorrent from another user that has logged in from the Linux console, has all files in its $HOME deleted before startx, and doesn't share X or any form of session with another user, the system tray doesn't appear. It's invisibile. Must be a cache or retained runtime setting that allows it to continually show?
*system tray icon
That sounds as if any of your configuration changes triggers it in qbittorrent and by default the tray would be there. Seems like old issue, check my comment from 2019 at https://github.com/qbittorrent/qBittorrent/issues/9518#issuecomment-455966320
Ok this is what I discovered. Unless I select an icon from the system's Appearance settings (I'm using XFCE), qbittorrent's icon won't appear in the system tray. Tested with 77aa85fbd3af12b319f8f0b8372f4ba186d10c80. Also tested with 4.5.4 unpatched but only with the not appearing part. I haven't tried running it with an Icon setting selected. The icon set selected doesn't seem to matter. I tried both Adwaita and Breeze in different instances. Selecting a theme/style isn't enough. An icon set has to be selected. However with 4.5.4 and my patch it doesn't matter. The icon will always appear.
I have to add that with every test I had to remove all of the temporary user's files before rerunning startx. I don't deselect an Icon setting to test. It's not even possible.
> Seems like old issue, check my comment from 2019 at https://github.com/qbittorrent/qBittorrent/issues/9518#issuecomment-455966320 Sorry I didn't read thoroughly before examining the issue. That looks similar to what I discovered. It's quite an interesting case how it worked when an Icon set is simply selected; as if Qt automatically selects the icon set for Qbittorrent or maybe mix icons up.
Ok so apparently it "works" when an Icon theme is selected, simply because the icon theme inherits hicolor. [Icon Theme] Name=Adwaita Comment=The Only One Example=folder Inherits=hicolor This method is pretty weak in my opinion. A system tray icon that's independent of a theme icon should not have the theme as a dependency. Hicolor should be programmatically enforced as the default theme icon instead since that's the repository used by all applications, either system-wide or per-package.
I think you have a good cause to bring up upstream and link the related bugs since you already did all the discovery and debugging
> I think you have a good cause to bring up upstream and link the related bugs since you already did all the discovery and debugging I'll think about it. I spent enough effort already for such a simple fix. How about the patch, will it be ignored, or will you just wait for a patch to be approved and then have it backported?
The patch while simple does hard code the EPREFIX and requires string replacement to support it properly, I'd like to see what upstream has to say about it before going forward with this patch, so far you are the only other affected user I know off and you already uses local patches, then depending on what upstream says about it it can be solved in one way or another.
I created an issue: https://github.com/qbittorrent/qBittorrent/issues/19476
