JakeStanger/ironbar

Fork 0

mirror of https://github.com/JakeStanger/ironbar.git synced 2026-07-11 10:15:20 +01:00

[GH-ISSUE #534] XDG menu #1583

New issue

Closed

opened 2026-05-22 22:53:18 +01:00 by JakeStanger · 14 comments

JakeStanger commented

2026-05-22 22:53:18 +01:00

Owner

Originally created by @ClaireNeveu on GitHub (Apr 6, 2024).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/534

Originally assigned to: @ClaireNeveu on GitHub.

Is your feature request related to a problem? Please describe.
The Launcher module is great for frequently accessed programs but right now ironbar doesn't provide a solution to infrequently used programs that you don't want cluttering the bar all the time. You mentioned in https://github.com/JakeStanger/ironbar/issues/194 that you don't really want to embed a rofi-like menu (like KDE does) but would you be open to a customizable XDG menu sort of like XFCE?

Describe the solution you'd like
The interface would be something like:

 - type: menu
   xdg_menu: true
   before:
   - label: Run Program
     action: "wofi --show drun"
   - label: Terminal
     action: "xterm"
   after:
   - label: logout
     action: "wlogout"

Describe alternatives you've considered
I've thought about building something with the custom modules but you can't dynamically decide which GTK elements are present.

Additional context
I'd be willing to contribute the module to ironbar if the idea is acceptable.

Originally created by @ClaireNeveu on GitHub (Apr 6, 2024). Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/534 Originally assigned to: @ClaireNeveu on GitHub. **Is your feature request related to a problem? Please describe.** The Launcher module is great for frequently accessed programs but right now ironbar doesn't provide a solution to infrequently used programs that you don't want cluttering the bar all the time. You mentioned in https://github.com/JakeStanger/ironbar/issues/194 that you don't really want to embed a rofi-like menu (like KDE does) but would you be open to a customizable XDG menu sort of like XFCE? ![xdg-menu](https://github.com/JakeStanger/ironbar/assets/1002726/7ed77b36-91f9-48c3-886c-13439fb71259) **Describe the solution you'd like** The interface would be something like: ```yaml - type: menu xdg_menu: true before: - label: Run Program action: "wofi --show drun" - label: Terminal action: "xterm" after: - label: logout action: "wlogout" ``` **Describe alternatives you've considered** I've thought about building something with the custom modules but you can't dynamically decide which GTK elements are present. **Additional context** I'd be willing to contribute the module to ironbar if the idea is acceptable.

JakeStanger

2026-05-22 22:53:18 +01:00

closed this issue
added the
T:New Module
label

JakeStanger commented

2026-05-22 22:53:19 +01:00

Author

Owner

@JakeStanger commented on GitHub (Apr 6, 2024):

I think this is acceptable because it's fairly light and stays within the confines of the bar. My main concern with a rofi-style launcher is that quickly becomes its own project, with its own set of modules and own logic and own window etc etc. A simple menu can just grab the data it needs and render and leave it at that.

What is the idea of the xdg_menu option. Would it just display the before/after options with that off? I also think start and end would be preferable to keep in line with the existing config terms.

If you're willing to take this on yourself, go for it!

I've thought about building something with the custom modules but you can't dynamically decide which GTK elements are present.

Yet ;)

(I still think this is a good native module regardless)

@JakeStanger commented on GitHub (Apr 6, 2024): I think this is acceptable because it's fairly light and stays within the confines of the bar. My main concern with a rofi-style launcher is that quickly becomes its own project, with its own set of modules and own logic and own window etc etc. A simple menu can just grab the data it needs and render and leave it at that. What is the idea of the `xdg_menu` option. Would it just display the `before`/`after` options with that off? I also think `start` and `end` would be preferable to keep in line with the existing config terms. If you're willing to take this on yourself, go for it! > I've thought about building something with the custom modules but you can't dynamically decide which GTK elements are present. Yet ;) (I still think this is a good native module regardless)

JakeStanger commented

2026-05-22 22:53:19 +01:00

Author

Owner

@ClaireNeveu commented on GitHub (Apr 6, 2024):

What is the idea of the xdg_menu option. Would it just display the before/after options with that off?

Exactly. I figure some people might just want a menu with various options in it.

@ClaireNeveu commented on GitHub (Apr 6, 2024): > What is the idea of the `xdg_menu` option. Would it just display the `before`/`after` options with that off? Exactly. I figure some people might just want a menu with various options in it.

JakeStanger commented

2026-05-22 22:53:19 +01:00

Author

Owner

@ClaireNeveu commented on GitHub (Apr 6, 2024):

FWIW I think KDE provides a good model for a restrained launcher where the text entry is basically just a search of the existing menu. A launcher doesn't have to evolve into a full extensible anyrun style thing (and those two things can co-exist).

@ClaireNeveu commented on GitHub (Apr 6, 2024): FWIW I think KDE provides a good model for a restrained launcher where the text entry is basically just a search of the existing menu. A launcher doesn't _have_ to evolve into a full extensible anyrun style thing (and those two things can co-exist). ![Screenshot_20240406-173800](https://github.com/JakeStanger/ironbar/assets/1002726/e1b98bc0-bb58-40c7-8a86-5b0199575310)

JakeStanger commented

2026-05-22 22:53:19 +01:00

Author

Owner

@JakeStanger commented on GitHub (Apr 10, 2024):

I think there is possible utility in that, but it's potentially limited. Why use a menu like that over anyrun and the likes? What does it bring to the table that a runner doesn't, and how do we keep the scope under control?

I'm not against it, but as it would take quite a bit more work (to both develop and support), I think it needs to be properly thought out, planned and justified.

@JakeStanger commented on GitHub (Apr 10, 2024): I think there is possible utility in that, but it's potentially limited. Why use a menu like that over anyrun and the likes? What does it bring to the table that a runner doesn't, and how do we keep the scope under control? I'm not against it, but as it would take quite a bit more work (to both develop and support), I think it needs to be properly thought out, planned and justified.

JakeStanger commented

2026-05-22 22:53:19 +01:00

Author

Owner

@ClaireNeveu commented on GitHub (May 7, 2024):

As an update: I have a very rough POC at https://github.com/ClaireNeveu/ironbar/tree/menu-widget. Been slowly picking away at it over the last month and after more polish and cleanup I'll put it up for review.

@ClaireNeveu commented on GitHub (May 7, 2024): As an update: I have a very rough POC at https://github.com/ClaireNeveu/ironbar/tree/menu-widget. Been slowly picking away at it over the last month and after more polish and cleanup I'll put it up for review.

JakeStanger commented

2026-05-22 22:53:19 +01:00

Author

Owner

@JakeStanger commented on GitHub (May 10, 2024):

Thanks for the update, I've had a very brief scan of the code and it's looking good so far.

@JakeStanger commented on GitHub (May 10, 2024): Thanks for the update, I've had a very brief scan of the code and it's looking good so far.

JakeStanger commented

2026-05-22 22:53:19 +01:00

Author

Owner

@ClaireNeveu commented on GitHub (May 18, 2024):

@JakeStanger I'm planning to implement a Grab so I can close and reset the menu when someone clicks outside of it. Since ironbar uses a single centralized popup I'll need to edit it at that level. Is it ok with you for all popups to close when clicked outside of or will I need to build an API to pass events to the individual modules to decide their behavior?

@ClaireNeveu commented on GitHub (May 18, 2024): @JakeStanger I'm planning to implement a [Grab](https://gtk-rs.org/gtk3-rs/stable/latest/docs/gdk/struct.Seat.html#method.grab) so I can close and reset the menu when someone clicks outside of it. Since ironbar uses a single centralized popup I'll need to edit it at that level. Is it ok with you for *all* popups to close when clicked outside of or will I need to build an API to pass events to the individual modules to decide their behavior?

JakeStanger commented

2026-05-22 22:53:19 +01:00

Author

Owner

@JakeStanger commented on GitHub (May 18, 2024):

Good question. It's something I've been considering in the back of my mind for a while.

The current close-on-mouse-leave solution is good enough in most cases, but imperfect, and also likely not everybody's preference. It would therefore be nice to have a close-on-click behaviour as an option, but I wouldn't want it to replace the current behaviour.

If it were an option, I'd probably define it at the bar level. I guess it wouldn't be much work from there to add it to CommonConfig to allow for overriding per-widget, or let a widget natively decide its close behaviour. I'd want to keep things as consistent as possible though.

What is the reason for wanting to to be close-on-click? Is it just because the current mouse-leave behaviour makes for bad UX with this style menu?

@JakeStanger commented on GitHub (May 18, 2024): Good question. It's something I've been considering in the back of my mind for a while. The current close-on-mouse-leave solution is good enough in most cases, but imperfect, and also likely not everybody's preference. It would therefore be nice to have a close-on-click behaviour as an option, but I wouldn't want it to replace the current behaviour. If it were an option, I'd probably define it at the bar level. I guess it wouldn't be much work from there to add it to `CommonConfig` to allow for overriding per-widget, or let a widget natively decide its close behaviour. I'd want to keep things as consistent as possible though. What is the reason for wanting to to be close-on-click? Is it just because the current mouse-leave behaviour makes for bad UX with this style menu?

