dreamcat4 / skippy-xd

A full-screen Exposé-style standalone task switcher for X11.
GNU General Public License v2.0
100 stars 12 forks source link

Additional hotkeys #165

Open oredaze opened 1 year ago

oredaze commented 1 year ago

I see that the mouse supports closing windows, shading and iconify, but I don't see a way to do the same with the keyboard, for example q does close-ewmh. I don't see a way to make the mouse cancel skippy-xd like keysExitCancelOnPress does, for example with miwMouse3.

dreamcat4 commented 1 year ago

Ah interesting...

Well keybinds handling (in general, including mouse). Has been re-prioritized for later date now. In favor of fixing multi monitor support.

And so this won't be look at for a while. However if we leave this issue open. And it might get looked into at a more appropriate time. Generally speaking, skippy is listening here for x-events, so if the mouse click is in fact observed / observable. Then it might be possible as some low-cost improvement. Those code yet has to be looked at around some other keyboard handling matters (which are not related to this).

felixfung commented 1 year ago

@dreamcat4 you forgot you are not the only dev here :)

dreamcat4 commented 1 year ago

Ah sorry I misread this bug report. Indeed it's a matter of mouse. (which is not keyboard matters...)

What I can say naively:

In previous versions of skippy. We had it so that moving the mouse cursor outside of any highlighted clientwin zone then de-highlighted the last hovered item.

And then... (with no longer any preview selected). That the same miwMouse1 (=focus). Positive selection (or left click). Would indeed become the cancel operation. Because no preview is actually selected. So on a dynamic basis, that shared / re-used the same mouse button.

@felix can clearly answer better about the new behaviour:

It is indeed different (not necessarily better or worse). But just different:

That the last hovered item. It remains highlighted. Until the next clientwin zone becomes hovered over (becomes new focussed).

So selection is "sticky" and there is never any de-selection. Which is indeed better in certain respect(s). For example ignoring any gaps moving in between clientwins.

I don't really see much point weighting in here my opinion about mouse behaviors. If felix can keep his opinions away from my Keybindings matters! (but perhaps he cannot).

But i can apologize for mis-reading the issue here... after having other recent issues on the mind.

felixfung commented 1 year ago

I see that the mouse supports closing windows, shading and iconify, but I don't see a way to do the same with the keyboard, for example q does close-ewmh.

Good idea. Probably will be implemented in near future.

I don't see a way to make the mouse cancel skippy-xd like keysExitCancelOnPress does, for example with miwMouse3.

Nice catch. I have made a fix where mouse click on anywhere without window would lead to a cancelling action, equivalent to keysExitCancelOnPress. I will push that based on the decision of @dreamcat4.

felixfung commented 1 year ago

@oredaze I have forked the repo to https://github.com/felixfung/skippy-xd, with new changes to (among other bug fixes/features) clicking on non-window area to cancel selection, equivalent to keysExitCancelOnPress.