Successful rotation to nonexistent face

Edit:
The second part of this bug is erroneous; I had inadvertently enabled two outputs in the General Options > Display Settings: one that was 1680x1050, one that was 640x480, both at +0+0.

Cheers,
Jesse Burt

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Hardy Heron. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

On Thu, 2008-02-14 at 17:33 +0000, Pedro Villavicencio wrote:
> reproducible with the live environment of the Desktop CD of the
> development release - Hardy Heron. It would help us greatly if you could
> test with it so we can work on getting it fixed in the next release of

Confirmed on the i386 Live CD from Feb 14. To reproduce in the live
environment, you must (as far as I know) download the ccsm (Compiz
Config Settings Manager) and enable Desktop Cube and Rotate Cube
plugins. In the Rotate Cube configuration, enable keybinding for a
desktop face that doesn't actually exist (I picked #12) and then use
that keybinding. The desktop will spin wildly getting to that face (or
face 12 at least). This doesn't seem to affect the ability to rotate
back to a valid face, though.

It doesn't rotate to a non-existant face, it rotates to one of your currently available faces. I have cube setup with 2 viewports (so it works like a piece of paper) and hitting the "Rotate to viewport 12" keybinding spun the whole thing around a few times but landed on viewport 2.

> It doesn't rotate to a non-existant face, it rotates to one of your
> currently available faces. I have cube setup with 2 viewports (so it
> works like a piece of paper) and hitting the "Rotate to viewport 12"
> keybinding spun the whole thing around a few times but landed on
> viewport 2.

Travis,

Okay, I thought since it successfully switched when asked to that
perhaps it was actually trying to switch to an imaginary one. Thanks for
the reply.

This bug was fixed in the package compiz - 1:0.7.2-0ubuntu1

---------------
compiz (1:0.7.2-0ubuntu1) hardy; urgency=low

  * new upstream release:
    - fix crash in window decorators (LP: #128651)
    - fix crash in cairo_set_line_width (LP: #149535)
    - fixes in compiz scale (LP: #159780)
    - fix resizing taskbar (LP: #172716)
    - do not rotate to non-existing faces (LP: #149460)
    - fixed incorrect switcher position (LP: #158877)
    - add missing i18n (LP: #152911)
    - do not switch viewports when a window requests to
      get focus but wait if it actually really got it
    - and more fixes
  * debian/control:
    - update standards version
    - use ${binary:Version}
    - add section 'libdevel' to libdecoration0-dev
    - updated depends for the compiz metapackage
  * debian/copyright:
    - update FSF adress

 -- Michael Vogt <email address hidden> Fri, 07 Mar 2008 14:26:18 +0100

Fix confirmed...mostly. Here is my setup now:

Installation based on Hardy Alpha 4
Compiz set up with horizontal virtual size set to n ...let's say n=2
I can switch to desktop #1 using the binding for desktop #3, but only if I switch to #2 first. If I try to switch to 3 from 1, it behaves as expected (i.e., does nothing)
I have tested this with other values for horiz. virtual size...it behaves the same way.
IOW, I can always switch to the first desktop by using the keybinding for the number of desktops I actually have defined, plus one (n+1), as long as I am currently viewing the last desktop (n)