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:
>  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
>