ironbar
ironbar copied to clipboard
JakeStanger
XDG menu
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.
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)
What is the idea of the
xdg_menuoption. Would it just display thebefore/afteroptions with that off?
Exactly. I figure some people might just want a menu with various options in it.
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).
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.
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.
Thanks for the update, I've had a very brief scan of the code and it's looking good so far.
@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?
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?
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.
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,
CommonConfigprovides 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.
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.
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.
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.
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!