Comment 40 for bug 878820

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 position it was before it was Maximised.
>
> Ctrl-Alt-Numpad 6 - Place window on the right side of the screen (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 1 - Place window in the bottom left corner of the
> screen. Pressing a second time does nothing.
>
> Ctrl-Alt-Numpad 2 - Place window in the bottom half of the screen.
> Pressing a second time does nothing.
>
> Ctrl-Alt-Numpad 3 - Place window in the bottom right corner of the
> screen. Pressing a second time does nothing.
>
> Ctrl-Alt-Numpad 0 - Minimise window.
>
>
> Note: in order for this bug to be fixed, Compiz needs to be amended to
> support multiple key bindings
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/ayatana-design/+bug/878820/+subscriptions
>