Dynamic window opening direction

[bilboquet]

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 Feature 526 open new window position gnome45 #679
  and even solve Shortcut to open new window vertically #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]

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]

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]

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):

1. Press specific keyboard command to swap layout direction (let's say Super+Shift+return).
2. A small tooltip or some sort of visual indicator could display to help guide what could be typed.
3. 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]

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

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]

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]

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:

1. use a shortcut to set the mode
2. 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.

[jtaala]

Hey @bilboquet, I'm finding more and more instances of where this feature would come in handy.

I'm working on an an early implementation similar to FocusMode. Feel free to follow along in the PR #829.

Note, I've just added an icon (next to FocusMode icon) which currently cycles through the window open direction options when clicked. Still need to add keybind shortcuts.

Cheers.

[jtaala]

As this relates to #679 and #526 (@joeyh): does anyone use the start and end options?

I implemented them at the time since I thought "why not?" - but in practice I don't think they're very practical. Reason why I'm asking is that it would simplify things a lot if they were removed - e.g. having only left/right as the options.

Then we could have one shortcut keybind cycle through window opening directions that will switch between the two.

Alternatively, we could leave them and add two keybinds (cycle (forward)... and cycle (backward) but that might get pretty tedious if users change window opening direction often?

Thoughts?

[jtaala]

Although, I guess those options might be more useful given we will soon be able to switch quickly between them...?

[jtaala]

Another alternative is that could allow users to set (in advanced preferences) the modes that will be cycled through? By default we could just have left/right but if users want to add the others (or any combination) this would allow them to do so.

[bilboquet]

Hey @jtaala
I'm glad you find this "idea" useful :)
I'll be AFK for more than a week but I'll definitively look at your work when I'm back.
To answer your question, I personally don't use start and end options. (my workflow is a bit chaotic, I see the general workflow as a stack, and at some point I spawn some "micro stack" for an activity, hence the need for open right/left, then I come back to the main stack when the activity is done) (so in fact my workflow is more like a tree ^^)
Anyway, thanks a lot for your work

[jtaala]

Hey @jtaala I'm glad you find this "idea" useful :) I'll be AFK for more than a week but I'll definitively look at your work when I'm back. To answer your question, I personally don't use start and end options. (my workflow is a bit chaotic, I see the general workflow as a stack, and at some point I spawn some "micro stack" for an activity, hence the need for open right/left, then I come back to the main stack when the activity is done) (so in fact my workflow is more like a tree ^^) Anyway, thanks a lot for your work

No probs.

P.S. I kept those two other settings (start, end) and just made them selectable (or not) for use in dynamic switching.

See it in action here:

Screencast.from.2024-04-19.08-06-43.webm