JakeStanger commented

2026-05-22 22:53:19 +01:00

Author

Owner

@ClaireNeveu commented on GitHub (May 18, 2024):

What is the reason for wanting to to be close-on-click? Is it just because the current mouse-leave behaviour makes for bad UX with this style menu?

@JakeStanger Mainly that it's bad UX and bad accessibility for a menu.

@ClaireNeveu commented on GitHub (May 18, 2024): > What is the reason for wanting to to be close-on-click? Is it just because the current mouse-leave behaviour makes for bad UX with this style menu? @JakeStanger Mainly that it's bad UX and bad accessibility for a menu.

JakeStanger commented

2026-05-22 22:53:19 +01:00

Author

Owner

@JakeStanger commented on GitHub (May 18, 2024):

Cool, I think that's a good enough reason :)

I may be over-engineering this so feel free to suggest an alternative, but here's the scenario in my head:

The default behaviour can be set at the top-level (or bar level?). If unset, this defaults to hover to keep the current behaviour.
Modules can specify an override (in code) to say "this should use close-on-click, even if hover is set as the global default".
Ideally, CommonConfig provides an option to override that override, so it's never hard-coded.

The last point, I think is probably a stretch goal of sorts and isn't needed, but would round things out. I assume there'll be someone somewhere who'd want the option?

How does that sound? If you want me to take some/all of that on let me know too, as I appreciate the scope is growing a bit here.

@JakeStanger commented on GitHub (May 18, 2024): Cool, I think that's a good enough reason :) I may be over-engineering this so feel free to suggest an alternative, but here's the scenario in my head: - The default behaviour can be set at the top-level (or bar level?). If unset, this defaults to hover to keep the current behaviour. - Modules can specify an override (in code) to say "this should use close-on-click, even if hover is set as the global default". - Ideally, `CommonConfig` provides an option to override *that* override, so it's never hard-coded. The last point, I think is probably a stretch goal of sorts and isn't *needed*, but would round things out. I assume there'll be someone somewhere who'd want the option? How does that sound? If you want me to take some/all of that on let me know too, as I appreciate the scope is growing a bit here.

JakeStanger commented

2026-05-22 22:53:20 +01:00

Author

Owner

@ClaireNeveu commented on GitHub (May 18, 2024):

That sounds good. I think I'll deliver the initial menu without that change and then circle back to add it just to keep the scope down.

I'm quite close to finished now I just need to work out how to set the vertical alignment on menus based on the bar & widget position.

@ClaireNeveu commented on GitHub (May 18, 2024): That sounds good. I think I'll deliver the initial menu without that change and then circle back to add it just to keep the scope down. I'm quite close to finished now I just need to work out how to set the vertical alignment on menus based on the bar & widget position.

JakeStanger commented

2026-05-22 22:53:20 +01:00

Author

Owner

@JakeStanger commented on GitHub (May 18, 2024):

Perfect, sounds great.

You can use info.bar_position, and that has an orientation method on it if you haven't found that yet btw.

@JakeStanger commented on GitHub (May 18, 2024): Perfect, sounds great. You can use `info.bar_position`, and that has an `orientation` method on it if you haven't found that yet btw.

JakeStanger commented

2026-05-22 22:53:20 +01:00

Author

Owner

@ClaireNeveu commented on GitHub (May 18, 2024):

Here's the current menu, btw. I did find info.bar_position but in order to work correctly we also need to know if the module is in start, center, or end.

If you have a vertical bar with the menu in start then you want all the menus to line up at the top but if it's in end then you want them to line up on the bottom. Any other behavior will cause the main menu to jump around if you open a sub-menu with more items.

@ClaireNeveu commented on GitHub (May 18, 2024): ![menu](https://github.com/JakeStanger/ironbar/assets/1002726/19190750-1124-4738-a497-5795a17611e2) Here's the current menu, btw. I did find `info.bar_position` but in order to work correctly we also need to know if the module is in `start`, `center`, or `end`. If you have a vertical bar with the menu in `start` then you want all the menus to line up at the top but if it's in `end` then you want them to line up on the bottom. Any other behavior will cause the main menu to jump around if you open a sub-menu with more items.

JakeStanger commented

2026-05-22 22:53:20 +01:00

Author

Owner

@JakeStanger commented on GitHub (May 18, 2024):

Ah okay that makes sense. info.location should cover that (left/right equate to start/end, I just never updated the names)

Looking good too!

@JakeStanger commented on GitHub (May 18, 2024): Ah okay that makes sense. `info.location` should cover that (left/right equate to start/end, I just never updated the names) Looking good too!