compiz team mailing list archive

[Anthony Francis <455378@xxxxxxxxxxxxxxxxxx>]

What progress has been made on rolling this behavior back? As far as I
can see reading through the attached links the change behind this
breakage fixes a non-problem (windows can always be moved and resized
through the task list) but it breaks a large number of programs,
including any window which tries to create itself at a size that would
span two monitors, not to mention xemacs, blender and especially No
Machine which reacts very, very badly to this. Assigning a keystroke to
do the resize does not fix the problem; any window that then tries to
tweak itself after resizing shrinks back to one monitor.

I've looked at the code which *apparently* affects this change (not
being a compiz expert ... more than one thing may be involved here) and
it really doesn't make sense - there was a clear setting which
enabled/disabled this behavior, which was completely removed in favor of
trying to be "smart". This was almost certainly not tested on multiple
monitors as I can't imagine someone who'd seen what happens actually
submitting it, much less making it into a release.  I'm working on a
change to roll this back on a personal build, but that will of course
get out of sync as Compiz is updated.

Please, please, roll this back or roll forward a fix! This is close to a
dealbreaker on a piece of software I've used successfully for years, and
some of the comments made about this bug being a non-problem simply
stagger me as clearly they haven't seen how badly this breaks Compiz.

-- 
You received this bug notification because you are a member of compiz
packagers, which is subscribed to compiz in ubuntu.
https://bugs.launchpad.net/bugs/455378

Title:
  Can't resize windows to be displayed on several monitors