Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[REQUEST] Internal API to access drun desktop entry cache from other modes #1935

Open
2 tasks done
alebastr opened this issue Jan 10, 2024 · 1 comment
Open
2 tasks done

Comments

@alebastr
Copy link

Before opening a feature request

  • I checked the next branch to see if the feature has already been implemented
  • I searched existing reports to see if it is already requested.

What is the user problem or growth opportunity you want to see solved?

In absence of _NET_WM_ICON or WM_ICON_NAME, the recommended path to the application icon for window mode is WM_CLASS (or Wayland app_id) -> $WM_CLASS.desktop -> Icon.

For an added fun, it could be necessary to match by StartupWMClass instead of the .desktop filename (e.g. org.codeberg.dnkl.foot.desktop with StartupWMClass=foot and app_id foot).

It wouldn't be too complicated to duplicate the lookup logic, but the code already exists, with all the optimizations and file-based cache. It just needs to be exposed to other modes.

How do you know that this problem exists today? Why is this important?

window mode both here and in the Wayland fork assumes that the icon name is a lower-case of WM_CLASS or app_id. That's not always true and we we're not able to display an icon for affected applications.

Who will benefit from it?

Mostly Wayland fork. But XCB window mode could leverage the same logic to resolve the icons from WM_CLASS.

Rofi version (rofi -v)

1.7.5

Configuration

Additional information

No response

@DaveDavenport
Copy link
Collaborator

I agree it would be nice, but not sure how this would be implemented in a way it does not break some of the abstractions that are in the modes/plugins. As mentioned in previous issue, I don't really want to break this.

I think if somebody is willing to do this, we should move the desktop file parser into a separate part with an api that in the background get used by both drun and window..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants