Skip to content
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: keybindings to move windows between monitors #23

Closed
prosoitos opened this issue Mar 16, 2018 · 14 comments
Closed

Feature request: keybindings to move windows between monitors #23

prosoitos opened this issue Mar 16, 2018 · 14 comments

Comments

@prosoitos
Copy link

Thank you very much for mons. I use it daily.

There may already be something that I missed, or it might be hard to implement within mons, but it would be amazing if a keybinding could easily move windows between monitors. When I get into extended mode, all of my windows are thrown to the second monitor and I need to move some of them back to my primary monitor. For some of them, it is quite easy, for others, that I configured in full screen and without decoration, it is a little tedious. Unplugging the 2nd monitor, however briefly to move somewhere (my primary monitor is a laptop), and replugging it requires to do this exercise all over again.

Note that I also really like the feature request #21 and if it becomes implemented, I guess that being able to switch windows easily won't be as critical as I wouldn't have to redo it each time.

Thank you!!!

@Ventto
Copy link
Owner

Ventto commented Apr 10, 2018

Hello @prosoitos,
Thanks for your feedback.

It sounds like a system configuration. For instance, tiling window managers like i3wm manage their workspaces and layers placement regarding the monitors.

Please, could you specify your distribution ?

@prosoitos
Copy link
Author

prosoitos commented Apr 10, 2018

I am on Arch Linux (4.15.15-1-ARCH).
My desktop environment is lxde (with default window manager Openbox).

I did look into setting this in the openbox config but did not find any documentation on it. It might be totally possible and it could just be my ignorance though. It certainly would be nice to be able to set a default config, either on the openbox settings or as suggested by #21.

That said, while on non linux OS, I used softwares that allowed to quickly move a window between monitors; and on my current system, it is very easy to move windows between desktops. So I thought that maybe it was something implementable with mons. Even with a good default, it would still be convenient to be able to move windows very easily between the primary and secondary monitors.

@prosoitos
Copy link
Author

prosoitos commented Apr 10, 2018

Note that, once I am set, extended mode does what I would expect (e.g. in a presentation, etc.). My "problem" is only when getting started: running mons -e <side> throws all my open windows to the 2nd monitor.

As a side note, I am really thankful that the daemon mode with mons -a exists, but when I unplug the 2nd monitor, the windows which are thrown back to my primary monitor are thrown in crazy places. No big deal at all, but basically both plugging and unplugging the 2nd monitor (which I have to do often), necessitates moving windows around manually.

@Ventto
Copy link
Owner

Ventto commented Apr 17, 2018

I've well understood your need.
First, let's try to handle it manually.

but it would be amazing if a keybinding could easily move windows between monitors. When I get into extended mode, all of my windows are thrown to the second monitor and I need to move some of them back to my primary monitor.

Have you tried wmctrl ? It is for EWMH compliant window manager like openbox.

...the windows which are thrown back to my primary monitor are thrown in crazy places.

Please, could you give me a screenshot ?

@prosoitos
Copy link
Author

prosoitos commented Apr 17, 2018

Thank you so much @Ventto for your time! 🙂

I do have wmctrl installed (might have been the dependency of something I installed), but I haven't played with it. I will explore!

Screenshots:

My 2nd monitor (let's call it m2) is above my primary (laptop) monitor (m1). So I use mons -e top.

When I unplug m2, windows in full screen on m2 "land" nicely on m1 (in full screen) and windows which already were on m1 in full screen remain on m1 in full screen. So this works great. Windows which were on m2 not in full screen land a little low on m1 (see the upper terminal on the screenshot: it was centered on m2 but isn't on m1. I have to say that both my monitors have different shapes though and m2 is longer than m1. So, had I have 2 monitors with the same length/width ratios, it might work nicely). But what doesn't work well at all is windows not in full screen which were already on m1. These get thrown down so that only their very top remains visible (see lower terminal on screenshot). So they are thrown down "as if" they were on m2 while they already were on m1... The daemon which should leave them alone is acting on them.

Issues when unplugging monitor 2

Full screen windows:
All works well.

Non full screen window thrown from monitor 2 to monitor 1 (see upper terminal window)
Not perfect (window always lands too low on monitor 1, but could be because my monitor 2 is taller than my monitor 1.

Non full screen window already in monitor 1 (see lower terminal window)
Daemon should leave it alone (window is already on monitor 1), but it moves it down as if it was on monitor 2, resulting of the window being thrown super low on the screen.

image

And another example here

image

Issue when launching monitor 2

  • most of the time, all the windows are thrown from monitor 1 to monitor 2, so that I have to bring some back into monitor 1.

  • some time, one doesn't get all the way there and ends up like this:

Window after getting into extended mode (some times only)

image

@prosoitos
Copy link
Author

prosoitos commented Apr 17, 2018

Correction: I had in fact tried wmctrl before posting the issue (I tried so many things that I couldn't remember). Some options look like they could work, however the man page says "The window manager may ignore the request". And sure enough, each time I tried something that seemed like it could work, it did ignore the request.

@Ventto
Copy link
Owner

Ventto commented Apr 17, 2018

Thanks @prosoitos.
Forgive my laziness but could you please give a title to your screenshots ?

@prosoitos
Copy link
Author

It is hard to get the idea without reading the information. Screenshot picture titles only don't do it. But I tried to add some formatting to make it more clear and readable. (And sorry for writing so much).

Thanks.

@Ventto
Copy link
Owner

Ventto commented Apr 22, 2018

Thanks @prosoitos. I got it.

What about your DPI at boot with your native monitor ?
What about it after running mons as deamon, plug and unplug a monitor ?
That DPI value is still the same ?

  • How to get DPI value ?:
$ xdpyinfo | grep resolution
resolution:    96x96 dots per inch

Have you tried to run xrandr command lines manually ?

Same issue with another window manager ?

@Ventto
Copy link
Owner

Ventto commented May 5, 2018

Up ?

@prosoitos
Copy link
Author

My apologies for the slow response. I have been caught in other things and away from my 2nd monitor lately. I will get back to your questions very soon now. Thank you! and sorry about that.

@prosoitos
Copy link
Author

I think that I will abandon openbox for exwm, which will solve my problem. I will see how that works. Either way, I am abandoning trying to solve this. If I go back to using mons and openbox at some point, I will keep moving windows manually the tedious way.

@Ventto
Copy link
Owner

Ventto commented May 31, 2018

Fell free to come back.

@Ventto Ventto closed this as completed May 31, 2018
@Ventto Ventto reopened this May 31, 2018
@prosoitos
Copy link
Author

Thanks! I am very happy with exwm, so definitely settling on this. And it is easy to set xrandr directly with exwm.

@Ventto Ventto closed this as completed Jun 21, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants