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

XDG menu #534

Open
ClaireNeveu opened this issue Apr 6, 2024 · 14 comments · May be fixed by #609
Open

XDG menu #534

ClaireNeveu opened this issue Apr 6, 2024 · 14 comments · May be fixed by #609
Assignees
Labels
enhancement New feature or request
Milestone

Comments

@ClaireNeveu
Copy link
Contributor

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 #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

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.

@ClaireNeveu ClaireNeveu added the enhancement New feature or request label Apr 6, 2024
@JakeStanger
Copy link
Owner

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)

@ClaireNeveu
Copy link
Contributor Author

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
Copy link
Contributor Author

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

@JakeStanger
Copy link
Owner

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.

@ClaireNeveu
Copy link
Contributor Author

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
Copy link
Owner

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

@ClaireNeveu
Copy link
Contributor Author

@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?

@JakeStanger
Copy link
Owner

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?

@ClaireNeveu
Copy link
Contributor Author

ClaireNeveu commented 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
Copy link
Owner

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.

@ClaireNeveu
Copy link
Contributor Author

ClaireNeveu commented 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
Copy link
Owner

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.

@ClaireNeveu
Copy link
Contributor Author

menu
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
Copy link
Owner

JakeStanger commented 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 JakeStanger linked a pull request May 29, 2024 that will close this issue
@JakeStanger JakeStanger added this to the 0.16.0 milestone May 30, 2024
@JakeStanger JakeStanger modified the milestones: 0.16.0, 0.17.0 Aug 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants