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

Select the first menu item when activating a menu from the keyboard #102

Closed
joewing opened this Issue Dec 17, 2013 · 5 comments

Comments

Projects
None yet
3 participants
@joewing
Owner

joewing commented Dec 17, 2013

When a key binding causes a menu to appear, currently no menu item is selected. The desired behavior is to select the first item automatically.

@Israel-D

This comment has been minimized.

Show comment
Hide comment
@Israel-D

Israel-D Jul 31, 2015

Contributor

I think this is a reasonable thing to do, especially if it can be figured out how to bind Meta/Super/Win to open the menu (like on other DE and other OS). Then navigating JWM could be extremely keyboard oriented.

Could it be possible to (in theory) swallow an input bar (for searching) and have it as the first item (to take focus). Swallowing programs into the menus could open up the possibility of extending JWM to some really interesting territory, especially if there is the possibility of using native JWM dialogs... there could be an entire sub-architecture for scripting some really interesting things.

Just a thought... I can open it as a new issue if you are interested (or you can). It might be too complex to do, or maybe not something that is demanded/desired.

Anyhow thanks for all you do for the JWM community your hard work is definitely appreciated!!

Contributor

Israel-D commented Jul 31, 2015

I think this is a reasonable thing to do, especially if it can be figured out how to bind Meta/Super/Win to open the menu (like on other DE and other OS). Then navigating JWM could be extremely keyboard oriented.

Could it be possible to (in theory) swallow an input bar (for searching) and have it as the first item (to take focus). Swallowing programs into the menus could open up the possibility of extending JWM to some really interesting territory, especially if there is the possibility of using native JWM dialogs... there could be an entire sub-architecture for scripting some really interesting things.

Just a thought... I can open it as a new issue if you are interested (or you can). It might be too complex to do, or maybe not something that is demanded/desired.

Anyhow thanks for all you do for the JWM community your hard work is definitely appreciated!!

@dumblob

This comment has been minimized.

Show comment
Hide comment
@dumblob

dumblob Aug 1, 2015

Actually, about 6 years ago, I was thinking about JWM supporting swallowing tray, because I wanted to know which tray applications are running (and be able to operate them), because I'm not using any bar.

So if it's not much work to support swallowing windows in menu, I'd definitely advocate for that.

Aside from that, couple years ago I made an improvement of the old myGtkMenu into myGtkMenu improved - e.g. added vi-like bindings and centering of the menu and some other minor stuff while retaining as high source-code compatibility (i.e. minimal diff) to the original myGtkMenu as possible.

But my ultimate goal is to have destop operated only through menus in a pseudo-optimal way. E.g. I'd like to open (sub)menus in a position vertically centered just next to the item currently selected in the parent menu (if it's root menu, then the middle item in the list should be selected after menu activation/appearance) and having the item vertically in the center selected. Also I'd like to have configurable key bindings and the application swallowing as described above.

Feel free to get inspired by these crazy ideas and maybe implement them (I would be so pleased that I would send you a beer or some money 😉).

dumblob commented Aug 1, 2015

Actually, about 6 years ago, I was thinking about JWM supporting swallowing tray, because I wanted to know which tray applications are running (and be able to operate them), because I'm not using any bar.

So if it's not much work to support swallowing windows in menu, I'd definitely advocate for that.

Aside from that, couple years ago I made an improvement of the old myGtkMenu into myGtkMenu improved - e.g. added vi-like bindings and centering of the menu and some other minor stuff while retaining as high source-code compatibility (i.e. minimal diff) to the original myGtkMenu as possible.

But my ultimate goal is to have destop operated only through menus in a pseudo-optimal way. E.g. I'd like to open (sub)menus in a position vertically centered just next to the item currently selected in the parent menu (if it's root menu, then the middle item in the list should be selected after menu activation/appearance) and having the item vertically in the center selected. Also I'd like to have configurable key bindings and the application swallowing as described above.

Feel free to get inspired by these crazy ideas and maybe implement them (I would be so pleased that I would send you a beer or some money 😉).

@dumblob

This comment has been minimized.

Show comment
Hide comment
@dumblob

dumblob Aug 1, 2015

The left menu is parent menu opened out of nowhere (and thus it has the middle item (red), or the first item from the middle pair in case of even number of items, selected). Then, after pressing e.g. a right arrow key, the right menu will appear vertically centered as shown and the corresponding item (next to the red one) will get selected. The newly selected item is depicted in blue.

parent_menu_and_submenu_s

dumblob commented Aug 1, 2015

The left menu is parent menu opened out of nowhere (and thus it has the middle item (red), or the first item from the middle pair in case of even number of items, selected). Then, after pressing e.g. a right arrow key, the right menu will appear vertically centered as shown and the corresponding item (next to the red one) will get selected. The newly selected item is depicted in blue.

parent_menu_and_submenu_s

@Israel-D

This comment has been minimized.

Show comment
Hide comment
@Israel-D

Israel-D Aug 1, 2015

Contributor

As long as the menu is confined to the screen bounds and can operate normally for those of us using a Tray. I keep my tray up top and the menu drops down, others keep it on the bottom (or sides)... so it would have to figure out how to position the submenu and either select the center, top or bottom item this way.

It seems like ultimately it might be easier to create a standalone menu (like yours, possibly) that does this. It might be possible to extend it to have a minimal interior dock for swallowing small python scripts using the glade ui files? I personally don't use GTK, so I have very little experience with what it is capable of (or not).

Contributor

Israel-D commented Aug 1, 2015

As long as the menu is confined to the screen bounds and can operate normally for those of us using a Tray. I keep my tray up top and the menu drops down, others keep it on the bottom (or sides)... so it would have to figure out how to position the submenu and either select the center, top or bottom item this way.

It seems like ultimately it might be easier to create a standalone menu (like yours, possibly) that does this. It might be possible to extend it to have a minimal interior dock for swallowing small python scripts using the glade ui files? I personally don't use GTK, so I have very little experience with what it is capable of (or not).

@dumblob

This comment has been minimized.

Show comment
Hide comment
@dumblob

dumblob Aug 1, 2015

It seems like ultimately it might be easier to create a standalone menu (like yours, possibly) that does this. It might be possible to extend it to have a minimal interior dock for swallowing small python scripts using the glade ui files?

Actually it's not such a good idea as it might seem to be. The menu would need to run as daemon anyway, because executing a new process takes way too long according to my personal experience (it has to be slow per se). Also, GTK is a nice framework, but only for "standardized" look (GTK menus don't support any fancy stuff like swallowing or selecting default item etc. and also never will). GTK is also quite slow. Note, that changing this behavior of GTK would be more difficult than writing support for the same stuff for JWM.

dumblob commented Aug 1, 2015

It seems like ultimately it might be easier to create a standalone menu (like yours, possibly) that does this. It might be possible to extend it to have a minimal interior dock for swallowing small python scripts using the glade ui files?

Actually it's not such a good idea as it might seem to be. The menu would need to run as daemon anyway, because executing a new process takes way too long according to my personal experience (it has to be slow per se). Also, GTK is a nice framework, but only for "standardized" look (GTK menus don't support any fancy stuff like swallowing or selecting default item etc. and also never will). GTK is also quite slow. Note, that changing this behavior of GTK would be more difficult than writing support for the same stuff for JWM.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment