>
> "One big wall" is currently the default behavior which makes some sense so
> long as the screens have exactly the same resolution.
We can argue about the best default of course. (have not even looked up what
it is set to in upstream/ubuntu)
> Its *completely* broken
> for multimonitor configurations with different resolutions. There's just no
> sane way to line the views up so that they look correctly when the wall is
> only rendered in one pass. This change should be reverted.
>
> I even have misgivings about the way that it works on multimonitor
> configurations where you have the same resolution and a number of viewports
> that is not evenly divisible amongst the monitors. It results in confusing
> situations where viewports end up partially on one monitor and partially on
> another and does not make for a good user experience.
>
Another response, especially regarding this change:
So forcing the user to use "One wall per output" is a very bad idea and leads to additional troubles, which do not occur with "One big wall"...
Another reason why a large wall spanning over multiple screens is important is the size of the miniature viewports itself, which in a typical horizontal monitor configuration logically have a high x to y ratio: 3.2 : 1.2 in my case for example, so in a 4:1 viewport
configuration (needed for the cube for example) this means a ratio of 12.8 : 1.2 (!).
Of course this fits much better onto 3200x1200 than 1280x1024, which would be the small monitor... hard to identify the correct window, everything is that small...
>
> "One big wall" is currently the default behavior which makes some sense so
> long as the screens have exactly the same resolution.
We can argue about the best default of course. (have not even looked up what
it is set to in upstream/ubuntu)
> Its *completely* broken
> for multimonitor configurations with different resolutions. There's just no
> sane way to line the views up so that they look correctly when the wall is
> only rendered in one pass. This change should be reverted.
>
> I even have misgivings about the way that it works on multimonitor
> configurations where you have the same resolution and a number of viewports
> that is not evenly divisible amongst the monitors. It results in confusing
> situations where viewports end up partially on one monitor and partially on
> another and does not make for a good user experience.
>
Another response, especially regarding this change:
This change also helps users hitting bug #1041822 (video: https:/ /bugs.launchpad .net/compiz/ +bug/1041822/ +attachment/ 3370316/ +files/ Expo2ndDisplayB lack.mp4 ), because this bug won't occur in "One big wall" mode.
Also it resolves bug #1024373 - Expo Zoom Animation uses wrong path on second screen in multimonitor configurations (video: /bugs.launchpad .net/compiz/ +bug/1024373/ +attachment/ 3370329/ +files/ ExpoWrongPath. mp4 )
https:/
So forcing the user to use "One wall per output" is a very bad idea and leads to additional troubles, which do not occur with "One big wall"...
Another reason why a large wall spanning over multiple screens is important is the size of the miniature viewports itself, which in a typical horizontal monitor configuration logically have a high x to y ratio: 3.2 : 1.2 in my case for example, so in a 4:1 viewport
configuration (needed for the cube for example) this means a ratio of 12.8 : 1.2 (!).
Of course this fits much better onto 3200x1200 than 1280x1024, which would be the small monitor... hard to identify the correct window, everything is that small...
Muuuch better that way:
It shows Expo in dual-screen mode with 1920x1200 and 1280x1024 screens (3200x1200 4x downscaled): /bugs.launchpad .net/compiz/ +bug/1009592/ +attachment/ 3687163/ +files/ Expo-2screens- different- resolution- very-usable_ scaled_ down.png
https:/