> >
> > "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.launchp
> ad.net/compiz/+bug/1041822/+attachment/3370316/+files/Expo2ndDisplayBlack.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:
> https://bugs.launchpad.net/compiz/+bug/1024373/+attachment/3370329/+files/Expo
> WrongPath.mp4 )
> 
> 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):
> https://bugs.launchpad.net/compiz/+bug/1009592/+attachment/3687163/+files
> /Expo-2screens-different-resolution-very-usable_scaled_down.png

It does appear from the screenshots to be a lot better from what I remember, however screenshots can be misleading. One needs to consider how monitors are positioned in reality. Then again, I can see the argument for allowing it to work so long as the user asked for it - it might just be that the user's monitors are positioned correctly so that it doesn't look misaligned. But there's no way to verify this programatically

What I might suggest is that - how about changing the default in the .xml file to be "one wall per output" and I'll look into any bugs to do with the second output being black (I'm sure its quite simple). Then the user can pick "one big wall" if it would make sense on their particular configuration, as I think it tends to work better in fewer configurations than the former does. Doing it that way, incidentally, helps to get around some complicated alignment issues that happen with unity, and I believe that the workspaces design specification mandated independent workspace picking per output.

Thanks for the other fixes though, I'll get to them now.