search

bbidulock / icewm

A window manager designed for speed, usability, and consistency
Other
571 stars 97 forks source link

Draft: Propagate meta key events from submenues as closing action to... #677

Closed Code7R closed 1 year ago

Code7R commented 1 year ago

… parent menus

Code7R commented 1 year ago

This solves the issue of pressing Win-Key inside of the menu. That worked on the parent level, handled via StartMenu::handleKey, but it failed in any other submenu. Works for me but I am not sure about side effects.

gijsbers commented 1 year ago

If the goal is to be able popdown the entire menu chain, I would change the meaning of Escape to do just that. At the location in ymenu.cc the case if (k == XK_Escape) { could popdown all menus right there in a loop. This commit touches 11 files for a single simple non-reusable use-case and introduces new keybindings which to me weren't obvious and hence also not for others. Then Left can popdown a single menu, also the last one. Thus a maximum functional effect for a minimal change in code is achieved.

Code7R commented 1 year ago

Are you saying that the change is not minimal? Sorry, they are ONE-LINER changes in interfaces or intermediate classes. How do you expect one to reduce the number of changed files while affected classes are spread among multiple files?

If there is a simpler way to fix this which is less intrusive, does not change interfaces AND without risk of other side effects then please reveal it. Otherwise let's get serious, can we?

Also, what do you mean with "new key bindings"? This is the very same key binding which would close the root level menu when the event arrives in StartMenu::handleKey. If I am overlooking something, feel free to explain, but please only with facts.

And why would someone change the meaning of the Escape key? I find it quite natural as it currently is. The only thing which looks strange ATM is that a meta key (i.e. Win) closes the menu when you are on the root level menu but not from inside of a submenu.