Dynamic window opening direction

bilboquet commented 9 months ago

I use very often super+return mostly for terminal and Firefox windows (since I'm using PaperWM I don't use tabs anymore and spawn and close windows when needed).

Recently, an option to open the new window on the left was added #679. It's cool but too static for my workflow, most of the time opening to right is fine for me. What I was about to suggest is to add a shortcut, let's say super+shift+return to open the new windows on the left. But maybe this idea can be generalized a bit:

it could dynamically change the parameter introduce in #679 and even solve #725
or a set of shortcuts that temporaly modify the opening direction

In any case, a user feedback about the "open direction" could be given like what has been done to show the user the current focus mode (aka an icon in the top bar)

Many thanks

Lythenas commented 9 months ago

Yes I was actually thinking of something similar for #725. To have a new "mode" where you can switch between vertical and horizontal for new window placement. But it makes total sense to extend this to e.g. above, below, right and left.

bilboquet commented 9 months ago

Glad to hear that :)

As, most of the time, the default behavior of super+return is fine for me (and consistent with the loved philosophy of PaperWM) my preference it to have a temporary modification. Hence, to prevent a mess of shortcuts, maybe the solution is to append the direction to the current shortcut:

super+return+timeout_1s would produce the actual behavior
super+return+l would open the windows on the left
super+return+b would open the windows below the currently focused one
super+return+a would open the windows above the currently focused one

I think this solution is fine when opening a new window for the currently focused application. So it's worth adding it.

But it has a drawback, I'm also using Switcher and in this case that does not work. Maybe the previous idea can be generalized, let's say super+p (p for placement) is available and can be used to instruct PaperWM to temporarily modify the placement of the next window to open:

super+p+l memorize the next opening position is left,
super+p+b memorize the next opening position is below,
super+p+a memorize the next opening position is above,

then Switcher can be invoked transparently, the window is opened at the right place and the placement is restored.

distefam commented 9 months ago

to prevent a mess of shortcuts, maybe the solution is to append the direction to the current shortcut:

super+return+timeout_1s would produce the actual behavior

super+return+l would open the windows on the left

super+return+b would open the windows below the currently focused one

super+return+a would open the windows above the currently focused one

SublimeText does something similar with (for lack of a better term) two-phase keyboard shortcuts. For example, to toggle the sidebar: ctrl+k ctrl+b. Essentially, there is an entire second layer of shortcuts that are nested beneath a single one ctrl+k in this instance. I think this would be preferable to introducing a timeout, which could be frustrating under normal circumstances, or having a proliferation of keyboard shortcuts one needs to remember.

The Helix editor also does this (I think Kakoune did it first) with g. In vim, you need to remember that gg goes to the top while G goes to the bottom of a file. However, in Helix/Kakoune there is a small sub-window that appears when pressing g once, which allows you to "complete" the command with a second choice: gh = go to beginning of line, gl = to end of line, ge = to end of file, etc.

So, this could work in PaperWM like this (for example):

Press specific keyboard command to swap layout direction (let's say Super+Shift+return).
A small tooltip or some sort of visual indicator could display to help guide what could be typed.
One could press l to insert to the right, h to insert to the left, j to insert below, etc.

In this circumstance, Super+Return would produce the normal behavior while Super+Shift+Return would await user input.

bilboquet commented 9 months ago

@distefam Two-phase shortcuts are also perfectly fine to me, and probably more extendable to other ideas. In fact that was my first idea, but I thought it would be less intrusive to have multi-key shortcuts…

I'd be also very glad if we have a command window. Let's imagine that Shift+Super+p trigger something like:

(very dumb proof of concept in html page.html.zip ) That could be another way to improve things.

jtaala commented 9 months ago

Just a note here that what you're describing above (two-phase shortcuts) are (AFAIK) outside the scope of Gnome extensions, mostly because extensions are run by gnome-shell process, and not a separate process (e.g. GTK or otherwise) like applications.

Sounds cool, but I wouldn't be interested in implementing two-phase keybinds - the keybind / action system in PaperWM is already quite complex and there's complexities around key timing contexts, repeats, clash detection etc.

Anyways, if someone would like to implement a different keybinding approach we'd consider any PRs that could be provided.

The most that I would implement would be keybinds for setting the direction (e.g. left,right,above,below) and (maybe) a clickable icon, similar to the focus mode icon I implemented some time back.

Otherwise the additional complexities involved wouldn't be justified by this feature for me (which I don't use very much). However, as I mentioned, if someone wants to give a different approach (e.g. something more than keybind shortcuts and an icon) - I'd happily consider their PR.

Lythenas commented 9 months ago

I'm mostly of the same opinion as @jtaala

While I also use multi phase shortcuts in Emacs with evil mode (so vim keybindings). They are mostly useful because that means you don't need to press multiple keys at once (like in normal emacs). But since we always have to press e.g. Ctrl anyway, this benefit is kind of lost.

I also think that key chords don't have much benefit over adding another "mode" (like the window focus mode) and keybindings to switch it. Since they almost act the same. Except with a mode it would remember the last direction.

Another approach for keybindings for the future could be that we expose them externally in some way so the actions can be triggered from outside of PaperWM. E.g. through DBus. Then you can use an external program for e.g. the section menu that was mentioned.

bilboquet commented 9 months ago

I apologize if my last post was sounding like "you must do it this way". I don't know the internal complexity, so I'm just sharing my thought which is influenced by my personal workflow, with the hope it's shared and it can help.

I'm really grateful for all the work you're doing.

@jtaala

The most that I would implement would be keybinds for setting the direction (e.g. left,right,above,below)

For the user I am, that would be great.

@Lythenas

I also think that key chords don't have much benefit over adding another "mode" (like the window focus mode) and keybindings to switch it. Since they almost act the same. Except with a mode it would remember the last direction.

At first thought, as most of the time the default behavior is fine, the fact that modes are not transient sounds like a drawback. But thinking twice, if I have to:

use a shortcut to set the mode
use a shortcut to do an action That sounds a bit like two-phases shortcut. So the user I'am can't complain and will be happy. :)

Another approach for keybindings for the future could be that we expose them externally in some way so the actions can be triggered from outside of PaperWM. E.g. through DBus. Then you can use an external program for e.g. the section menu that was mentioned.

That would be a cool thing.

Thanks a lot.