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

[feature request] Assign scratchpad to monitor #3162

Open
k1sul1 opened this Issue Mar 7, 2018 · 7 comments

Comments

Projects
None yet
5 participants
@k1sul1

k1sul1 commented Mar 7, 2018

Reposting from Airblader/i3#198 (comment)


I've been using i3(-gaps) for a little over 6 months now, and the one thing that's bugging me is that the scratchpad follows my cursor. I've put a terminal emulator on it, and I show & hide it with a hotkey. It doesn't follow the cursor immediately, but if the scratchpad is open on my primary monitor, and I move my mouse to the secondary and then try to hide it with the hotkey, it will instead pop to my secondary monitor.

bindsym $mod+minus scratchpad show

That is the hotkey combination I'm using.

If my monitors were the same resolution, the scratchpad following wouldn't be an issue, but the terminal is unreadable on my laptop monitor when I'm using it on the primary monitor. I've tried searching the documentation but I haven't found anything on the subject.

Something like this is what I'd want to do. But pretty much anything that will achieve what I want will do.

workspace 1 output $external_monitor
workspace 2 output $external_monitor
workspace 3 output $external_monitor

scratchpad output $external_monitor

workspace 11 output $laptop_monitor
workspace 12 output $laptop_monitor
workspace 13 output $laptop_monitor

Output of i3 --moreversion 2>&- || i3 --version:

Binary i3 version: 4.14.1 (2017-09-24) © 2009 Michael Stapelberg and contributors
Running i3 version: 4.14.1 (2017-09-24) (pid 959) abort…)
Loaded i3 config: /home/k1sul1/.config/i3/config (Last modified: Wed 07 Mar 2018 12:49:30 PM EET, 144 seconds ago)

The i3 binary you just called: /usr/bin/i3
The i3 binary you are running: i3

@i3bot i3bot added the enhancement label Mar 7, 2018

@Airblader

This comment has been minimized.

Member

Airblader commented Mar 7, 2018

I think adding a flag like scratchpad show --focused-workspace (we can talk about the name of course) to conditionally skip this would be fine.

@Airblader

This comment has been minimized.

Member

Airblader commented Mar 7, 2018

Sorry, I should elaborate. I don't like the proposal here (and don't think it makes much sense*), so my suggestion is a different one. Would that work for you as well? From my understanding it should.

*) The scratchpad is a workspace which lives on no output. The behavior in question is caused by the logic of showing a scratchpad window. "Assigning the scratchpad to an output" thus seems weird and would logically involve other effects, I think, which may not be wanted.

@k1sul1

This comment has been minimized.

k1sul1 commented Mar 7, 2018

Yeah, I don't really care how it's done, but I'd just like to have the scratchpad stay put.

@Airblader

This comment has been minimized.

Member

Airblader commented Mar 7, 2018

Alright, let's add a flag then. PRs welcome, should be pretty trivial to implement.

@orestisf1993

This comment has been minimized.

Member

orestisf1993 commented Mar 13, 2018

I don't really understand the flag proposal. Isn't --focused-workspace the current behaviour?

@Airblader

This comment has been minimized.

Member

Airblader commented Mar 17, 2018

If you follow the link in the beginning of this issue, you'll find the part of the code causing the behavior this issue is about. It'd basically be a flag to skip that piece of code.

leoagomes added a commit to leoagomes/i3 that referenced this issue Jul 6, 2018

Proposal for issue i3#3162.
Added 'scratchpad show [on] output <name>' command.
@leoagomes

This comment has been minimized.

leoagomes commented Jul 6, 2018

I stumbled upon this a couple of days ago and as I tried to understand the issue, I noticed that perhaps the proposed solution doesn't solve OP's problem and does not add much functionality as well. It seems to me the original idea behind "assigning" the scratchpad to an output would be to have the scratchpad always be displayed on a given output: running scratchpad show (from any workspace/output) would bring up a scratchpad window to the active workspace on the desired output (and focus it); running the command again (from any workspace) with a scratchpad window visible on the assigned output* would hide the scratchpad.

(* = more on that later)

The proposed behavior (and somewhat associated pull request) just add an option to prevent a scratchpad window on a workspace that's not the currently focused one from being moved to the current workspace when scratchpad show is invoked. I don't believe this behavior would satisfy the original needs because the user appears to want the scratchpad to be hidden when scratchpad show is invoked from a workspace different than the one on the output rather than having another window from the scratchpad open up on the current workspace.

I agree that it doesn't make much sense to assign the scratchpad (workspace) to an input, so I propose a variant of scratchpad show is added: scratchpad show [--hide-if-visible] [on] output <name>. This would behave similarly to how scratchpad show behaves: (i) running it while focusing a scratchpad window on the target output (<name>) hides the window; running it without focusing a scratchpad window brings up (on the target output) either (ii) an unfocused scratchpad window on the target output's active workspace or (in case there aren't any) (iii) an unfocused scratchpad window on any of the workspaces in the target output or (iv) an unfocused scratchpad window on any (non-internal) workspace or (v) the window highest on the scratchpad workspace focus stack. This would make it so running scratchpad show on output current results (I believe) in the same behavior as running scratchpad show, but a user could bind a key to show their scratchpad on a specific monitor.

This wouldn't still work 100% for OP, because having the scratchpad terminal window open on monitor A, then focusing B and running scratchpad show on output A would bring the terminal back to focus instead of hiding it. The idea behind --hide-if-visible is that it will not only hide the scratchpad window if it is focused (behavior i) but also hide the scratchpad window in the active workspace of the target output. This way, in OP's scenario, pressing $mod+$minus with the terminal hidden would bring it to the front of the target output, pressing it again from any other output would hide it and pressing it yet again would reveal the window again, which seems to me as a reasonable experience.

I tried to implement (to the best of my ability, as this is my first attempt at contributing to the project) this feature, and it lives in PR #3320. There are still some problems with it, but I'd like to know what you think of the feature and in case you guys think it's valid, please check the code and tell me if there's anything I could improve on it (which I believe there'll be).

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