Comment 13 for bug 745159

The video looks nice. However, "grid" plugin is not "move" plugin: from a semi-advanced user perspective (that's what I, plainly, am), I just don't like having checkboxes to play with which crash my system (2 years standing): if it does never work, disable it in "release" ubuntu (i.e., assume always checked and hide in the user interface)... as comment #10 suggests.

However, from an user perspective, I thing the snapoff/snapback in "maximized" hasn't the same meaning as in "gridded" windows: For me, I'd like the grid plugin to be a fast way of changing size of a window without touching my mouse. So, when I try to uncheck the option it's because I just want that: I don't want any "maximized"-like interpretation, just change size and move around that smaller window. So, I think the design "does make sense".

A different thing is the behaviour shown in the "move" plugin video: the snapoff makes you avoid one step of "1st minimize, then move" a maximized or semi-maximized window. That's useful, too.

In summary, both designs can coexist and make sense; my ideal combined user interface would be:
1) Move, drag to an edge, maximise buttons: window gets maximised as expected (full, half left, horiz, etc.)... move it and you restore size.
2) Grid: change size of the window, no default "semi-maximised" interpretation. Move and it keeps the size set by the grid.

If the grid plugin UI as it stands now has the checkbox and it does not crash, then it's up to the user the interpretation of the grid window size changes. I prefer "2" (but cannot do it because of the bug); if others prefer "1", good: user flexibility wins. In fact, the most flexible interface would be selecting "snapoff fully maximised windows true/false", "snapoff semimaximised (left,right,top,bottom) windows true/false", "snapoff all gridded windows (i.e., the 9 combinations) true/false".

So, if it's easy to fix and I convinced you the design makes sense (for some of us at least), maybe you might think fixing it.