Window Management, Keyboard shortcut - The grid keybindings are behaving inconsistently

I'm seeing the same problem as Carlos, but in addition the top-right position doesn't work at all. Instead it behaves just like center-top. So my Ctr-Alt-KP8 and Ctr-Alt-KP9 buttons do the exact same thing.

Status changed to 'Confirmed' because the bug affects multiple users.

I've found out that reverting the package "compiz-plugins-main-default" version 0.9.6-0ubuntu4 to version 0.9.6-0ubuntu2 solves this problem, as well as the incorrect Ctrl-Alt-KP_9 behaviour.

Settings to High, it's a SRU regression

Status changed to 'Confirmed' because the bug affects multiple users.

In addition, if you push Ctr-Alt-KP9 to adjust a windows to the top right corner and after you change to another viewport using "expo pluguin" then the windows previously adjusted is showed in the 'new' viewport. In fact, the window is showed there but it is not there, since you canot access to it. The only way to access to it is changing again with the "expo plugin" to the original viewport.

The same happens with Ctr-Alt-KP7, Ctr-Alt-KP1 and Ctr-Alt-KP3.

I installed the ppa https://launchpad.net/~lbrulet-8/+archive/ppa as described on bug #876591 but this does not solve the issue reported on the bug about the missing cycling feature on Ctr-Alt-KP4 and Ctr-Alt-KP6 .

Is there a way to unmark this bug as a duplicate? Bug bug #876591 is related, but not exactly the same bug described here. As described above, the patch posted there does not fix the issue.

Sam mentioned that the behaviour there is not a bug, the side placements are not supposed to split in half every time there are used, that requires design input on the wanted behaviour

Oh, bumb, I loved that behavior. It was how the Grid plugin has always worked. It is specially useful with widescreen monitors. I normally use 1/3 of the screen for a terminal and the other 2/3 for a browser, ide, etc.

I guess what remains is to make the other movements consistent. Move Top/Bottom-Left/Right do split in half every time they are used.

I thought it was a bug since the behavior I described was available previous to the lasted update.

Thanks.

I find it hard to accept that the lack of cycling behavior for the left and right window placements could be a "feature". It worked in natty and still seems to work in oneiric for the top, bottom and corner placements.

I think this bug remains valid. I don't see why it should require design input.

Mal

Agreed, it's very convenient to be able to split the screen in, saiy, one third for one window and two thirds for another, or 1/4 and 3/4, etc.

Would be nice to see design team involved in this bug though I believe this behavior would take a few hours of careful thinking.

Does anyone have a workaround for this? Is there perhaps a different version of the grid plugin we can install? This feature is *extremely* useful for widescreen monitors.

Thanks John.

We know that some users liked the old way better but we are aiming for consistency and to avoid confusion there.

It doesn't prevent us to work on solving the "it should be easy to make dialogs take 25% of the screen" scenario in a way which doesn't abuse the grid placement combos (could be to use another modifier than ctrl-alt for example for those), could somebody open a new bug to request that features to be included in some way?

In my opinion the best solutions is giving to both sides. For ease of usability, by *default* the behavior of the grid plugin should use only half of the screen. However, this can reverted to the old behavior (1/2, 1/3, 1/4) using the grid plugin configuration panel via ccsm. New users get a less confusing experience, and more experience users can still setup their systems for maximum productivity.

AGREED! Please!

Thanks

I fully agree with #16, I think the old behavior makes the grid plugin *very* useful when arranging several windows on the same workspace. Just making everything occupy half the screen isn't as useful. I like to get the "Ubuntu really is much more useful than Windows 7" feeling.

