Created attachment 306656 [details] [review]
window: Remove old tiling code

We'll soon replace this with a better scheme

Created attachment 306657 [details] [review]
Add "size states" which save window size information

Created attachment 306658 [details] [review]
window: Add new tiling code

The new tiling code, instead of based around "tiling states", is instead
based around constrained edges. This allows us to have windows that have
three constrained edges, but keep one free-floating, e.g. a window tiled
to the left has the left, top, and bottom edges constrained, but the
right edge can be left resizable.

This system also is easily extended to support corner tiling. We also,
using the new "size state" system, also keep normal, tiled, and
maximized sizes independently, allowing the maximize button to bounce
between maximized and tiled states without reverting to normal in
between. Dragging from the top will always restore the normal state,
though.

Created attachment 306659 [details] [review]
frame: Don't allow resizing of edges that are constrained

(In reply to Jasper St. Pierre from comment #3)
> The new tiling code, instead of based around "tiling states", is instead
> based around constrained edges.

I'm all for making tiling more flexible, but there are cases where I expect it to at least appear as window state to the user - namely the multiple monitor behavior has seriously regressed with those patches:
If two windows are tiled side-by-side and moved to another monitor (via shortcuts, the overview, or by unplugging their monitor), I expect them to remain tiled side-by-side without gaps or overlap. I don't think that's a crazy expectation, or that it's impossible to add more flexibility without breaking what we have.

(In reply to Florian Müllner from comment #5)
> I'm all for making tiling more flexible, but there are cases where I expect
> it to at least appear as window state to the user - namely the multiple
> monitor behavior has seriously regressed with those patches:

Well, I did write them at a hackfest with a laptop with one monitor. I'm aware things like multimonitor broke, along with keybindings (this isn't a completed patchset, but to present the approach make sure I don't waste my time further). I'll look into multimonitor support. Do you have any other comments on the behavior or code?

Will I see any review here before I fix multimonitor behavior, or should I work on fixing that first?

I think you should probably go ahead and look at multimonitor behavior.

Jasper are you still working on this?

I'm still waiting for feedback that doesn't involve "improve multimonitor first". If I won't get such feedback, then I suppose I'm not working on it.

(In reply to Jasper St. Pierre from comment #10)
> I'm still waiting for feedback that doesn't involve "improve multimonitor
> first". If I won't get such feedback, then I suppose I'm not working on it.

I'm not entirely sure what kind of feedback you are hoping for to be honest. In its current form, it is unclear what behavior the patches try to implement (apart from adding quarter-tiling support, which looks fine to me), so I cannot comment on whether the redesigned tiling behavior makes sense to me, nor whether I think the code is a good way to implement it.

Fair enough. I developed this model with the Elementary designers since they were at the West Coast Hackfest, and they seemed interested and eager in the feature, and there were otherwise no GNOME designers there I could design the feature with.

The model we have developed together is that windows are attached to monitor edges instead of having explicit tiling zones. Dragging a window into a tiling zone constrains it to those edges, and leaves the remaining edge hanging, but with a default value.

For instance, if you right-tile a window, it constrains the top, bottom, and right edges of the window to the monitor edges, but leaves the left edge free-floating and free to resize.

If you quarter-tile a window, you get two edges free-floating, and such.

Besides this, we cleaned up the state management for the window, so the window now saves three states. If you have a window, tile it, and then maximize it, pressing the maximize button will move it back to tiled mode, and if you drag it from the top, it will remember the size it started with -- something that today's mutter gets wrong (try left-tiling a window, then pressing Super+Down -- it resizes to the minimum size possible).

We thought this model was flexible and worked in most scenarios we cared about.

(In reply to Jasper St. Pierre from comment #12)
> For instance, if you right-tile a window, it constrains the top, bottom, and
> right edges of the window to the monitor edges, but leaves the left edge
> free-floating and free to resize.

So resizing two side-by-side tiled windows is essentially:
- tile window left
- resize
- tile window left
- fiddle to get a matching size

That doesn't sound much more convenient than moving the windows to opposite corners and resizing them by grabbing the window corner. At the very least I'd expect two side-by-side windows to be resizable together, and ideally tiling a second window would take up the remaining monitor area (instead of half) when there's already a tiled window on the opposite edge. I think that's what we settled on in bug 645153 at least.


> Besides this, we cleaned up the state management for the window, so the
> window now saves three states. If you have a window, tile it, and then
> maximize it, pressing the maximize button will move it back to tiled mode

That sounds like the original tiling behavior we had, but we changed it in bug 677565.

We designed a model for resizing multiple windows at the same time, but I decided not to implement it so I could get feedback on this model first.

The model we designed was that when you have opposite edges or corners in close proximity that are visible, you can drag them together.

Well? Is that enough? Will I get any other feedback?

Now that the only way to resize a snapped window has been removed ( https://git.gnome.org/browse/mutter/commit/?id=91b7dedf368c6f70817849a324c0fd8ad6b8ccf3 ) I would certainly appreciate an alternative way of doing it.

Jasper, I can compile and test patches if that helps! I can dig out a second monitor, too.

The old way was equivalent to untiling the window from the side and then resizing it. It didn't actually keep the window tiled. You can continue to untile the window and then resize it -- that should still work.

I'm not blocked on testing. I'm blocked on review from another core team member.

Yes, that still works. It's a minor annoyance but I guess I'll get used to it.

Pushed.

(In reply to Florian Müllner from comment #5)
> I'm all for making tiling more flexible, but there are cases where I expect
> it to at least appear as window state to the user - namely the multiple
> monitor behavior has seriously regressed with those patches:
> If two windows are tiled side-by-side and moved to another monitor (via
> shortcuts, the overview, or by unplugging their monitor), I expect them to
> remain tiled side-by-side without gaps or overlap. I don't think that's a
> crazy expectation, or that it's impossible to add more flexibility without
> breaking what we have.

Looking at this, we already have code to adjust the window to the new monitor's size, so this should work mostly perfectly. I tested it and I was comfortable with the behavior on my machine. If it doesn't, please tell me your setup and I'll try to fix it up as best I can.

(In reply to Jasper St. Pierre from comment #19)
> Pushed.

Reverted. I want to have a chat with Lapo about the desired behavior first, but only came back from vacations on Thursday.

From trying it out a bit:
 - tiled windows are still resized one-by-one; without that it's hard to
   judge whether a whole new implementation is better than something like
   the patches in bug 645153
 - keyboard shortcuts are messed up - no way to get out of tiling, after
   maximizing/unmaximizing the normal window size is messed up, ...
 - no, windows are *not* resized on monitor/resolution changes: windows
   keep the width they had on the previous monitor, rather than preserving
   the occupied monitor area (half, third, ...)

As mentioned, I'll need to have a talk with Lapo; however the last point makes me think that constraints are a more logical approach to tiling than treating it as a move+resize operation. Tiling as a window state where the window covers a particular part of the monitor is a well-established definition by now (and doesn't exclude resizing at all), I don't think the same is true for the sticking to a corner/edge approach. There are definitively parts in the "old" tiling code that I dislike (mostly the confusing semantics of tile-mode being used for requested and actual mode), but I don't see how those cannot be changed without changing the definition of tiling altogether.

I'm livid.

Next time, after working on this code for nearly a year, not being contacted about it, and not answering my questions, or hearing any contact after repeated inquires, could you at the very least, *include me* on these discussions with Lapo instead of having them in private, without me?

You know my email address. You know my GChat. You know my IRC handle. Any of those would have sufficed.

I'm going to fix the remaining issues and re-push the new branch. I didn't catch the keyboard shortcuts one -- thanks for noticing. As for multimonitor, we do do rescaling. I tested it, and it works fine. If it's not working on your setup, we need to figure out why.

https://git.gnome.org/browse/mutter/tree/src/core/window.c#n3774

Oh, sorry, I misread your comment -- I thought you had already talked with lapo about desired behavior. My bad. So yeah, when you do talk with lapo, I'd prefer to be invited. I also won't re-push my branch to master until after we've had that discussion, though I will keep wip/tiling up-to-date.

--

When I previously talked to lapo, his desired approach was a model that was completely different from everyone else's I've heard. Basically, you have a grid of four corner slots, and when you resize all four slots.

So if you have windows stacked top-left A, maximized B, bottom-right C. Clicking-and-dragging A would also resize C. Seemed like a bizarre and unintuitive approach to me, which we all agreed on.

--

Also, while this first patch land isn't going to have multi-edge dragging, that could be fairly complicated to get right. But it does add corner-tiling, tiling resizing, and a few other features. I'd prefer for those to be judged independently of multi-edge, because they, alone, are a *massively* improved feature set, in my opinion. (I did wake up to three emails this morning from people saying they were happy I landed improved tiling features)

Elementary has said they might want something like ChromeOS's dragging, where hovering over two close window edges shows a grip which gives you the option. That would mean giving edge information and such to the compositor, and having it show UI elements which could start multi-edge drags. I have a plan (and some extremely hacky WIP code) to do multi-edge dragging, but it could take another month or so.

(In reply to Jasper St. Pierre from comment #21)
> Next time, after working on this code for nearly a year, not being contacted
> about it, and not answering my questions, or hearing any contact after
> repeated inquires, could you at the very least, *include me* on these
> discussions with Lapo instead of having them in private, without me?

Sorry, but the feedback you were asking for is hard, considering that it is largely about *unwritten* code (combined resizing, automatic size adjustments). Those were issues when I marked the patch as needs-work, and they are *still* issues with the patches you pushed. The very least is that those are fixed *before* landing them (that's what "needs-work" means really).

And no, I didn't have sneaky chats with Lapo - I *want* to discuss tiling with him, but we haven't done so yet. Let's include you in the discussion from the get-go then.


> I'm going to fix the remaining issues and re-push the new branch.

Please don't. I don't see any code that does automatic resizing on multimonitor(*), and adding code to handle it in monitor_changed() or similar would be conceptually odd when we don't change the handling of maximization at the same time. This starts to look very much like a disagreement about the definition of tiling, which should be resolved in discussion and *not* by a push-revert war.


(*) reproducer: left-tile one window, right-tile another one, move both to another monitor using <super><shift>left/right - they keep the width they had on the original monitor, which is not the correct behvior

I'm currently not at a place where I can test multimonitor support -- my laptop only has a DisplayPort connector and none of the monitors I have here have DisplayPort. I tested it at the office.

However, when we move windows across monitors, like we do on keyboard shortcut or on automatic hotplug, we do indeed use move_between_rectangles which should adjust the scale of both of them. This has been standard behavior, even with unmaximized or untiled windows (have a window be about 80% of the screen? It should resize to be about 80% of the screen once moved to a monitor half the size).

This feature worked fine for me when I tested it at the office. If it's not working for you, can you see if it happens for you in untiled cases as well, and look into why the code isn't working. We do do this size adjustment on monitor handling -- see move_to_monitor calling move_between_rectangles.

It could be that a feature I added or a small cleanup I made before I pushed it broke it for everyone, but all of the stuff I touched was in the toggle-tiled keybindings code, so I doubt that.

(In reply to Jasper St. Pierre from comment #22)
> When I previously talked to lapo, his desired approach was a model that was
> completely different from everyone else's I've heard. Basically, you have a
> grid of four corner slots, and when you resize all four slots.
> 
> So if you have windows stacked top-left A, maximized B, bottom-right C.
> Clicking-and-dragging A would also resize C. Seemed like a bizarre and
> unintuitive approach to me, which we all agreed on.

"We all" apparently didn't include me there, but yeah, I tend to agree there. I think the main difference is:
 (1) tiling is a window state that limits the window to x% of the monitor width
     (currently 50%, but having that user-adjustable still fits the concept (see
     again bug 645153), as does quarter-tiling)

 (2) tiling as a move-resize operation: a window is stuck to an edge/corner
     and resized to some part of the monitor area, after that the user may 
     resize it using the "free" edges/corners - I don't think making resizing
     *only* a user operation is right, and recomputing the area on monitor
     changes and applying the new size seems like an after-thought


> Also, while this first patch land isn't going to have multi-edge dragging,
> that could be fairly complicated to get right. 

Well, yes - that's why bug 645153 has a lengthy discussion. However I don't think resizing tiled windows makes sense without that.


> But it does add corner-tiling, tiling resizing, and a few other features. 
> I'd prefer for those to be judged independently of multi-edge, because they,
> alone, are a *massively* improved feature set, in my opinion.

What other features? From what I see, the patch set:
 (1) adds corner tiling
 (2) adds rudimentary resizing with the hard parts left out
 (3) regresses in several areas the old implementation got right

For (2) we already have a patch set that could be picked up that includes the hard parts, which leaves the question why (1) requires a completely different concept rather than extending the existing implementation?

(In reply to Jasper St. Pierre from comment #24)
> However, when we move windows across monitors, like we do on keyboard
> shortcut or on automatic hotplug, we do indeed use move_between_rectangles
> which should adjust the scale of both of them. This has been standard
> behavior, even with unmaximized or untiled windows (have a window be about
> 80% of the screen? It should resize to be about 80% of the screen once moved
> to a monitor half the size).

No, move_between_rects() updates the window position to reflect the relative position on the old monitor. It doesn't touch the size at all, which is the expected behavior for normal windows. The size of maximized windows is handled by a constraint, as did the old tiling code for tiled windows.

Looking forward to seeing this getting in.  I hope that discussions with Lapo come out with something that would see some good improvement in this area.  Let me know if there is something you'd like me to help with..

Have there been any updates here on the design side?

I am also interested.  We are close to UI freeze so I would be interested to seeing this in this upcoming cycle.

(In reply to Jasper St. Pierre from comment #28)
> Have there been any updates here on the design side?

No. For what it's worth, I don't consider tiling changes subject to any freezes except for hard code freeze, and there are still some UI changes pending on the shell side. Still, let's try to have the talk later this week.

The code is now on the wip/tiling-2 branch.

I've given it a try after todays discussion. My observations:

1) Keybindings feel incomplete without a way to go to the quarter tiling states via keyboard

2) The heuristics for maximizing almost screen-filling windows still work

3) There is no obvious way to tile to the top half of the screen, since dragging up is for maximizing

4) While the resizing of constrained windows works nicely in isolation, without the ability to resize tiled neighbors, it feels cumbersome. Maybe it would feel better if you could at least 'snap into the remaining space' (ie half-tile window 1, adjust its size, then half-tile window 2 to the other side and have it take up the remaining space.

5) Changing screen resolution with tiled windows leads to overlaps or gaps, which is not great


I think the following would be needed to make this feel natural:

- When windows are tiled next to each other (either left/right or neighboring quarters), the shared edge should not be unconstrained but resize both windows at the same time. Should probably use a different cursor to make that obvious (the ones we use on pane splitters). Maybe this is the "hard parts" that Florian alluded to in comment #25 ?

- Constraining shared edges like that should also take care of the move-between-monoitors and change-resolution situations. Extra wrinkle here: when the constraints can't be satisified in these cases, we need to give up tiling, while we should simply refuse to resize any further when the user is dragging the shared edge.

- We should add keybindings to move between the quarter and half-tiled states. Could just extend the current Super-arrow bindings to roam between all tiling states in some fashion.

(In reply to Matthias Clasen from comment #31)
> The code is now on the wip/tiling-2 branch.
> 
> I've given it a try after todays discussion. My observations:
> 
> 1) Keybindings feel incomplete without a way to go to the quarter tiling
> states via keyboard
<snip>

What's the use case for quarter tiling, when we already have trouble with some applications being able to tile to half of the screen (especially in hidpi), and there are at least 2 tiling terminals available for GNOME[1]?

Half-tiles with 2/3 1/3 splits would probably be more generally useful (it's what iOS and Windows allow in recent versions).

[1]: Terminix:
http://www.webupd8.org/2016/03/terminix-promising-new-tiling-terminal.html
Terminator:
http://gnometerminator.blogspot.fr/p/introduction.html

(In reply to Bastien Nocera from comment #32)
> What's the use case for quarter tiling, when we already have trouble with
> some applications being able to tile to half of the screen (especially in
> hidpi), and there are at least 2 tiling terminals available for GNOME[1]?
> 
> Half-tiles with 2/3 1/3 splits would probably be more generally useful (it's
> what iOS and Windows allow in recent versions).

Funny, I found this discussion after trying to find out how to split screen by other ratio than 50%.

It probably needs to be configurable, because I would not want to have 1/3-screen terminal to only have 70 columns. So either a way to specify width of the "left half" of the screen or implement multiple sizes to toggle through with super-right.

Thanks. :-)

(In reply to Jan Dvořák from comment #33)
> (In reply to Bastien Nocera from comment #32)
> > What's the use case for quarter tiling, when we already have trouble with
> > some applications being able to tile to half of the screen (especially in
> > hidpi), and there are at least 2 tiling terminals available for GNOME[1]?
> > 
> > Half-tiles with 2/3 1/3 splits would probably be more generally useful (it's
> > what iOS and Windows allow in recent versions).
> 
> Funny, I found this discussion after trying to find out how to split screen
> by other ratio than 50%.
> 
> It probably needs to be configurable, because I would not want to have
> 1/3-screen terminal to only have 70 columns.

No, because you'd use a tiling terminal emulator, where the constraints aren't the same as in managing multiple windows on the one screen.

(In reply to Bastien Nocera from comment #34)
> (In reply to Jan Dvořák from comment #33)
> > (In reply to Bastien Nocera from comment #32)
> > > What's the use case for quarter tiling, when we already have trouble with
> > > some applications being able to tile to half of the screen (especially in
> > > hidpi), and there are at least 2 tiling terminals available for GNOME[1]?
> > > 
> > > Half-tiles with 2/3 1/3 splits would probably be more generally useful (it's
> > > what iOS and Windows allow in recent versions).
> > 
> > Funny, I found this discussion after trying to find out how to split screen
> > by other ratio than 50%.
> > 
> > It probably needs to be configurable, because I would not want to have
> > 1/3-screen terminal to only have 70 columns.
> 
> No, because you'd use a tiling terminal emulator, where the constraints
> aren't the same as in managing multiple windows on the one screen.

I joined the gnome bug tracker just so I can give some input here.

As a student, I constantly reference many things, be it a website, a book, a pdf, an article, an assignment spec, etc. And also have many windows open, usually a terminal, a note taker (like cherrytree or zim), an editor for code, spreadsheets, graphing, anything really.

Plain vertical half tiling mostly works fine, but often I find the need to have at least 4 windows open at once and refer between them. Alt-Tabbing is a p-i-t-a, so is switching between virtual desktops. In this case, quarter tiling is my only option to maintain a decent workflow.

I used to use a tiling window manager like i3 or awesome (I even made an easy theme switcher for awesome using environment vars), but I got fed up with losing too many conveniences; things like not remembering the name of an app and needing to browse a menu to find it, where just clunky in a tiling wm. And I liked having the easy access to a calendar and notifications in gnome (important for managing my study).

My point of all this, is this;
*Not everyone is going to use quarter/adjustable tiling to run multiple terminals*
*There are many more use cases for quarter tiling than you think*

As an example; http://i.imgur.com/y0QZ8eD.png

> No, because you'd use a tiling terminal emulator, where the constraints
> aren't the same as in managing multiple windows on the one screen.

Tiling terminal application won't help me with browser/terminal or evince/terminal split I tend to use very frequently.

Hi everyone! Just noticed this bug report and also want to help as much as I can :)

I've tried to compile wip/tiling-2 by merging it to the master branch but I've got a compile error. Before I investigate more, just wanted to check if someone got it currently working?

> - We should add keybindings to move between the quarter and half-tiled states. Could just extend the current Super-arrow bindings to roam between all tiling states in some fashion.

When Cinnamon introduced quarter tiling it broke many key bindings for me. Please let the following bindings still work:

Floating window: Super + Up -> Maximize window (NOT tile top)
Tiled window: Super + Up -> Maximize window (NOT quarter tile)
Tiled window: Super + Down -> "Untile" window (NOT quarter tile)

I suggest these new keybindings for the new tiling modes:

Super + (two arrow keys at the same time) -> Quarter Tile
Maximized window: Super + Up -> Tile top
Floating window: Super + Down -> Tile bottom

> 3) There is no obvious way to tile to the top half of the screen, since dragging up is for maximizing

This could be fixed by adding a maximize button to every window and have dragging up tile to the top. IMHO this would be a lot more consistent and intuitive, but on the other hand maximizing is a far more important operation than top-tiling. So I think it might be okay if top-tiling is only accessible via the key bindings for power users.

Hi all. Is `wip/tiling-2` going to receive attention in any near future type of thing?

Hardcoded 50/50 is just plain unoptimal for a number of usability reasons. Simple baseline reasoning is that 50/50 ruins both windows, whereas other ratios tilt at least one of the windows towards a usability win. For example, in a "left-to-right" environment it makes more sense to do a 1/3 + 2/3 split or similar, so for a center-positioned user could gain a more enjoyable standard F attention pattern (most critical info is top-left) for the 2/3 window.

50/50 split feels like a person's two eyes are constantly dragged into separate directions.

> 50/50 split feels like a person's two eyes are constantly dragged into separate directions.

It would be nice if a dconf parameter would allow specifying tiling % ratios, so we could more accurately experiment and study the situation, what works what doesn't. Patching ratio calculation settings seems like a useful, low hanging fruit step to take, that could be achieved quicker than 2017+.

I'm on Gentoo, and would be able to easily user-patch my mutter installation, but client work makes it unlikely I can familiarize myself with mutter codebase to come up with a patch on my own for at least a few months from today.

IMO  Super + Up is not intuitive for Maximize.  

Especially since:
 1) Super + Down is not Minimize.
 2) Super + Left is already Tile Left.
 3) Super + Right is already Tile Right
 4) Super + Down would be Tile Bottom.
 5) Alt + F10 is already Maximize toggle.

If you need maximize with mouse you already have double click on the title.

Simple question: I don not want to sound disrespectful, but you are not serious, are you? Every major Linux IDE (e.g. Unity 7/8, KDE and EVEN XFCE) has a quarter tiling functionality. People do not care, whether you come up with the most intuitive and powerful implementation in the first release of tiling support. Please just include the code again and let people enjoy the taste of quarter tiling!

This comment may sound technically not thought through, but speaking as a technician myself, technicians mostly tend to solve non-existing problems; call it one of our habits ;) Just concentrate on the basic flow for now; include the other fancy stuff at a later point in time. Who knows what future might bring us...

Please stick to the following: There is a considerably large userbase that wants to enjoy the possibility of (even standard) quarter tiling in Gnome IDE. Just deliver; very soon! Thank you in advance!

(In reply to christian.ohrfandl from comment #41)
> Simple question: I don not want to sound disrespectful, but you are not
> serious, are you? Every major Linux IDE (e.g. Unity 7/8, KDE and EVEN XFCE)
> has a quarter tiling functionality. People do not care, whether you come up
> with the most intuitive and powerful implementation in the first release of
> tiling support. Please just include the code again and let people enjoy the
> taste of quarter tiling!

The implementation is incomplete and thus broken. We're not going to merge it.

You also confuse desktop environments (DE) and integrated development environments (IDE).

> This comment may sound technically not thought through, but speaking as a
> technician myself, technicians mostly tend to solve non-existing problems;
> call it one of our habits ;)

The bugs exist in that first pass implementation. And the mutter developers certainly know what habits "technicians" would have.

All in all, this is not a useful comment. Unless somebody fixes the corner-cases in the existing patch, this will need to be implemented another way.

Please don't post any more comments of that sort, they're not helping fix the problem.

(In reply to Bastien Nocera from comment #42)
> You also confuse desktop environments (DE) and integrated development
> environments (IDE).

Was a typo, of course I meant desktop environment (DE) and not IDE; why would you even think of an integrated development environment in that context? Wee bit fussy, ey?

> The bugs exist in that first pass implementation. And the mutter developers
> certainly know what habits "technicians" would have.

What are the current priorities of the mutter developers? Is this issue among them? The wip/tiling-2 branch did not receive much attention lately...

> All in all, this is not a useful comment.
As I pointed out in my post, I did not want to sound disrespectful. All I wanted to say is that the lacking of this feature is a major usability issue in Gnome Shell (or Mutter) and to be honest, as Gnome Shell is one of the major DEs on Linux, this circumstance ist quite a bit of a shame. Gnome Shell should pay attention to perform the forerunner role in innovative features like the mentioned one. Of course, this should include Mutter aswell.

If you find these kind of comments, directly comming from your userbase, "not very useful", you probably lost your connection to the userbase. Just think about that a little longer, before you start "classifying" the usefulness of comments.

> Unless somebody fixes the
> corner-cases in the existing patch, this will need to be implemented another
> way.
OK, now we're talking ;) As asked earlier: What are the current priorities of the mutter team? Are there any ressources left the tackle the CORRECT implementation of this feature. Could you (or Florian Müller?) assign this feature request to a dev that has the time to implement the upcoming time?

> Please don't post any more comments of that sort, they're not helping fix
> the problem.
I'll do my best, if you encourage mutter devs to start working on this feature again (maybe Japer St. Pierre?) ;) Generally speaking, this was sort of an outcry, having the intention to make this feature relevant again. I mean come on; this discussion started about 1.5 years ago...

Nevertheless, thank you for the quick reply!

Just so you know, I was the one who wanted to implement this and I got the OK from mutter developers.  Jasper was kind of enough to take over it as he felt that the solution was going require effort that would be beyond my experience.   Of which he was quite correct!

Do not construe the lack of progress as a denial that mutter developers don't want this feature, it just lower priority than other things that need to be worked on.  If you think this might be a fun project to work on, you should dive in.

I might look at this again, given what has been done so far and see it can go anywhere.  It will be a fun project to do, I reckon as I soon as figure out what needs to happen to get accepted.

Cassidy from elementary (and System76 now!) following back up on this. 

I've now also heard from the System76 engineers that we'd love to get first party quarter tiling (enabled by this concept of constrained edges) into Mutter and GNOME Shell. elementary also would still love to see this in Mutter for better tiling features in Gala.

Sri, what are the steps to move forward with this? I could see if there's engineering resources available from System76 and/or elementary to help nudge this along. :)

Hiya Cassidy :-)

It is already on the features list for next release - 3.26.  See https://wiki.gnome.org/ReleasePlanning/FeaturePlans

I believe in the discussion I had with everyone involved that we shouldn't have a problem with implementation once we worked out the design aspect.  If you're coming to GUADEC you're free to participate there since that is where the design aspect will be fleshed out with Lapo and also an opportunity for System76 engineers to help hack (or at least be familiar with the codebase) on mutter. 

Diversity of voice at GUADEC will always be welcome. :-)

For everyone involved in here: you can track some pre-quarter tiling progress in bug 645153, and also see the details of the implementation plan in [1].

As a general advice, please refrain from commenting if the commend does not add to the *technical* discussion. Not only it has the oposite effect (it scares potential new contributors) but also lower the chances to get someone actually working on it. This bug history is already too long.

[1] https://wiki.gnome.org/GeorgesNeto/MinutesOfFeaneron/Tiling

With respect,
Georges

Created attachment 359416 [details] [review]
window: Track edge constraints

GTK has the ability to handle client-decorated windows
in such a way that the behavior of these windows must
match the behavior of the current window manager.

In Mutter, windows can be tiled horizontally (and, in
the future, vertically as well), which comes with a few
requirements that the toolkit must supply. Tiled windows
have their borders' behavior changed depending on the
tiled position, and the toolkit must be aware of this
information in order to properly match the window manager
behavior.

In order to provide toolkits with more precise and general
data regarding resizable and constrained edges, this patch
makes MetaWindow track its own edge constraints.

This will later be used by the backends to send information
to the toolkit.

Created attachment 359417 [details] [review]
wayland: Send edge constraints

Following up the previous patch, this patch makes the
Wayland backend send the edge constraints through a
custom protocol extension internal to GTK.

As it mature, we can think of upstreaming the protocol
to Wayland itself.

Created attachment 359418 [details] [review]
x11: Add support for _GTK_EDGE_CONSTRAINTS atom

To keep feature parity with the Wayland backend, and
to improve the overall tiling experience with GTK apps,
add the _GTK_EDGE_CONSTRAINTS X11 atom and update it
when necessary.

Just for the record, those 3 patches above are meant to be applied on top of the ones in bug 645153.

Created attachment 360862 [details] [review]
window: Track edge constraints

Rebased on updated patches in bug 645153

Created attachment 360863 [details] [review]
wayland: Send edge constraints

Dto.

Created attachment 360864 [details] [review]
x11: Add support for _GTK_EDGE_CONSTRAINTS atom

Dto.

Created attachment 360865 [details] [review]
project: add **/tags.* to gitignore

Builds adds lots of them in the source tree.

Review of attachment 360862 [details] [review]:

::: src/core/window-private.h
@@ +218,3 @@
+   * 2 - bottom
+   * 3 - left */
+  MetaEdgeConstraint edge_constraints[4];

I suggest changing the order to left, right, top, bottom to match MetaSide, then use the enum values in the code:
edge_constraints[META_SIDE_TOP] = ...

Review of attachment 360863 [details] [review]:

::: src/wayland/protocol/gtk-shell.xml
@@ +1,3 @@
 <protocol name="gtk">
 
+  <interface name="gtk_shell1" version="2">

meta-wayland-versions.h still only claims support for version 1

Review of attachment 360864 [details] [review]:

LGTM (other than the previous suggestion of using "edge_constraints[META_SIDE_TOP]" etc.)

Review of attachment 360865 [details] [review]:

This was commited to master already.

Created attachment 360878 [details] [review]
wayland: Send edge constraints

Following up the previous patch, this patch makes the
Wayland backend send the edge constraints through a
custom protocol extension internal to GTK.

As it mature, we can think of upstreaming the protocol
to Wayland itself.

Review of attachment 360878 [details] [review]:

::: src/wayland/protocol/gtk-shell.xml
@@ +53,3 @@
       <entry name="tiled" value="1"/>
+
+      <entry name="tiled_top" value="2" since="2" />

FWIW, I'm not quite convinced by the protocol - it doesn't convey the full state, which limits its usefulness: "top+right+left+bottom" can mean any of:

  - tiled left (with a neighbor to the right)
  - tiled right (with a neighbor to the left)
  - tiled maximized

We used to have dedicated styling of tiled windows (before we switched decorations to use gtk drawing) where the top-edge corner was rounded and the top-center corner was not. It's a bit sad that with all the new state, we wouldn't be able to re-implement that if we wanted to ...

Anyway, this allows us to handle shadows correctly, and as an unstable protocol it's easy to improve at a later point if necessary, so let's go with it.

Leaving the ticket open for quarter tiling.

Attachment 360862 [details] pushed as a5f4ffa - window: Track edge constraints
Attachment 360864 [details] pushed as e198c84 - x11: Add support for _GTK_EDGE_CONSTRAINTS atom
Attachment 360878 [details] pushed as aea66dd - wayland: Send edge constraints

(In reply to Georges Basile Stavracas Neto from comment #62)
> Leaving the ticket open for quarter tiling.
> 
> Attachment 360862 [details] pushed as a5f4ffa - window: Track edge
> constraints
> Attachment 360864 [details] pushed as e198c84 - x11: Add support for
> _GTK_EDGE_CONSTRAINTS atom
> Attachment 360878 [details] pushed as aea66dd - wayland: Send edge
> constraints

Hi Georges - this issue has been raised which apparently has been triggered by the X11 _GTK_EDGE_CONSTRAINTS atom patch.  Thoughts?

https://bugzilla.gnome.org/show_bug.cgi?id=788666