[GH-ISSUE #1017] Breaking changes to app ID resolution #1724

New issue

Open

opened 2026-05-22 22:54:13 +01:00 by JakeStanger · 2 comments

JakeStanger commented

2026-05-22 22:54:13 +01:00

Owner

Originally created by @BowDown097 on GitHub (May 28, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1017

Describe the bug
It appears what likely is commit 3e55d87 has broken resolution of app IDs in some cases (at least compared to prior behavior), such as with Qt Creator running under XWayland, which I will use as an example with launcher favorites.

To reproduce
Steps to reproduce the behavior:

Add module launcher
Under favorites section, add "QtCreator" (XWayland app ID, verified with wf-info)
Bare entry is created, with no icon and unopenable. Instances of the program will still be merged with this bare entry, though. Using other app IDs such as "qtcreator" and "org.qt-project.qtcreator" will create a functional favorite entry, but instances of the program will take up an additional, still bare entry.

Expected behavior
With the prior behavior, under the previously mentioned conditions, a fully functional entry with an icon would be created, with instances of the program merging into it as expected.

System information:

Distro: Artix Linux
Compositor: Wayfire
Ironbar version: 0.16.1.r332.gb62d0d5-1

Configuration

Config

[[start]]
type = "launcher"
favorites = [
    "launcher",
    "pcmanfm-qt",
    "zen",
    "legcord",
    "mpc-qt",
    "URxvt",
    "QtCreator",
    "VSCodium",
    "jetbrains-rider",
    "QtTube"
]
icon_size = 48
show_names = false
show_icons = true

Additional context
Another thing of note that I found whilst messing with this. With the StartupWMClass in the .desktop file changed to "QtCreator" (by default, it is qtcreator), a functional entry is STILL not created. Looking at the source code, it does appear that the StartupWMClass is handled in some way at least. Has this also been broken?

Screenshots
In these screenshots, congruent with the above config, Qt Creator is the 7th favorite, and the open instance of it is highlighted.
Using "QtCreator" as the entry, with Qt Creator opened:

Using "qtcreator" or "org.qt-project.qtcreator" as the entry, with Qt Creator opened:

Originally created by @BowDown097 on GitHub (May 28, 2025). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/1017 **Describe the bug** It appears what likely is commit 3e55d87 has broken resolution of app IDs in some cases (at least compared to prior behavior), such as with Qt Creator running under XWayland, which I will use as an example with launcher favorites. **To reproduce** Steps to reproduce the behavior: 1. Add module `launcher` 2. Under ``favorites`` section, add "QtCreator" (XWayland app ID, verified with wf-info) 3. Bare entry is created, with no icon and unopenable. Instances of the program will still be merged with this bare entry, though. Using other app IDs such as "qtcreator" and "org.qt-project.qtcreator" will create a functional favorite entry, but instances of the program will take up an additional, still bare entry. **Expected behavior** With the prior behavior, under the previously mentioned conditions, a fully functional entry with an icon would be created, with instances of the program merging into it as expected. **System information:** - Distro: Artix Linux - Compositor: Wayfire - Ironbar version: 0.16.1.r332.gb62d0d5-1 **Configuration**  <details><summary>Config</summary> ``` [[start]] type = "launcher" favorites = [ "launcher", "pcmanfm-qt", "zen", "legcord", "mpc-qt", "URxvt", "QtCreator", "VSCodium", "jetbrains-rider", "QtTube" ] icon_size = 48 show_names = false show_icons = true ``` </details> **Additional context** Another thing of note that I found whilst messing with this. With the StartupWMClass in the .desktop file changed to "QtCreator" (by default, it is qtcreator), a functional entry is STILL not created. Looking at the source code, it does appear that the StartupWMClass is handled in some way at least. Has this also been broken? **Screenshots** In these screenshots, congruent with the above config, Qt Creator is the 7th favorite, and the open instance of it is highlighted. Using "QtCreator" as the entry, with Qt Creator opened: ![Image](https://github.com/user-attachments/assets/8ff90fca-4b24-42be-9393-7ceaed9c6f0c) Using "qtcreator" or "org.qt-project.qtcreator" as the entry, with Qt Creator opened: ![Image](https://github.com/user-attachments/assets/820e47a7-6102-4976-9caf-c27b655aa920)

JakeStanger added the

labels

2026-05-22 22:54:13 +01:00

JakeStanger commented

2026-05-22 22:54:13 +01:00

Author

Owner

@JakeStanger commented on GitHub (Jun 3, 2025):

Thanks for the detailed report. The overhaul was not supposed to change any of the actual implementation logic, but looks like something has slipped through.

@JakeStanger commented on GitHub (Jun 3, 2025): Thanks for the detailed report. The overhaul was not supposed to change any of the actual implementation logic, but looks like something has slipped through.

JakeStanger commented

2026-05-22 22:54:13 +01:00

Author

Owner

@JakeStanger commented on GitHub (Sep 7, 2025):

Planning on giving the launcher module lots of attention specifically for the next big update. I'll look at this then, to try and build in some proper features for mapping favourites/app IDs more robustly. Otherwise I suspect I'll just be chasing my tail trying to get an imperfect system to work

@JakeStanger commented on GitHub (Sep 7, 2025): Planning on giving the `launcher` module lots of attention specifically for the next big update. I'll look at this then, to try and build in some proper features for mapping favourites/app IDs more robustly. Otherwise I suspect I'll just be chasing my tail trying to get an imperfect system to work