For example, maybe I want Firefox to occupy 75% of the screen (so I can use the Treestyle tab addon to put my tabs on the left side of the window and still see the web page I'm on), and then keep a text editor on the left side. With the old behavior, this just required a couple of ctrl+alt+6 and ctrl+alt+4 to get it *just right*, whereas with the new behavior I have to drag stuff around with the mouse and probably won't get it *just right*. I like the old behavior. Why not have an option to activate it in CCSM? Both easy for newcomers, and easy to activate for people that want it.

One vote more for #16. I really think the old behaviour should be available by some way.

I was a new user to unity/compiz when i upgraded to 11.04 (from my very first linux experience on 10.10). And it was this feature that i found so compelling to stick with Ubuntu - it's now installed on four machines which had MS OSs previously. There's nothing confusing about it - its just great for gui productivity. No reason to dumb-down it's functionality by default. Until the feature is 're-introduced' are there any work arounds worth trying for those like i who struggle without it? Cheers all -K

I still vote we have multiple window sizes available when repeat pressing the same number key as it does everybody else as well. Please please keep this feature.

Is there going to be a way to restore old behaviour (i.e. more windows sizes available)? Grid plugin would be much more useful to me then.

I don't get either why the cycling works for ctrl-alt-5, but not for ctrl-alt-4 and ctrl-alt-6, which are much more useful.

Any plan to restore the behaviour by precise release? it's still like this in precise beta.

Agreed, also don't get why? Please restore, and PLEASE PLEASE do NOT take away the ability to do so with 1,2,3,5,7,8 & 9. I can't stress enough how usefull this is!! I use it everyday all day.

I'm chiming in too as someone who extremely highly values the original behavior (repeated presses resize the window repeatedly for all numpad keys).

I'm a software engineer who switched over to Ubuntu on 11.04. My work process immediately became more productive due to the combination of the workspace/desktop switcher, the spinning wheel type alt-tab window switcher and this grid plug-in.

I saved immense amounts of time placing each little debug/project/etc. window from Eclipse in a different position on each of my two widescreen monitors because of this plug-in.

To be candid, this is the deal breaker for me regarding sticking with Ubuntu. If I can't get this functionality, Ubuntu as a solution doesn't compete well with my alternatives.

Hell, I contemplated quitting my job to contribute to Compiz development. I don't know how I'd make that work financially. Oops, off-topic.

I agree with comment #16, I'd like to see the old behavior an option.

Ok, new keybindings done as per design request. However, note that multiple press on “place window” is currently continuing to resize the window, this need to be fixed in compiz in a separate bug, preferably, I guess.

Status changed to 'Confirmed' because the bug affects multiple users.

This bug was fixed in the package compiz - 1:0.9.7.0~bzr2995-0ubuntu5

---------------
compiz (1:0.9.7.0~bzr2995-0ubuntu5) precise; urgency=low

  * Change some keybindings as per design (LP: #878820, #891757, #751050)
    debian/patches/ubuntu-config.patch:
    - Show desktop is now Super + d
    - Super + Up maximize the window
    - Super + Down restore the window
    - Super + W initiate scale for all windows on current ws
    - Control + Alt + NumPad 5 is used to switch/restore maximize state
    - Control + Alt + NumPad 0 is used to minimize current window
    - Ensure we don't have any conficting keys anymore (LP: #922354)
  * 01_ctrl_alt_*tea*.patch:
    - Merged into ubuntu-config.patch, no reason to keep it separated
  * debian/compiz-gnome.gconf-defaults, debian/rules, debian/unity.ini:
    - Set the new plugin order with the incoming unity change as the default
 -- Didier Roche <email address hidden> Wed, 22 Feb 2012 13:44:25 +0100

This bug was fixed in the package compiz-plugins-main - 1:0.9.7.0~bzr19-0ubuntu3

---------------
compiz-plugins-main (1:0.9.7.0~bzr19-0ubuntu3) precise; urgency=low

  * apply design changes for the keybindings (LP: #878820, #891757, #751050),
    debian/patches/ubuntu_config.patch:
    - Control + Alt + KP_5: don't center, used for toggling maximize state
      by core
    - Remove Control + Alt + KP_0 to not maximize, (used to minimize in core)
    - Super + Left, Right key to semi maximize and stack on left or right
    - Remove zoom in/out/box (like in oneiric and before). Those should be
      enabled in g-c-c with the a11y tools.
 -- Didier Roche <email address hidden> Wed, 22 Feb 2012 15:04:30 +0100

Is there going to be some way to enable second pressess to do something? If not, another useful feature gone away. Anyway, I do not undestand it - this is a keyboard shortcut, that is not something the ordinary user uses much, do they? (you are doing user testing - I wonder how many of the tested "ordinary users" use shortcuts).

After updating this feature is now completely broken. Pressing ctl-alt-4 or 6 does nothing. If you have an open terminal it actually types 4 and 6 on the screen.

I don't understand. Every single comment in this bug says they prefer the old way of being able to place the window anywhere on the screen and then being able to repeat press that key and cycle through several different sizes, including half screen.

These are the kinds of features that users and most importantly the power users love and it's features like this that compels me to use ubuntu and recommend to everyone else. I literally use it everyday repeatedly. It has become part of my workflow and it's one of the main features which makes me MORE productive on linux than on any other OS. None of them have this feature which gives Unity an edge. please don't alienate more power users!

This feature worked fine in the past and all of us have grown used to it and depend on it. Please figure it out and fix it.

But like I said, right now it does nothing. THANK GOODNESS ctrl-alt 1/2/3/5/7/8/9 still works.

Le ven. 24 févr. 2012 07:02:00 CET, psypher a écrit :
> After updating this feature is now completely broken. Pressing ctl-alt-4
> or 6 does nothing. If you have an open terminal it actually types 4 and
> 6 on the screen.
>
> I don't understand. Every single comment in this bug says they prefer
> the old way of being able to place the window anywhere on the screen and
> then being able to repeat press that key and cycle through several
> different sizes, including half screen.
>
> These are the kinds of features that users and most importantly the
> power users love and it's features like this that compels me to use
> ubuntu and recommend to everyone else. I literally use it everyday
> repeatedly. It has become part of my workflow and it's one of the main
> features which makes me MORE productive on linux than on any other OS.
> None of them have this feature which gives Unity an edge. please don't
> alienate more power users!
>
> This feature worked fine in the past and all of us have grown used to it
> and depend on it. Please figure it out and fix it.
>
> But like I said, right now it does nothing. THANK GOODNESS ctrl-alt
> 1/2/3/5/7/8/9 still works.
>

I started a discussion on unity-design mailing list (require joining
the unity-design launchpad team), but no answer yet.

There are keyboard changes on the way, you might be able to place
windows left/right with super+→ and super+← but it's still the broken
version, we need to raise this issue with design, or the same behaviour
for 1, 2, 3, 5, 7, 8, 9 *will* be broken for Precise+1

For anyone that finds this change as annoying as I do, I have compiled a version of grid from the upstream git sources in natty. I don't know how / have time to debify this but if anyone else wishes to please be my guest;

http://quicksilver.umbralservices.com/eric/fixed_grid_oneiric.tar.bz2

Has there been any progress with this issue. ctrl alt 4 and 6 still does nothing, only way to set an app to half screen is to drag it to the left or right.

Le ven. 16 mars 2012 10:06:52 CET, psypher a écrit :
> Has there been any progress with this issue. ctrl alt 4 and 6 still does
> nothing, only way to set an app to half screen is to drag it to the left
> or right.
>

the currently configured way to put a window half left or half right is
super+left or super+right, however you can change that in CCSM (i
changed back to ctrl-alt-4 ctrl-alt-6 until there is a coherent way to
manage all the stuff without numpad), look at the binding part of the
grid plugin.

still no cycling, howether, i think that's gone forever :/

the currently configured way to put a window half left or half right is super+left or super+right, however you can change that in CCSM (i changed back to ctrl-alt-4 ctrl-alt-6 until there is a coherent way to manage all the stuff without numpad), look at the binding part of the grid plugin.

still no cycling, howether, i think that's gone forever :(

Thanks I have fixed it.

HIGHLY disappointing that despite not ONE person here saying they are happy losing that functionality yet still an extremely useful feature which worked fine in the past is not working anymore.

I don't get the logic...

If (as seems likely) this won't be fixed for 12.04, I think it is important that the keybindings used in 11.10 continue to work.

For example, whilst I support the addition of Super+Left and Super+Right for people without a numberpad, it is important that Ctrl+Alt+Numpad4 and Ctrl+Alt+Numpad6 continue to work.

It doesn't make sense to ask people to relearn keyboard shortcuts for the 12.04 release, especially if things are going to change again in a future release.

Hi Eric,

I'd really appreciate if you could explain what exactly to do with
"fixed_grid_oneiric.tar.bz2" or maybe point to similar resource as such.
For those like myself who dearly miss this functionality but lack the
expertise to implment your fix. I suspect we may need to do this all over
again come 12.04.

With thanks in advance,

Karl

On Sat, Feb 25, 2012 at 11:06, Eric Bennett <email address hidden> wrote:

> For anyone that finds this change as annoying as I do, I have compiled a
> version of grid from the upstream git sources in natty. I don't know how
> / have time to debify this but if anyone else wishes to please be my
> guest;
>
> http://quicksilver.umbralservices.com/eric/fixed_grid_oneiric.tar.bz2
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/878820
>
> Title:
> Window Management, Keyboard shortcut - The grid keybindings are
> behaving inconsistently
>
> Status in Ayatana Design:
> Fix Committed
> Status in Compiz Main Plugins:
> Invalid
> Status in “compiz” package in Ubuntu:
> Fix Released
> Status in “compiz-plugins-main” package in Ubuntu:
> Fix Released
> Status in “compiz” source package in Oneiric:
> Won't Fix
> Status in “compiz-plugins-main” source package in Oneiric:
> Confirmed
>
> Bug description:
> When placing windows on left or right (ctrl+alt+4, ctrl+alt+6), the
> windows do not cycle through different sizes, occupying only half of
> the screen. The rest of placing locations works perfectly.
>
> The problem was initially reported in bug #862260, and supposedly
> fixed. I am using compiz-plugins-main and compiz-plugins-main-default
> version 1:0.9.6-0ubuntu4, and the problem persists.
>
> ------------------------------------------------------------
>
> At the moment we are in a halfway house with some of the absolute
> positioning shortcuts working and some of the variable positioning
> shortcuts working, and we need to take a decision as to which path to
> follow. The absolute positioning shortcuts have the benefit of
> greater simplicity and less scope for confusion so this is the path I
> propose we should follow. When using absolute positioning users to
> not need to be aware of the current window state before pressing the
> key combo, which makes the operation quicker and less prone to
> unwanted results.
>
> Desired Resolution - the default behaviour should be:
>
> Ctrl-Alt-Numpad 7 - Place window in top left corner of screen.
> Pressing a second time does nothing.
>
> Ctrl-Alt-Numpad 8 - Place window in top half of screen. Pressing a
> second time does nothing.
>
> Ctrl-Alt-Numpad 9 - Place window in top right corner of screen.
> Pressing a second time does nothing.
>
> Ctrl-Alt-Numpad 4 - Place window on the left side of the screen in
> *semi-maximised* state (it is important that the window is actually
> semi-maximised, not just the same size and position as a semi-
> maximised window) Pressing a second time does nothing.
>
> Ctrl-Alt-Numpad 5 - Maximize window. If window is already Maximised,
> pressing this key combo restores the window to the exact same size,
> shape and positi...

Hi Karl,

I should note in advance that at the end of the day, the fix posted up there ended up segfaulting my compiz after a few random updates to oneiric in mainline, I recompiled it a few times and eventually got so tired of it I just reverted back to natty after trying pangolin (it's not just broken there but *totally* broken, if I recall correctly the plugin completely fails to work) and finding it no better.

I also tried nuking the *entire* compiz distro and all supporting infrastructure and rebuilding from source, but this is not much of a better solution either, random segfaults aplenty still.

For those that wish to continue with this line of wrestling in oneiric or pangolin you will want to be checking http://wiki.compiz.org/Plugins/Grid , you can grab the source via git and recompile like so;

git clone http://cgit.compiz-fusion.org/compiz/plugins/grid/

cd grid
mkdir build
cd build
cmake ../
make
sudo make install

But please keep in mind the problems I've iterated above and consider if you really want to go through this yourself.

Best of luck.

Le lun. 19 mars 2012 23:34:55 CET, Eric Bennett a écrit :
> Hi Karl,
>
> I should note in advance that at the end of the day, the fix posted up
> there ended up segfaulting my compiz after a few random updates to
> oneiric in mainline, I recompiled it a few times and eventually got so
> tired of it I just reverted back to natty after trying pangolin (it's
> not just broken there but *totally* broken, if I recall correctly the
> plugin completely fails to work) and finding it no better.
>
> I also tried nuking the *entire* compiz distro and all supporting
> infrastructure and rebuilding from source, but this is not much of a
> better solution either, random segfaults aplenty still.
>
>
> For those that wish to continue with this line of wrestling in oneiric or pangolin you will want to be checking http://wiki.compiz.org/Plugins/Grid , you can grab the source via git and recompile like so;
>
> git clone http://cgit.compiz-fusion.org/compiz/plugins/grid/
>
> cd grid
> mkdir build
> cd build
> cmake ../
> make
> sudo make install
>
> But please keep in mind the problems I've iterated above and consider if
> you really want to go through this yourself.
>
> Best of luck.
>

I think it's probably easier to look at compiz-plugins-main history on
launchpad
(http://bazaar.launchpad.net/~compiz-team/compiz-plugins-main/0.9.7/changes
or one of the others, or maybe
http://bazaar.launchpad.net/~lbrulet-8/compiz-plugins-main/fix-876591/revision/21),
find the first offending commit, and revert it in the current package
source to rebuild the package.

note that i didn't say «easy» i said «easier». But anybody finding the
time to restore the cycling on left/right (whatever key si configured
to them) will have my gratitude.

Le lun. 19 mars 2012 23:57:00 CET, Gabriel Pettier a écrit :
> Le lun. 19 mars 2012 23:34:55 CET, Eric Bennett a écrit :
>> Hi Karl,
>>
>> I should note in advance that at the end of the day, the fix posted up
>> there ended up segfaulting my compiz after a few random updates to
>> oneiric in mainline, I recompiled it a few times and eventually got so
>> tired of it I just reverted back to natty after trying pangolin (it's
>> not just broken there but *totally* broken, if I recall correctly the
>> plugin completely fails to work) and finding it no better.
>>
>> I also tried nuking the *entire* compiz distro and all supporting
>> infrastructure and rebuilding from source, but this is not much of a
>> better solution either, random segfaults aplenty still.
>>
>>
>> For those that wish to continue with this line of wrestling in
>> oneiric or pangolin you will want to be checking
>> http://wiki.compiz.org/Plugins/Grid , you can grab the source via git
>> and recompile like so;
>>
>> git clone http://cgit.compiz-fusion.org/compiz/plugins/grid/
>>
>> cd grid
>> mkdir build
>> cd build
>> cmake ../
>> make
>> sudo make install
>>
>> But please keep in mind the problems I've iterated above and consider if
>> you really want to go through this yourself.
>>
>> Best of luck.
>>
>
> I think it's probably easier to look at compiz-plugins-main history on
> launchpad
> (http://bazaar.launchpad.net/~compiz-team/compiz-plugins-main/0.9.7/changes
> or one of the others, or maybe
> http://bazaar.launchpad.net/~lbrulet-8/compiz-plugins-main/fix-876591/revision/21),
> find the first offending commit, and revert it in the current package
> source to rebuild the package.
>
> note that i didn't say «easy» i said «easier». But anybody finding the
> time to restore the cycling on left/right (whatever key si configured
> to them) will have my gratitude.

i would really try more to understand this patch if i had more time,
it's the most probable one to be linked to this bug in the set of
patches in the compij-plugins-main source package, alas my c++ foo is
really bad, and i really lack time to dive more into that.
http://bazaar.launchpad.net/~lbrulet-8/compiz-plugins-main/fix-876591/revision/21#debian/patches/fix-862260.patch

Eric, tshirtman,

Really appreciate your sharing your approaches for a work around to keep
this feature in oneiric and perhaps pangolin.

For my level of expertise, i'll remain patient a little longer before
diving in with spanner and wrench :)

Thanks again,

Karl

On Tue, Mar 20, 2012 at 00:45, tshirtman <email address hidden> wrote:

> Le lun. 19 mars 2012 23:57:00 CET, Gabriel Pettier a écrit :
> > Le lun. 19 mars 2012 23:34:55 CET, Eric Bennett a écrit :
> >> Hi Karl,
> >>
> >> I should note in advance that at the end of the day, the fix posted up
> >> there ended up segfaulting my compiz after a few random updates to
> >> oneiric in mainline, I recompiled it a few times and eventually got so
> >> tired of it I just reverted back to natty after trying pangolin (it's
> >> not just broken there but *totally* broken, if I recall correctly the
> >> plugin completely fails to work) and finding it no better.
> >>
> >> I also tried nuking the *entire* compiz distro and all supporting
> >> infrastructure and rebuilding from source, but this is not much of a
> >> better solution either, random segfaults aplenty still.
> >>
> >>
> >> For those that wish to continue with this line of wrestling in
> >> oneiric or pangolin you will want to be checking
> >> http://wiki.compiz.org/Plugins/Grid , you can grab the source via git
> >> and recompile like so;
> >>
> >> git clone http://cgit.compiz-fusion.org/compiz/plugins/grid/
> >>
> >> cd grid
> >> mkdir build
> >> cd build
> >> cmake ../
> >> make
> >> sudo make install
> >>
> >> But please keep in mind the problems I've iterated above and consider if
> >> you really want to go through this yourself.
> >>
> >> Best of luck.
> >>
> >
> > I think it's probably easier to look at compiz-plugins-main history on
> > launchpad
> > (
> http://bazaar.launchpad.net/~compiz-team/compiz-plugins-main/0.9.7/changes
> > or one of the others, or maybe
> >
> http://bazaar.launchpad.net/~lbrulet-8/compiz-plugins-main/fix-876591/revision/21
> ),
> > find the first offending commit, and revert it in the current package
> > source to rebuild the package.
> >
> > note that i didn't say «easy» i said «easier». But anybody finding the
> > time to restore the cycling on left/right (whatever key si configured
> > to them) will have my gratitude.
>
> i would really try more to understand this patch if i had more time,
> it's the most probable one to be linked to this bug in the set of
> patches in the compij-plugins-main source package, alas my c++ foo is
> really bad, and i really lack time to dive more into that.
>
> http://bazaar.launchpad.net/~lbrulet-8/compiz-plugins-main/fix-876591/revision/21#debian/patches/fix-862260.patch
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/878820
>
> Title:
> Window Management, Keyboard shortcut - The grid keybindings are
> behaving inconsistently
>
> Status in Ayatana Design:
> Fix Committed
> Status in Compiz Main Plugins:
> Invalid
> Status in “compiz” package in Ubuntu:
> Fix Released
> Status in “compiz-plugins-main” package in Ubuntu:
> Fix Released
> Status in “compiz” source package in Oneiric:
...

If Ctrl+Alt+Num4/6 are going to do nothing and Ctrl+Alt+Num5 is going to Max/Restore instead of position, the keyboard shortcuts overlay should say that. As is, it mentions the numpad shortcuts that work very inconsistently.

Multi-cycling of window sizes via grid was the single most important compiz feature for me (and still is on computers with 10.04). It is so much more convenient to press shortcut twice to get window in right 1/3 of the screen than to fight with mouse…

Whoever made the design decision to drop this functionality: PLEASE RECONSIDER. It makes grid plugin so much worse.

I'll just +1 that this behavior is inconsistent and confusing.

Ctrl+Alt+KP* works for everything but left and right, which are the most useful IMHO on widescreen monitors.

Super+L/R would be fine, but Super+Arrow Key presses appear to be misdetected (LP#972330), bringing up the keyboard overlay after a few seconds.

Eric

After today's update, Super+L/R no longer do anything at all. There is now no way to place windows left or right with the keyboard.

Eric

Eric, today's update changed the key combo to Ctrl+Super+Left/Right, I believe.

Many people disagree no matter what the combo is changed to. You can customize it by running: ccsm

The setting is in the Grid section of ccsm.

Is this going to be fixed in 11.10?

This still doesn't work in 11.10 .. My co-worker made a fresh install of 12.04 final beta and it still doesn't work. However he managed to make it work after fiddling in Compiz Config Manager, it seems at this point it was a key binding conflict.

This issue is really getting painful.

Comment #46 has it 100% right.

I'm starting to really *hate* how Ubuntu/Unity devs are hiding behind some hidden, nebulous idea of "design" whenever they take away or break features people want.

Perhaps the Grid plugin should be renamed to FourSquare to reflect its actual functionality.

Reverting to 'Triaged' as this bug is not fixed in the release version of 12.04

Please add an option for this in ccsm. Since the change to 50% the plugin has been useless for me, so please allow cycling between sizes for "put left" & "put right".

Also, +1 on what Gonzo wrote.

12.04 has been a marvelous upgrade for me -- except for this regression. Rapidly pulling windows side-by-side saved my much time as a software developer on a large monitor. Multiple key presses changing sizes meant that I could quickly give my text editor a little more width, and my terminal a little less.

Breaking the previous ctrl+alt+4/6 behaviour makes the rest of the resizing/moving numberpad shortcuts much less useful too, as the principle of least surprise has been violated pretty badly:

"Use ctrl+alt+numpad to move and resize windows. Up, down, top-right, top-left, bottom-right, bottom-left, and middle. All directions! It's easy!

Except for left or right. In that case you need to use the arrow keys instead. Oh, and don't use the control key anymore, use the super key this time. What's the super key you say? Ah, well..."

I would love to see evidence from an actual user test showing that the original behavior was "confusing", because I'm skeptical that any such evidence exists.

Can somebody find even *one* user who was "confused"?

I really hope this gets fixed. In many cases a 50/50 split is not the way to go. Half of the screen may be to little space for e.g. a browser window, but is wasted space for e.g. a terminal window. I use a 66/33 split way more often. While I would prefer separated shortcuts for 50/50 and 66/33 (or even something like Divvy), cycling is better than only having 50/50 BY FAR.

I upgraded from 10.04 to 12.04 yesterday, stumbled upon this bug/feature, and then restored 10.04 backups. Going back to resizing windows with the mouse instead of keyboard shortcuts is a step I don't want to take, it's slower by magnitudes. Please restore this functionality, pretty please with sugar on top.

What fixes/workarounds/alternatives are there at the moment? Compiling upstream grid from source? I tried and failed. Switching distribution? I'm not happy about that idea either.

I've hacked back in the old behavior and created a PPA:

https://launchpad.net/~ef/+archive/grid-cycling

At the moment it's waiting in the build queue, and will be for several hours.

If you're adventurous and on amd64, you can try these. They work for me, but that's no guarantee they won't light your computer on fire, etc, etc:

http://dl.dropbox.com/u/239052/compiz-plugins-main_0.9.7.0%7Ebzr19-1custom11_amd64.deb
http://dl.dropbox.com/u/239052/compiz-plugins-main-default_0.9.7.0%7Ebzr19-1custom11_amd64.deb

These work for me. Thank you, Edward.

So we started with a bug saying that ctrl+alt+num behaved inconsistently and ended up with the same problem + different shortcuts?

I don't get why it makes any sense to have 1,2,3,7,8,9 working but not 0,4,5 and 6. It was ok the way it was in 11.10, it made sense. Now it doesn't make sense, and having to change alt to super makes it even more annoying.

Thank you Edward, until now I had no problems whatsoever.

Is there another way to remap the shortcuts then ccsm?

Are there any updates on this? We're having the same discussion over at Bug #879218 (https://bugs.launchpad.net/unity/+bug/879218) and everyone there also agrees that the old behaviour is more desirable. The devs don't seem to care though :(

This branch follows the Ayatana Design specification in the description and fixes behaviour for top and bottom windows as well
(corner and centered will still cycle):
lp:~mc-return/compiz/compiz.merge-fix1082001-gridded-windows-jump-workspaces

@all: Long term plan is to make behaviour configurable by the user, so everyone will be satisfied.

Cycling through sizes is disabled in my branch for all gridded windows for now, following design specifications in the description of this bug.

Long term plan is finished:

The branch linked here makes the cycling through different grid sizes behaviour fully configurable via CCSM.
CCSM Screenie: http://uppix.net/5/f/4/c21c285ee4ce86b1b9f756e3c17ab.png

:)

Thanks! That sounds great.

Fix committed into lp:compiz at revision 3650, scheduled for release in compiz, milestone 0.9.10.0

A video showing current trunk version:
https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/745159/+attachment/3660185/+files/GridAllFunctionalityFullyFixed.mp4

Happy viewing :)

That looks sweet, thanks a lot, cannot wait till saucy :-).

This bug was fixed in the package compiz - 1:0.9.10+13.10.20130822-0ubuntu1

---------------
compiz (1:0.9.10+13.10.20130822-0ubuntu1) saucy; urgency=low

  [ Sam Spilsbury ]
  * Bump version to 0.9.10

  [ Łukasz 'sil2100' Zemczak ]
  * Remove debian/patches/unity_support_test.patch:
    - Running the support test from compiz has bad side effects, from now
      on we run it from Xsession.d
  * Automatic snapshot from revision 3644

  [ Iven Hsu ]
  * Opacify: Only dim the windows above the active window.(LP:
    #1189374). (LP: #1189374)
  * KWD: Fix compile errors with KDE 4.11. The KWin developers made
    kdecorationbridge.h private. See:
    http://lists.freedesktop.org/archives/compiz/2013-March/003479.html
    (LP: #1193792). (LP: #1193792)

  [ Nikolay Martynov ]
  * When static switcher is enabled and has an option to show
    application icon turned on the icons are expected to be ~1/3 of a
    thumbnail (48px). Instead they are displayed in 512px size and
    completely cover everything. This change addresses this issue. See
    LP #1173914. (LP: #1173914, #1186426)

  [ BryanFRitt ]
  * Fixed the non-working Annotate 'Clear' Button. Moved this option's
    CCSM position upwards to keep the button shortcuts together. (LP:
    #1202907). (LP: #1202907)

  [ Mehrdad Afshari ]
  * Added "move window to previous monitor" feature to compiz Put
    plugin. (LP: #1178581)

  [ Hu Kang ]
  * gtk-window-decorator: destroy action menu when any of the (close,
    min, max) buttons on the title bar is pressed. (LP: #1101648)
  * Remove redundant src/logmessage/include/core/logmessage.h (LP:
    #1067246). (LP: #1067246)

  [ Steve Langasek ]
  * Fix for bug #763148 (with added test cases): when the desktop is
    resized, windows should stay on their original workspace. (LP:
    #763148)

  [ Brandon Schaefer ]
  * Unrevert 3728, fix failing tests. Change the behaviour of
    undecorating windows. Previously when a window was undecorated, we
    would shift it back to an appropriate position according to its
    gravity member. That behaviour was problematic because in the
    StaticGravity case the window has to just stay in the same place.
    But then if you had a window with StaticGravity which then did get a
    decoration and later removed it, it would be placed as though it was
    decorated and appear to be in the wrong place. The correct behaviour
    is to place all windows as though they have decorations, and then
    when decorations are removed, to move the window back to the corner
    as indicated in its gravity and then expand its size to cover the
    obscured regions no longer hidden because the decorations went away.
    (LP: #1165343).   1. Completely remove decorOffsetMove and other
    related code from      decor.cpp. Put the logic to handle the
    window->input () - window->border ()      placement offset inside of
    setWindowFrameExtents instead. Now the window      will always be
    offset from its original non-decorated position to the new
         decorated position, rather than having to guess between
    decoration sizes.   2. Make saveGeometry and restoreGeometry work
    relative to window->border ()      a...