[PR #1093] [MERGED] fix(launcher): improve app ID handling: fallback for desktop entries.… #6758

New issue

Closed

opened 2026-05-23 01:57:01 +01:00 by JakeStanger · 0 comments

JakeStanger commented

2026-05-23 01:57:01 +01:00

Owner

📋 Pull Request Information

Original PR: https://github.com/JakeStanger/ironbar/pull/1093
Author: @slowsage
Created: 7/19/2025
Status: ✅ Merged
Merged: 8/5/2025
Merged by: @JakeStanger

Base: master ← Head: wmclass-async

📝 Commits (1)

0159c01 fix: app_id StartupWMClass resolution in launcher

📊 Changes

1 file changed (+40 additions, -21 deletions)

View changed files

📝 src/modules/launcher/mod.rs (+40 -21)

📄 Description

… Fixes: #487

This approach has decent enough defaults and we will not need to change the config parsing as I initially suggested (#487). A mapping can be forced by setting StartupWMClass in the .desktop file.

The app_id found in window/desktop environment will first be matched against the string specified in the favorites list (items, initially). Failing that, it will try to reverse lookup the app_id as a startup_wm_class. the reverse lookup dict wm_app_ids is a map from startup_wm_class to app_id that the app was initialized with.

As long as the same app is launched with the same wm_class, duplicates are handled for both favorites (secondary lookup to find key as it was specified in config file) and non-favorites (app_id/wm_class wont be in favorites, so the app_id passed in will be used as key).

Want to let it run for a bit but figured I'd send what I have for feedback.

P.S. To avoid a secondary IndexMap, I looked at using multi_map but that uses Hashmap underneath - which will not preserve order.
This is the datastructure we need eventually IMO.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/JakeStanger/ironbar/pull/1093 **Author:** [@slowsage](https://github.com/slowsage) **Created:** 7/19/2025 **Status:** ✅ Merged **Merged:** 8/5/2025 **Merged by:** [@JakeStanger](https://github.com/JakeStanger) **Base:** `master` ← **Head:** `wmclass-async` --- ### 📝 Commits (1) - [`0159c01`](https://github.com/JakeStanger/ironbar/commit/0159c0155e96dae4d10090b539481418a5a34546) fix: app_id StartupWMClass resolution in launcher ### 📊 Changes **1 file changed** (+40 additions, -21 deletions) <details> <summary>View changed files</summary> 📝 `src/modules/launcher/mod.rs` (+40 -21) </details> ### 📄 Description … Fixes: #487 This approach has decent enough defaults and we will not need to change the config parsing as I initially suggested (#487). A mapping can be forced by setting StartupWMClass in the .desktop file. The app_id found in window/desktop environment will first be matched against the string specified in the favorites list (`items`, initially). Failing that, it will try to reverse lookup the app_id as a startup_wm_class. the reverse lookup dict `wm_app_ids` is a map from startup_wm_class to app_id that the app was initialized with. As long as the same app is launched with the same wm_class, duplicates are handled for both favorites (secondary lookup to find key as it was specified in config file) and non-favorites (app_id/wm_class wont be in favorites, so the app_id passed in will be used as key). Want to let it run for a bit but figured I'd send what I have for feedback. P.S. To avoid a secondary IndexMap, I looked at using [multi_map](https://docs.rs/multi-map/latest/multi_map/) but that uses Hashmap underneath - which will not preserve order. [This](https://github.com/lun3x/multi_index_map/issues/60) is the datastructure we need eventually IMO. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

JakeStanger

2026-05-23 01:57:01 +01:00