(In reply to comment #0)
> 1. drag to the side - half-tile outline appears
> 2. drag up or down - outline snaps to the quarter, if the window is small
> enough for that

Also, for keyboard shortcuts: if I press super+right then up without releasing super, that should quarter-tile to the top-right corner.

However, if I'm half-tiled to the right already, and then press super+up, it should just maximize, as it does now.

+1 . I'd rephrase - to tile to a quarter - drag to the corner (not side,then up or down)

A great idea for a feature I've long missed. If this is expose via keyboard shortcuts it gets us slightly closer to tiling window-manager like behaviour.

Currently I enable something similar using the popular shellscape extension.

The "Put Windows" extension makes it available through shortcuts , but there's no extension for directly dragging to the corner . *shellshape (google tipped me about the name) is as far as I've seen keyboard based and more complicated . IMO the best behavior is as Mathias Clasen explained - edges resize to half and corners resize to quarter (by dragging) .

*** Bug 750760 has been marked as a duplicate of this bug. ***

Florian, you had some WIP patches for this, right?

No

Hello,

I've been using Gnome3 for a while and really appreciate that I can do most of what I need without using the mouse!  I also like the basic tiling available today and use it very regularly.  I just wish I could tile to quarters of a screen AND Gnome would handle tiling with multiple monitors better.

(Yes I could use another window manager or possibly a Gnome plugin, but what I'm after is only one step ahead of what Gnome already does today)


Would it be possible to have behaviour similar to Windows 10's "snap view"?  I find it more intuitive than what is described above.


Here's a rough example where a window is moved around by *key presses* on a dual monitor system.  *The left monitor is currently active*.

1. Super + Left = tile Window to left half of current (left) monitor (same as Gnome 3 today)
2. Super + Up + Left = tile Window to the top left quarter of the left monitor
3. Super + Right = move and tile Window to right half of the left monitor
4. Super + Right again = move and tile Window to the left half of the *right* monitor (jump between monitors - Gnome doesn't do this today)
5. Super + Right again = move and tile Window to the right half of the right monitor (same as today)
6. Super + Up + Left = move and tile Window to the top left of the right monitor


In other words extend the current functionality by;
1. Allowing windows to be moved between monitors by using the keys only
2. Allow a triple-key combination to snap a window to a quarter of the current screen (which I would argue is both more intuitive and simpler to implement than Mathieu's suggestion)



Although I'm talking about using shortcut keys to move windows, I believe the same thing can work with snapping windows to regions.

* Top of monitor, maximise window in that monitor (like today)
* Left of monitor, tile to left 50% of that monitor (like today)
* Bottom left corner of monitor, tile to bottom left 25% of monitor


The only thing Gnome doesn't do today is allow snapping of a window to the region on the right of the left monitor in a multi-monitor setup.  I'd like to see that change, however the regions used "in between" monitors would need to be smaller than those on the "outsides" so users don't get stuck to them when normally dragging monitors around.

Perhaps in this situation the mouse might have to stop over the region between monitors - while dragging a window with the mouse.

Thank you!

> Allowing windows to be moved between monitors by using the keys only

Isn't that already possible using Super + Shift + Left/Right?

(In reply to Jan Niklas Hasse from comment #9)
> > Allowing windows to be moved between monitors by using the keys only
> 
> Isn't that already possible using Super + Shift + Left/Right?

Hi,

No this doesn't work not in Gnome 3.18 (Fedora 23).
It also hasn't been the case in the previous few Fedora releases.

I'll upgrade to Fedora 24 soon and try that too, but if it should do this behaviour it could be a bug which has gone unnoticed.

If it doesn't work, something is probably wrong with your keyboard shortcuts settings. That shortcut has been around for quite a while (definitively before 3.18).

It's quite possible that I mucked around with the keyboard shortcuts before Fedora 23, however when that version was released I did a fresh reinstall.

It most definitely does not work now.

I mean the arrow keys do move the windows to half the screen, but they do not move between monitors.

Ah sorry guys you are right.  I missed Jan's mention of the shift key.

I still stand by my original post.  Having to add a shift to switch between monitors is unintuitive.

I'm surprised to be saying this, but if you ever have the opportunity to use Windows 10 with dual monitors, please try it's simple "Super + Arrows" combinations.  They're very obvious key combinations and work well.

(In reply to ldn from comment #13)

> Having to add a shift to switch between
> monitors is unintuitive.
> 
> I'm surprised to be saying this, but if you ever have the opportunity to use
> Windows 10 with dual monitors, please try it's simple "Super + Arrows"
> combinations.  They're very obvious key combinations and work well.

+1 on this. Moving between either pretty much any tiling WM or Windows (at least 7+, not just 10) to GNOME on multimonitor I've found this frustrating and inaccessible. It's not well-documented, and I'd rather see the behavior change to make Super + Arrow consistently move across screens than document the inconsistent Super + Shift + Arrow solution.

I'm glad to at last find a way to actually move windows across monitors without the mouse, if not as cleanly, but not until scouring Bugzilla or mailing lists.

Specifically, Super + Shift + Left/Right Arrow is not mentioned here:
https://help.gnome.org/users/gnome-help/stable/keyboard-shortcuts-set.html.en
Nor here:
https://help.gnome.org/users/gnome-help/stable/keyboard-nav.html.en
Nor here:
https://wiki.gnome.org/Design/OS/KeyboardShortcuts

I thought I found it buried elsewhere on the help or wiki pages, but I can't find it again.

Looks like these bindings correspond to settings org.gnome.desktop.wm.keybindings.move-to-monitor-left and org.gnome.desktop.wm.keybindings.move-to-monitor-right.

(In reply to ldn from comment #13)
> I still stand by my original post.  Having to add a shift to switch between
> monitors is unintuitive.

So would using <super>up (the maximize shortcut) to move a window between monitors be intuitive? If not, what is different about half-maximized windows?

Some shortcuts change the window's state, some are move operations - so far we have agreed that a shortcut that is a bit of both doesn't make sense. You'll need to convince the designers from the opposite for us to consider this (and no, "hitting shift is hard" isn't a good argument, as you can change the shortcuts in keyboard settings if you don't like them, and "windows 10 does it" is a data point to consider, but not conclusive)

I've filed bug 768454 for the docs

(In reply to Florian Müllner from comment #15)
> So would using <super>up (the maximize shortcut) to move a window between
> monitors be intuitive? If not, what is different about half-maximized
> windows?

Maximizes takes the whole screen, it doesn't tile to the top-half, and in Windows, Super-Down on a restored/windowed window minimizes it, which I find a bit more intuitive/consistent than Super-H. So it's functionally different.
Further, multimonitor in vertical arrangement is much less common than horizontal. Even in that case, Super-Right/Left can proceed through all the monitors in logical order (as Windows does). Super-Shift-Arrow requires not only learning out a second chorded (and heretofore undocumented) shortcut, but one that would usually be redundant, if not slower. If I want to move a window to a tile (or window) somewhere on a different monitor with the Windows-style shortcut, I just hold Super and tap Arrow until it gets there. Right now in Gnome, I have to use two key shortcuts with and without shift to get it there, slightly slower and more awkward. To me it's unexpected that Super-Right on a right-tiled window would restore it on the same screen (to the left of its current position) rather than move it to the next screen on the right.

There's nothing wrong with the Shift+Super shortcut the way it is, but there's some loss of usability and intuitiveness from Super-Arrow only working to tile within one screen in multimonitor configuration.

> You'll need to convince the designers from the opposite for us to consider
> this (and no, "hitting shift is hard" isn't a good argument, as you can
> change the shortcuts in keyboard settings if you don't like them,

Respectfully, the ability to remap the shortcuts is not an argument either for less intuitive defaults (that most users will never change, and will expect to be consistent out of the box) or for the limitation of the move-to-monitor-left/move-to-monitor-right bindings, which can't be easily changed by rebinding.

That's just my opinion; if someone is acclimatized to the current behavior and shortcuts it's not going to be unintuitive, but since you asked this is something that's irked me for a while in Gnome. It's not a big deal once the documentation is made accessible.

I agree with ntk in Comment #17!


> You'll need to convince the designers from the opposite for us to consider
> this (and no, "hitting shift is hard" isn't a good argument, as you can
> change the shortcuts in keyboard settings if you don't like them, and
> "windows 10 does it" is a data point to consider, but not conclusive)

It's not about being too lazy to press an extra key, it's about how unintunitive that extra key is in the first place.  Until I went to the trouble of registering an account here and posting in this bug I had no idea that shift was required.


Also, in principle, I agree that just copying another operating system is generally a bad idea.  However in this case the way it is done in that operating system is beautifully logical and easy to use.  It requires no training, just to tell a user that they should experiment with Super + Arrow keys.



FWIW The other part of my first suggestion was about being able to "snap" windows to *one quarter* of the screen.  That is, a very limited tiling window manager.

There are currently Gnome shell extensions which offer this functionality but they tend to be less well tested, are often a bit complex and can be unintunitive to use.  I'd personally really like something elegant and intuitive to end up in Gnome by default because I'm not permitted to use Gnome shell extensions at work.

Thanks again!

I think, I'll stand with the developers and designers in this respect. I frequently use the vertical combination of displays and pushing Super-Right to throw a window to a display below (or should it be above?) would completely blow my mind. And the "just push the same hotkey until it fits right" reminds me of "just push PgDown until you find the right page" instead of jumping directly to a needed chapter in a document. I like the current way.

(In reply to Alexey Rusakov from comment #19)
> I
> frequently use the vertical combination of displays and pushing Super-Right
> to throw a window to a display below (or should it be above?) would
> completely blow my mind. 

I'm curious, how did you learn about the key combination in the first place?


I've used Gnome for years and I never discovered that shift was required!  Call me foolish, but I've been using the mouse to move windows between monitors because I assumed doing that with keys wasn't implemented.


Anyway, why couldn't the key combination work (almost) identically for monitors using a vertical layout as it would in a horizontal?

For example:
The first time pressing  Super + Up would maximise the window in the current monitor - changing that behaviour would be a step backwards.  The second time pressing Super + Up would move the window in to the upper monitor *in the size/shape it was before it was maximised*.

Yes you would have to press the up arrow twice while holding down Super, but is that really any harder than pressing Super + Shift + Up?  Avoiding the use of Shift is a lot easier for a new user to visualise and discover by experiment.



> And the "just push the same hotkey until it fits
> right" reminds me of "just push PgDown until you find the right page"
> instead of jumping directly to a needed chapter in a document. I like the
> current way.

The example I gave above was for a new user learning how it behaved.  I would not expect anybody who had used it before to have to "hunt" like you describe.  An experienced user would, in this example, hold Super and press UP, UP moving the window quicker than it took you to read this sentence.

As to how I've learnt - from this bug, no surprise here. The question about documenting this is already covered several comments above.

Super-Up to maximize then one more Up to move to another monitor (why restored, by the way?)? And what if I do Super-(Up, Up) then change my mind and do Super-Down - instead of Restoring it should throw the window to a display below - maximized again? Sorry, I don't get how this is intuitive.

(In reply to ntk from comment #17)
> Maximizes takes the whole screen, it doesn't tile to the top-half, and in
> Windows, Super-Down on a restored/windowed window minimizes it, which I find
> a bit more intuitive/consistent than Super-H. So it's functionally different.

I'm not disputing that maximizing and tiling are different - after all, we have different actions for them. Where I don't follow is that "resize window to the available work area" and "resize window to half the available work area" should imply "move window to a different monitor" in one case but not the other.


> Super-Shift-Arrow requires not only learning out a second chorded (and 
> heretofore undocumented) shortcut, but one that would usually be redundant,
> if not slower.

We have already established that the missing documentation is a bug. My apology for the oversight of updating the documentation when we added the new shortcut, but it's hardly an argument for changing an existing shortcut - the documentation wouldn't just magically mention that the shortcut does something else besides tiling the window, so we'd still have a documentation issue.


> If I want to move a window to a tile (or window) somewhere on a different 
> monitor with the Windows-style shortcut, I just hold Super and tap Arrow 
> until it gets there.

So what if you want to move a maximized or unconstrained window to a different monitor? Hit the shortcut for "maximize" or "restore" until it ends up on the monitor you want? What if I want to tile/maximize/restore a window on a different workspace rather than a different monitor - should we cycle between those as well? I'm sorry, but I don't see how "move a window to a different monitor" or "move a window to a different workspace" are *not* separate actions from maximizing/tiling/restoring a window.


> There's nothing wrong with the Shift+Super shortcut the way it is, but
> there's some loss of usability and intuitiveness from Super-Arrow only
> working to tile within one screen in multimonitor configuration.

You claim it would be more intuitive, but I don't see why this would be the case. To me it sounds like artificially combining separate operations into a single action, which doesn't sound intuitive at all to me.


> Respectfully, the ability to remap the shortcuts is not an argument either
> for less intuitive defaults

It's not an argument for "less intuitive defaults", it's a suggestion of a workaround if you really dislike the existing shortcuts for moving windows to a different monitor that much. I am disputing that combining resizing windows to half the work area and moving them to a different monitor is any more intuitive than combining restoring a window to its original size and moving it to a different workspace.


(In reply to ldn from comment #18)
> FWIW The other part of my first suggestion was about being able to "snap"
> windows to *one quarter* of the screen.  That is, a very limited tiling
> window manager.

That is what this bug was asking for originally, see comment #0. There are unfinished proof-of-concept patches for rewriting tiling which include quarter-tiling in bug 751857.

*** Bug 775436 has been marked as a duplicate of this bug. ***

Maybe there is some code that can be used from this extension that work really well ?

https://git.gnome.org/browse/gtk%2B/commit/?id=fb0a13b7f070a14312dafa1e4df6ba03cf33be01

(In reply to jeremy9856 from comment #24)
> Maybe there is some code that can be used from this extension that work
> really well ?
> 
> https://git.gnome.org/browse/gtk%2B/commit/
> ?id=fb0a13b7f070a14312dafa1e4df6ba03cf33be01

That's not an extension. Typo?

Oops ! Sorry, here it is :

https://extensions.gnome.org/extension/657/shelltile/

+1 The shelltile extension does exactly what the optimal behavior should be IMO. Even without migrating code it could just be added as a default extension (though integrating it would be nice)

The shelltile extension has some annoying regressions. For example it's too easy to tile a window by mistake using the mouse. Also you can't restore the size of a tiled window like you can now.

adding some see-alsos; these are near- if not total-duplicates of each other

*** Bug 792828 has been marked as a duplicate of this bug. ***

Hi everyone, I just got referred here from IRC by @garnacho.

I'm the developer of WinTile, an extension for GNOME that's been growing lately. It was built to help with the transition from Windows to GNOME by expanding the Super+Arrows to support quarter screen docking as requested in this bug ticket, but recently I got a request to see if I could contribute it to GNOME.

The source can be found here, and I'd be happy to expand/integrate it into the GNOME shell as part of this bug (or if a more familiar dev would like to integrate, that's fine, too): https://github.com/Fmstrat/wintile

I was the user requesting adding this directly into GNOME. I came across the extension when doing a short web search on GNOME tiling capabilities. Since this is a pretty basic and useful thing, I suggested to maybe integrate it directly into GNOME. This way probably maintenance, integration and a much larger base of benefiting users can be achieved. I guess there are also some other extensions aiming to provide better support for this, so there is some redundant code and effort that can hopefully be directed into a more efficient way.

GNOME is going to shut down bugzilla.gnome.org in favor of  gitlab.gnome.org.
As part of that, we are mass-closing older open tickets in bugzilla.gnome.org
which have not seen updates for a longer time (resources are unfortunately
quite limited so not every ticket can get handled).

If you can still reproduce the situation described in this ticket in a recent
and supported software version, then please follow
  https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines
and create a new ticket at
  https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/

Thank you for your understanding and your help.