Bug 274057 - x11-themes/adwaita-icon-theme: some icons in XFCE are broken after update to 42
Summary: x11-themes/adwaita-icon-theme: some icons in XFCE are broken after update to 42
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-desktop (Team)
URL:
Keywords: needs-qa, regression
Depends on:
Blocks: 271570
  Show dependency treegraph
 
Reported: 2023-09-23 20:09 UTC by Anton Saietskii
Modified: 2023-09-29 13:58 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (desktop)
madpilot: maintainer-feedback+


Attachments
issue screenshot (850.98 KB, image/png)
2023-09-23 20:13 UTC, Anton Saietskii
no flags Details
v1 (apply via "git am") (1.24 KB, patch)
2023-09-24 19:43 UTC, Jan Beich
no flags Details | Diff
v1 (apply via "git am") (1.24 KB, patch)
2023-09-24 20:00 UTC, Jan Beich
no flags Details | Diff
v1 (apply via "git am") (1.27 KB, patch)
2023-09-24 20:01 UTC, Jan Beich
jbeich: maintainer-approval? (xfce)
Details | Diff
defaults change v1 (2.58 KB, patch)
2023-09-24 20:26 UTC, Guido Falsi
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Anton Saietskii 2023-09-23 20:09:25 UTC

    
Comment 1 Anton Saietskii 2023-09-23 20:13:54 UTC
Created attachment 245174 [details]
issue screenshot

Please note following menu items: Settings, Accessories, Internet, Office, XScreenSaver Blank/Lock. All of these were with correct icons before update.

Unfortunately, I have no idea where to look to investigate this. But at least I did a session restart.
Comment 2 Graham Perrin 2023-09-23 20:23:16 UTC
Thank you, 

(In reply to Anton Saietskii from comment #1)

Which version of FreeBSD, exactly? 

Packages from quarterly, or latest? 

freebsd-version -kru ; uname -aKU

% pkg -vv | grep -e url -e enabled -e priority
Comment 3 Anton Saietskii 2023-09-23 21:58:16 UTC
(In reply to Graham Perrin from comment #2)

I don't really believe anything of that is relevant, but here it is (and latest tree ofc, adwaita-icon-theme hasn't been merged to quarterly):
jason@jnb: [?:0] ~ $ freebsd-version -kru ; uname -aKU ; pkg -vv | grep -e url -e enabled -e priority
13.2-RELEASE-p2
13.2-RELEASE-p2
13.2-RELEASE-p2
FreeBSD jnb.local 13.2-RELEASE-p2 FreeBSD 13.2-RELEASE-p2 releng/13.2-n254627-4341433a673 JNB amd64 1302001 1302001
    url             : "file:///usr/local/poudriere/data/packages/releng132-default",
    enabled         : yes,
    priority        : 0

Looking at the plist changes in PR#271570 (commit 	14ac2cbef6484e85669c99a5a8388ea4627f029f), I can see lots of "legacy" icons removed (especially applications-accessories.png, and can't see it's replacement). As "Accessories" icon is one of broken, likely this is the case.
Comment 4 Anton Saietskii 2023-09-23 22:10:09 UTC
Reddit guys complaining: https://www.reddit.com/r/archlinux/comments/uchhho/icons_missing_for_adwaita_xfce_using_a_different/
There's also a thread on XFCE forum: https://forum.xfce.org/viewtopic.php?id=15735

Both links suggest 41 as latest working version. As Adwaita is default and only that gets installed as XFCE dependency, downgrading port to 41 and bumping PORTEPOCH seems reasonable to me.
Comment 5 Jan Beich freebsd_committer freebsd_triage 2023-09-23 23:20:09 UTC
According to https://repology.org/project/adwaita-icon-theme/versions other distributions don't stick to 41 series as the primary one. Someone may need to investigate how XFCE is packaged there instead of guessing based on user discussions.
Comment 6 Jan Beich freebsd_committer freebsd_triage 2023-09-23 23:25:20 UTC
(In reply to Jan Beich from comment #5)
The emphasis is on *currently* packaged. The workarounds discussed in comment 4 references are more than 1 year old. Since then XFCE 4.18 was released.
Comment 7 Anton Saietskii 2023-09-23 23:35:37 UTC
(In reply to Jan Beich from comment #5)

Everything worked with 40.1.1, and broke with 42. No changes have been made in XFCE, and root cause is Adwaita version indeed. I believe one can't blindly commit to ports tree whatever they want without any verification, especially when something else depends on it. This is POLA violation.

If we can't live without Adwaita>41, another default icon set may be selected, for example. But again, breaking that thing which worked is simply not right
Comment 8 Anton Saietskii 2023-09-23 23:37:16 UTC
(In reply to Jan Beich from comment #6)

Pretty obvious that XFCE still uses "legacy" icons from Adwaita. That means Adwaita should stay on legacy version unless XFCE will drop dependency in favor of another icon set.
Comment 9 Guido Falsi freebsd_committer freebsd_triage 2023-09-24 08:24:04 UTC
(In reply to Anton Saietskii from comment #8)

Please try to understand that who committed the update to adwaita did not mean to do any harm and simply committed an upstream upgrade, which is normal policy.   

Please avoid accusations of mischief. It is not possible to test every commit to icon sets with every other port that could be using them before committing a normal version update.

BTW POLA has nothing to do with this. This was not an intentional change but an unintentional regression. Requires fixing anyway but which fix is not obvious.

Keeping ports at older versions is not an option except in extreme cases, and even then it is to be avoided anyway. If XFCE uses some legacy icon names XFCE is at fault [1] and the best that can be done is finding a workaround.

Changing the default icon theme of XFCE also comes with a cost. It would be an intentional gratuitous change that would astonish others. I can evaluate it though.

In the while this can be easily worked around by installing yourself another icon theme and configuring that.

Personally I'm using xfce-icons-elementary which works fine. Could you test installing and configuring it in your desktop and report back if switching XFCE default to that theme would be acceptable to you?

icons-tango + icons-tango-extras also looks fine as an option.



[1] Especially so if these icon names have been deprecated since 2022 or earlier.
Comment 10 Guido Falsi freebsd_committer freebsd_triage 2023-09-24 08:34:50 UTC
(In reply to Guido Falsi from comment #9)

I forgot to mention:

I personally think that reverting the adwaita icon theme update is unacceptable, would risk causing brokenness elsewhere in the tree, and keeping a port at an old version is a way to create landmines ready to explode, so should be avoided.

But if you want old adwaita 41 in the ports tree, you have the option of creating a legacy port for it. If we were to choose to go down this way, would you be willing to do that and maintain it?

This entail you submitting the "new" port for adding it to the tree.
Comment 11 Olivier Duchateau 2023-09-24 09:27:31 UTC
Just a comment, GNOME developers remove some icons in their theme (or move into symbolic). In gnome-shell session there is no "traditional" menu, so no one crying.

I use the 44.0 release and there are more and more missing icons (tested with gnome-flashback, a Gtk3 consumer for Metacity). So with this session I use misc/gnome-icon-theme. I think this icon theme is a legacy.
Comment 12 Jan Beich freebsd_committer freebsd_triage 2023-09-24 19:43:05 UTC
Created attachment 245196 [details]
v1 (apply via "git am")

After testing inside jail + rootful Xwayland:
- gnome-icon-theme better complements default XFCE theme unlike adwaita-icon-theme-40.1.1_1.
  For example, Home icon is back from GNOMEish beige to XFCE blue and File menu icons are monochrome instead of GNOMEish multicolor.
- XScreenSaver Blank/Lock still lack icons but downgrading to adwaita-icon-theme-40.1.1_1 didn't help.
Comment 13 Jan Beich freebsd_committer freebsd_triage 2023-09-24 20:00:52 UTC
Created attachment 245197 [details]
v1 (apply via "git am")

Corrected "Reported by" in the commit message.
Comment 14 Jan Beich freebsd_committer freebsd_triage 2023-09-24 20:01:50 UTC
Created attachment 245198 [details]
v1 (apply via "git am")
Comment 15 Jan Beich freebsd_committer freebsd_triage 2023-09-24 20:09:46 UTC
(In reply to Anton Saietskii from comment #8)
> Pretty obvious that XFCE still uses "legacy" icons from Adwaita.

Where in the code? Applications menu appears to be implemented by x11-wm/xfce4-panel. However, I couldn't find Settings and Accessories there.
Where XFCE sets Adwaita theme? If it doesn't set any theme (relying on gtk3 default) then the meta-port shouldn't directly depend on adwaita-icon-theme.
Comment 16 Guido Falsi freebsd_committer freebsd_triage 2023-09-24 20:22:30 UTC
(In reply to Jan Beich from comment #15)

When I started working on XFCE ports they already had a dependency on adwaita. I tried to switch defaults with the update to 4.16, but the proposal was criticized, so I simply left things untouched.

Simply changing the dependency in the metaport like you did would not fix this issue, since the default is forced via a patch (post-patch target) in the xfce4-settings port [1]. This thing has been there since the addition of the port, but went through some slight changes with time, especially with the update to XFCE 4.12, that added the present changes.

I actually don't know what the XFCE behavior is if that post patch thing is removed. I'll test that and report back.



[1] https://cgit.freebsd.org/ports/tree/sysutils/xfce4-settings/Makefile#n53
Comment 17 Guido Falsi freebsd_committer freebsd_triage 2023-09-24 20:26:51 UTC
Created attachment 245199 [details]
defaults change v1

Attaching a patch I've successfully tested to change the default to xfce-icons-elementary.

This patch also includes a note to be added to UPDATING to inform users.

Also note that the adwaita theme will be depended upon indirectly anyway, since gtk3 requires it.

Before committing this change I'm going to test how things turn out without forcing defaults and not installing any extra theme.
Comment 18 Guido Falsi freebsd_committer freebsd_triage 2023-09-24 20:53:46 UTC
(In reply to Guido Falsi from comment #16)

I actually don't know what the XFCE behavior is if that post patch thing is removed. I'll test that and report back.


Looks like it ends up using the first icon theme it can find, which happens to be adwaita most probably, since it's a dependency of gtk3, and present on the system.

Simply removing the post-patch target is not a good solution.

I think I'll go with the patch I proposed chaging the default to xfce-icons-elementary which is made for XFCE.
Comment 19 commit-hook freebsd_committer freebsd_triage 2023-09-25 07:55:39 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=364a6b8d61e4c0a7991c85fc0e00d122960529c8

commit 364a6b8d61e4c0a7991c85fc0e00d122960529c8
Author:     Guido Falsi <madpilot@FreeBSD.org>
AuthorDate: 2023-09-25 07:53:36 +0000
Commit:     Guido Falsi <madpilot@FreeBSD.org>
CommitDate: 2023-09-25 07:53:36 +0000

    x11-wm/xfce4: Switch default icon set to x11-themes/xfce-icons-elementary

    After the update x11-themes/adwaita-icon-theme update to version
    42.0 (commit 14ac2cbef6484e85669c99a5a8388ea4627f029f) XFCE is not
    compatible with it anymore, due to icons being renamed/removed from
    the theme.

    To work around this, change the default icon theme installed with
    XFCE to x11-themes/xfce-icons-elementary.

    Users with XFCE desktops already configured to use adwaita-icon-theme
    need to install another theme and switch to it manually using the
    XFCE settings "appearance" application, see UPDATING entry 20230924.

    PR:             274057

 UPDATING                         | 15 +++++++++++++++
 sysutils/xfce4-settings/Makefile |  5 +++--
 x11-wm/xfce4/Makefile            |  3 ++-
 3 files changed, 20 insertions(+), 3 deletions(-)
Comment 20 Guido Falsi freebsd_committer freebsd_triage 2023-09-26 09:53:32 UTC
@submitter

Can this be closed as resolved?
Comment 21 Guido Falsi freebsd_committer freebsd_triage 2023-09-29 13:58:11 UTC
XFCE configured to use another icon theme by default.

Manual configuration is required for users who already have the desktop setup, but this is unavoidable and outside of ports scope.

So I'm marking this as resolved.

Please reopen or file a new bug report if issue comes up again.