Skip to content

Conversation

Kafva
Copy link

@Kafva Kafva commented Sep 10, 2022

I have noticed that the window mode does not pick up certain icons from the icon theme set in gtk-3.0.ini. Looking at window.c I can see that this is to be expected since the class name that is used to look up the icon name is not guaranteed to be correct.

However, currently the NETWM icon seems to override any GTK icons that are found, this patch is meant to address this.

Before/after patch using:

[Settings]
gtk-icon-theme-name=Papirus-Dark

# rofi -show window

(theme)
before
after

@DaveDavenport
Copy link
Collaborator

I don't think this patch implements correct behavior.
The icon the application explicitly sets for itself should get priority.
(some) Applications use this to relay extra information to the user.

@Kafva
Copy link
Author

Kafva commented Sep 10, 2022

Oh ye, I assume you mean like an email app setting "X unread messages" in the corner of the icon?
I would personally prefer that the icons always try to follow the theme but I guess that behaviour is worth preserving for other use cases.

@DaveDavenport
Copy link
Collaborator

maybe get the applications to use the correct icon theme instead?

@Kafva
Copy link
Author

Kafva commented Sep 10, 2022

Hmmm ye, I guess the source of the problem isn't really rofi but how my environment sets (or does not set) the application icons that are sent. Definitely seems better to fix that instead if that is the case.

@Kafva
Copy link
Author

Kafva commented Sep 10, 2022

I tried my patch in a different window manager (awesomewm instead of bspwm) but saw the same behaviour as shown in my prior screenshots.

Were you implying earlier that each individual application (kitty, obs etc.) would need to be patched to provide an icon from the active GTK theme (in queries for their NET_WM_ICON) or is this something that the WM/DE has control over/should handle?

@DaveDavenport
Copy link
Collaborator

I have no idea what a window manager has to do with what icon an application set for itself.

I don't know how applications exactly do this, I guess it depends on the application.

But I am not going to change rofi default behavior, that seems correct, because a user finds it 'ugly'.

@Kafva
Copy link
Author

Kafva commented Sep 10, 2022

Ye, the window manager is probably unrelated 😅

My main gripe with the current behaviour is that the drun mode does show icons from the GTK theme, so it feels inconsistent that another mode shows different icons.

But I am fine with using my fork instead if this is not desirable as the default.

@Kafva Kafva closed this Sep 10, 2022
@DaveDavenport
Copy link
Collaborator

DaveDavenport commented Sep 10, 2022

I don't think you read my reply right. I am not going to change the default behaviour, this does not rule out an config option to change the default behaviour.

@Kafva
Copy link
Author

Kafva commented Sep 10, 2022

Oh ok, I guess I will reopen the issue then.

@Kafva Kafva reopened this Sep 10, 2022
@DaveDavenport
Copy link
Collaborator

I think gtk icons is not the right name, -window-prefer-icon-theme is better.

@@ -585,6 +585,9 @@ Default: *"wmctrl -i -R {window}"*

Show window thumbnail (if available) as icon in the window switcher.

`-window-prefer-icon-theme`

Use icons from the current GTK theme in window mode.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not 'gtk theme'. It is the icon theme set, this is not directly dependent on gtk.
Rofi f.e. has it own set icon-theme option, and this will be used when set.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I changed it to 'icon theme', does it need to be more verbose in some other way?

} else if (c->icon == NULL && c->icon_checked == FALSE) {
c->icon = get_net_wm_icon(rmpd->ids->array[selected_line], size);
c->icon_checked = TRUE;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this logic correct? when config.window_prefer_icon_theme is not set, it will never fall back to the 'class icon' when the application has no net_wm_icon set.
It now always requests this icon, even when not used. This seems wasteful.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried to address this in 4bd7d3b

Kafva added 2 commits September 10, 2022 20:05
Only fetch the NET_WM_ICON and theme icon when their counterpart is NULL as a
fallback for each state of the `-window-prefer-icon-theme` flag.
@DaveDavenport
Copy link
Collaborator

Going over the patch, there is a small possible glitching issue. It might show the application set by the application, then the one from the theme.
To fix this an extension needs to be made to rofi_icon_fetcher. I will look at this.

@DaveDavenport DaveDavenport added this to the 1.7.6 milestone Oct 3, 2022
@DaveDavenport
Copy link
Collaborator

Pushed the extension to rofi_icon_fetcher and directly implemented this request (this exposed another small issue, so decided to commit the whole).

Can you test?

@DaveDavenport DaveDavenport reopened this Oct 22, 2022
DaveDavenport added a commit that referenced this pull request Oct 22, 2022
Thanks to Kafva (https://github.com/Kafva) for the original patch.

Issue: #1702
@DaveDavenport
Copy link
Collaborator

   You can prefer the icon theme above the window set icon with the 'prefer-icon-theme' setting:

          configuration {
            window {
                prefer-icon-theme: true;
            }
          }

   or pass -window-prefer-icon-theme true on command line.

@Kafva
Copy link
Author

Kafva commented Oct 22, 2022

Ye, tested the new option via CLI and from the config file, both seem to work as expected 🙂

@Kafva Kafva closed this Oct 22, 2022
@github-actions
Copy link

This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Nov 23, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants