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

Multimonitor keybinds #371

Merged
merged 4 commits into from Jan 15, 2018

Conversation

Projects
None yet
6 participants
@ozeidan
Contributor

ozeidan commented Dec 30, 2017

Hi,

I implemented proper keybinds for moving windows between monitors that work with tiled/maximized/fullscreen windows.

Please test it and sorry for the PR spam :)

Closes #320

@jhasse

This comment has been minimized.

Contributor

jhasse commented Jan 2, 2018

How can I assign those keybindings when running a local marco build via ./src/marco --replace?

@raveit65

raveit65 approved these changes Jan 2, 2018 edited

Seems to work fine, i just tested it with my notebook and a TV-Monitor.
I set up the for possible keybings and only 2 are working, which is good.
north+ south or west+east, depending on a vertical or horizontal 2 monitor setup.
On a system with 1 monitor you can setup the keys, but they doesn't have any function,....which is good.
And i saw no regressions in a quick test.

@lukefromdc

Built and started up fine, but I was unable to get a keybinding set in dconf-editor to actually work. I have very little experience with changing keybindings however, so no guarantee I was not hitting a keybinding used somewhere else

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Jan 3, 2018

@jhasse @lukefromdc you have to recompile the gschema: I usually do this by copying the file src/org.mate.marco.gschema.xml into /usr/share/glib-2.0/schemas and then running lib-compile-schemas /usr/share/glib-2.0/schemas. Then the options move-to-monitor-(n|e|s|w) should show up in dconf-editor at path /org/mate/marco/window-keybindings/.

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Jan 3, 2018

Also, I still found an issue with this implementation: When moving a firefox window that is either fullscreen or maximized to another monitor, it jumps right back. Can you guys reproduce that?

@lukefromdc

This comment has been minimized.

Member

lukefromdc commented Jan 3, 2018

I did recompile the schema, and the default disabled keybindings showed up in dconf-editor, but when I tried things like F12 or m they had no effect. I'm not an expert on this, my workflow is mostly mouse driven with few keybindings used and only the ctrl-alt-backspace changed back to its old binding to kill the X server.

EDIT: I was trying to use the monitor-west keybinding with a second monitor set to the right, nothing happened on trying to move a window from the left monitor (main) to the right monitor

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Jan 3, 2018

@lukefromdc west means right to left. Try placing the window on the right monitor and then pressing the key.

As a side note: currently I am using a function that already existed to determine the neighbour in the according direction. This works fairly well, though the current algorithm stops checking once it has found a monitor in the given direction. This means that if you have two monitors on a side of the current monitor, one the one which was registered first will always be chosen. Maybe I should improve this logic by checking which of those the screens is closer vertically (in the cases of move-to-monitor-(w|e)). What do you guys think?

@raveit65

This comment has been minimized.

Member

raveit65 commented Jan 3, 2018

Also, I still found an issue with this implementation: When moving a firefox window that is either fullscreen or maximized to another monitor, it jumps right back. Can you guys reproduce that?

Yes, it's reproducible here, but only with firefox. I tested this with chrome, vlc, mate-terminal and i don't see this issue.
firefox problem?

Maybe I should improve this logic by checking which of those the screens is closer vertically (in the cases of move-to-monitor-(w|e)). What do you guys think?

I don't think that i can test a 3 monitor setup. There is a report somewhere that it is impossible to setup 3 Monitors with mate-display-properties.
And i don't have 2 external monitors/tvs in one room ;-)
But go ahead if you can test it. I am sure there are some ppl who use 3 or more monitors.

Setting up the keybindings is working with both tools here, mate-keybinding-properties and dconf-editor.
Only keys with more than 2 levels are critical. An example for move-to-monitor-north with a vertical monitor setup.

crtl+Shift+Alt+KP_Up    --> works
crtl+Shift+Alt+u             --> works
crtl+Shift+Alt+8             --> don't work

The last one is impposible to setup with german keyboard layout and mate-keybinding-properties and move-to-monitor-north function doesn't work.
The result is always

crtl+Shift+Alt+[

With german layout you need altgr key to type [

(I hope this is understandable because of my poor english)

I think such weirdness is more a general problem than a problem with your PR.

@raveit65

This comment has been minimized.

Member

raveit65 commented Jan 10, 2018

@lukefromdc
Could you solve to setup some working keys?
@ozeidan
Beside from firefox, do you think this is ready to go?
We want to freeze MATE in a few days for releasing 1.20 end of this month, than only bugfixes are allowed to merge.

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Jan 10, 2018

The only other issue I found was, when you have a fullscreen window on a monitor and move a window to that monitor, the moved window gets placed behind the fullscreen window. I'll try to fix this today or tomorrow, otherwise I think it's ready to merge.

@raveit65

This comment has been minimized.

Member

raveit65 commented Jan 10, 2018

Ok, but isn't a fullscreen-window not always in the foreground?
I never saw another window on top of a fullscreen-window.
Or do i miss something?

@monsta

This comment has been minimized.

Member

monsta commented Jan 10, 2018

Looks like 15da872 might affect some existing features.

@monsta

This comment has been minimized.

Member

monsta commented Jan 10, 2018

When moving a firefox window that is either fullscreen or maximized to another monitor, it jumps right back.

I'm not surprised at all. We already have #28. Maybe Mozilla needs to learn to use GTK+?

@lukefromdc

This comment has been minimized.

Member

lukefromdc commented Jan 10, 2018

I have zero experience setting up custom keybindings, and also would need to be damned sure they got reverted. Not sure if I will have time for this one today.

@lukefromdc

This comment has been minimized.

Member

lukefromdc commented Jan 10, 2018

I have no issue with merging this

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Jan 12, 2018

@raveit65 when a window is fullscreen, you still can alt-tab to get another window in front of it. So I think if you move a window to that monitor it should be on top, just because it's really confusing otherwise.

@monsta I changed the parameter from FALSE to TRUE because I found some bug that this fixes. As I remember it this only changes the behavior of the move-to-X keybinds

@raveit65

This comment has been minimized.

Member

raveit65 commented Jan 12, 2018

when a window is fullscreen, you still can alt-tab to get another window in front of it. So I think if you move a window to that monitor it should be on top, just because it's really confusing otherwise.

Indeed, i didn't known that, btw. i never tried this ;-)
The result is that the panel, in my case top and bottom panel are on top of the fullsreen-window,
which looks very scary if you use a transparent panel.
I don't think i will use that for productivity :-)

But, i think that both arguments are legitim , for me the alt-tab function is a special case with a fullscreen window.
Any way, i don't care much about if this is an issue or not.

@monsta

This comment has been minimized.

Member

monsta commented Jan 12, 2018

What is that bug? Is it in this PR or in some existing feature?

That commit also changes some logic in constrain_maximization function

@raveit65

This comment has been minimized.

Member

raveit65 commented Jan 15, 2018

@ozeidan
Today is the last day for merging before feature freeze for 1.20.
Otherwise this new feature goes into next development cycle (1 year)
Personal i can live with the fullscreen-window issue for the moment.
If i merge the PR today you can fix it later.

@ozeidan

This comment has been minimized.

Contributor

ozeidan commented Jan 15, 2018

@raveit65 raveit65 merged commit e43cf41 into mate-desktop:master Jan 15, 2018

@raveit65

This comment has been minimized.

Member

raveit65 commented Jan 15, 2018

Thanks.

@csarmendariz

This comment has been minimized.

csarmendariz commented Aug 10, 2018

Hi,

Sorry because I'm pretty new so the question can be a bit silly or misplaced...
I would love to be able to move windows between monitors, I think is the only functionality I'm missing in marco.
However I cannot find how to activate the keybinds you guys are talking about here... not sure if I have an old version of marco without this functionality activated.
I'm running ubuntu mate 16.04, is there a way I could activate a keyboard shortcut to send window to the other monitor?
Thanks and sorry if this is not the place to ask.

@raveit65

This comment has been minimized.

Member

raveit65 commented Aug 10, 2018

You need Mate-1.20 (ubuntu.18.04)

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