Expo Plugin: Multi-Monitor Behavior: Appearance -> Multi Output Mode "One big wall" selectable, but ignored without explanation if displays use different resolutions

Bug #1009592 reported by MC Return on 2012-06-06
20
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Compiz
Low
MC Return
compiz (Ubuntu)
Undecided
Unassigned

Bug Description

I can select Expo->Appearance->Multi Output Mode->One big wall, but the setting gets ignored and Expo shows One wall per output when used, apparently because the monitors use different resolutions.

The code says that this behaviour is intentional, which is quite okay - but the user should be informed about it.
The tooltip in CCSM should at least mention that "One big wall" will only work if using the same resolution on/for all monitors/displays.

Related branches

MC Return (mc-return) on 2012-06-14
tags: added: amd64 compiz-0.9 precise running-unity ubuntu
Sam Spilsbury (smspillaz) wrote :

Do you have monitors of different sizes? The option is forced to be one per output in that case, since one big wall makes no sense there.

Changed in compiz:
status: New → Incomplete
MC Return (mc-return) wrote :

Yes, the monitors use different resolutions: one is 1920x1200, the second 1280x1024, so that explains this (new) behavior.

Still the selection of "One Big wall" is possible, but gets silently ignored then - it would be better if this option would not be available in this case to not confuse anyone.

summary: - Expo Plugin: Cannot change Appearance -> Multi Output Mode to "one wall
- per output"
+ Expo Plugin: Multi-Monitor Behavior: Appearance -> Multi Output Mode to
+ "One big wall" selectable, but ignored when monitors use different
+ resolution

I've updated the title and initial bug report to describe the situation better.

description: updated
MC Return (mc-return) on 2012-06-24
Changed in compiz:
status: Incomplete → New
Mariusz Bal (gullybox) wrote :

part of the wall on my second monitor is moved outside visible area.

Ari (ari-lp) wrote :

@Mariusz Bal

Same problem for me. Using notebook panel (1366x768) in addition to external display (1920x1080). Wall is off-center on external display, slightly shifted to the left.

MC Return (mc-return) on 2012-11-02
description: updated
MC Return (mc-return) on 2012-11-02
Changed in compiz:
assignee: nobody → MC Return (mc-return)
Changed in compiz:
status: New → In Progress
milestone: none → 0.9.9.0
summary: Expo Plugin: Multi-Monitor Behavior: Appearance -> Multi Output Mode to
- "One big wall" selectable, but ignored when monitors use different
- resolution
+ "One big wall" selectable, but ignored without explanation when monitors
+ use different resolution
Changed in compiz:
importance: Undecided → Low
Changed in compiz:
milestone: 0.9.9.0 → 0.9.9.2
Changed in compiz:
milestone: 0.9.9.2 → 0.9.10.0

It makes no sense to remove this option from the user as it is actually very much usable with different-resolution screens (see attached screenshot).
The branch linked here (lp:~mc-return/compiz/compiz.merge-expo-code-cleanup) fixes this issue.

MC Return (mc-return) on 2013-05-28
summary: - Expo Plugin: Multi-Monitor Behavior: Appearance -> Multi Output Mode to
+ Expo Plugin: Multi-Monitor Behavior: Appearance -> Multi Output Mode
"One big wall" selectable, but ignored without explanation when monitors
use different resolution
summary: Expo Plugin: Multi-Monitor Behavior: Appearance -> Multi Output Mode
- "One big wall" selectable, but ignored without explanation when monitors
+ "One big wall" selectable, but ignored without explanation if displays
use different resolution
summary: Expo Plugin: Multi-Monitor Behavior: Appearance -> Multi Output Mode
"One big wall" selectable, but ignored without explanation if displays
- use different resolution
+ use different resolutions
PS Jenkins bot (ps-jenkins) wrote :

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

Changed in compiz:
status: In Progress → Fix Committed
Stephen M. Webb (bregma) wrote :

Fix Released in Compiz Compiz 0.9.10.0.

Changed in compiz:
status: Fix Committed → Fix Released
Launchpad Janitor (janitor) wrote :
Download full text (70.8 KiB)

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

Changed in compiz (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.