Can't resize windows to be displayed on several monitors

Bug #455378 reported by Sylvain Rabot
170
This bug affects 33 people
Affects Status Importance Assigned to Milestone
compiz (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

Binary package hint: compiz

srabot@khety:~$ uname -a
Linux khety 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux

Since this morning, well since my last apt-get dist-upgrade, I'm not able anymore to resize my windows to be displayed on two monitors (like that http://www.flickr.com/photos/absynthe/4025164739/). I'm able to move the windows across the two but I can't increase the windows' width with a value superior of the width resolution of one screen (http://yfrog.com/02capture1gp).

I tried with metacity --replace and it's working so I think it's something related to compiz.

I don't know what you need so tell me and I will provide.

Regards.

ProblemType: Bug
Architecture: i386
CompizPlugins: [core,move,resize,place,decoration,animation,ccp,vpswitch,dbus,mousepoll,workarounds,video,session,svg,extrawm,text,gnomecompat,neg,imgjpeg,regex,png,shift,snap,wall,resizeinfo,wobbly,fade,expo,scale,ezoom,scaleaddon,staticswitcher]
Date: Mon Oct 19 13:18:15 2009
DistroRelease: Ubuntu 9.10
Lsusb:
 Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
 Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
NonfreeKernelModules: nvidia
Package: compiz 1:0.8.4-0ubuntu1
PackageArchitecture: all
PciDisplay: 02:00.0 VGA compatible controller [0300]: nVidia Corporation G96 [GeForce 9500 GT] [10de:0640] (rev a1)
ProcCmdLine: root=UUID=81162d5d-7691-4918-8730-db6c4b12c9c4 ro quiet splash
ProcEnviron:
 PATH=(custom, user)
 LANG=fr_FR.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
RelatedPackageVersions:
 xserver-xorg 1:7.4+3ubuntu5
 libgl1-mesa-glx 7.6.0-1ubuntu4
 libdrm2 2.4.14-1ubuntu1
 xserver-xorg-video-intel 2:2.9.0-1ubuntu2
 xserver-xorg-video-ati 1:6.12.99+git20090929.7968e1fb-0ubuntu1
SourcePackage: compiz
Uname: Linux 2.6.31-14-generic i686
dmi.bios.date: 03/20/2007
dmi.bios.vendor: Award Software International, Inc.
dmi.bios.version: FC
dmi.board.name: M55S-S3
dmi.board.vendor: Gigabyte Technology Co., Ltd.
dmi.board.version: x.x
dmi.chassis.type: 3
dmi.modalias: dmi:bvnAwardSoftwareInternational,Inc.:bvrFC:bd03/20/2007:svn:pn:pvr:rvnGigabyteTechnologyCo.,Ltd.:rnM55S-S3:rvrx.x:cvn:ct3:cvr:
system: distro = Ubuntu, architecture = i686, kernel = 2.6.31-14-generic

Revision history for this message
Sylvain Rabot (sylr) wrote :
Revision history for this message
Sylvain Rabot (sylr) wrote :

Hey,

I have the same problem at home with a pretty similar configuration, two 19" screens (1280 * 1024).

I made a video of the bug : http://www.youtube.com/watch?v=A5cb5wX5VZY

Regards.

Revision history for this message
Sylvain Rabot (sylr) wrote :
Revision history for this message
Erkin Bahceci (cornelius1) wrote :

You should be able to resize windows beyond work area edges with Alt + Middle click (by default), which can be configured in Resize plugin options in ccsm. Does that work there?

Resizing by dragging window borders is limited to work area by Compiz to prevent window edges from becoming inaccessible while resizing by going behind panels or beyond screen edges. To handle this issue, Metacity instead uses snapping during resize, which Compiz 0.8.4 lacks.

Revision history for this message
Sylvain Rabot (sylr) wrote :

Thanks for the trick, it works :)

Revision history for this message
wetmonkey (wetmonkey) wrote :

I assume there is a setting in compiz to allow this. Prior to upgrade to 9.10 I was able to resize across monitors without special key strokes.
I can override the output settings in the general tab by changing the output to 2560x1024. However, clicking maximize on a window goes fullscreen across both monitors. Prior to upgrade, maximize would be limited to single monitor which is the preferable action.

A large majority of my compiz settings were reset during the upgrade so it's proven difficult to find the setting allowing this option back.

Revision history for this message
wetmonkey (wetmonkey) wrote :

I just noticed another difference which could be related.
While using 4 desktops ::

When I activate "Rotate Cube" and rotate the desktop I am presented with two eight sided 'cubes'. Prior to the upgrade I was presented with two different cubes, each with four sides. Each cube representing the physical monitor.

Revision history for this message
wetmonkey (wetmonkey) wrote :

Found another one which may not be related, but because it's in the resize plugin....

I can't remap the setting for "Initiate Window Resize" for either keyboard or mouse. I change it, click "back" and then go back into the settings and it's remapped back to <Alt>Button2

Revision history for this message
wetmonkey (wetmonkey) wrote :

Disregard previous comment :: Solution found at https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/153626/comments/9

Revision history for this message
mback (mback) wrote :

Well, this new behavior is equivalent of "breaking" compiz for me. I was very comfortable with the old behavior of compiz naturally allowing windows to be resized across displays... I'll try the workaround, but this new behavior is counterintuitive, and should be treated as a bug. It's only with compiz that this happens... if I disable compiz, I can naturally resize windows across multiple displays.

Revision history for this message
Frakie (frakieack) wrote :

Agree with mback. This "feature" makes everybody think about a bug.
Unhappy change on compiz.

Revision history for this message
acroporas (acroporas) wrote :

Agreed. This is a bug. At a minimum there should be a setting to turn this "Feature" off.

Revision history for this message
Max Bowsher (maxb) wrote :

This issue was introduced in the 1:0.8.4-0ubuntu1 upload.

This portion of the changelog sounds relevant:
    - cannot resize window taller than screen (LP: #221698)

Changed in compiz (Ubuntu):
status: New → Confirmed
tags: added: regression-release
Revision history for this message
mback (mback) wrote :

It seems that others have had success working around this bug, but I have to confess that I am at a loss... With compiz enabled, I cannot drag-resize windows to larger than one screen. Neither can I make full-screen of an application use up multiple screens... this is especially problematic with VNC where I need to control systems with multiple monitors. Can anyone help with straightforward instructions to enable the functionality that I need with compiz enabled?

Revision history for this message
Alexandre Anoutchine (xirius) wrote :

This is really annoying problem for me :(

Revision history for this message
markboo (markboo99) wrote :

Just wanted to note that this bug is still in 10.04 LTS - Lucid Lynx

Revision history for this message
jasonq (jason-quinn) wrote :

Also seeing in Ubuntu 10.04 LTS with Nvidia drivers. This appears to be Bug 1219 "Unable to resize across monitors on nvidia" at the Opencompositing Bugzilla. http://bugs.opencompositing.org/show_bug.cgi?id=1219

Revision history for this message
fermulator (fermulator) wrote :

I'm experiencing the same bug using ATI proprietary fglrx drivers, so it's not ATi/nVidia related given that people are seeing the problem using both vendor cards.

Revision history for this message
cometdog (ericctharley) wrote :

@mback - if you still need a workaround
1. install CompizConfig Settings Manager
2. Under the category Window Management, turn on Resize Window
3. Assign your desired keyboard shortcut to the last entry on the Bindings tab, Initiate Window Resize. I'm using <Alt>F8.
Use the keyboard shortcut followed by mouse movement to resize the window across multiple screens. This works for me on 9.10; I assume it would be the same or similar on 10.04.

Revision history for this message
mback (mback) wrote :

@cometdog - Thanks for the tip... I've been using the Alt-F8 workaround for some time... but it is still inconvenient.

My use case is that I need to control multi-headed remote workstations via VNC. I also sometimes have large spreadsheets and text editing that spans multiple screens. So, I often really need the ability to span/resize and full-screen across monitors with the same convenience on Compiz as with stock Gnome. Often I just get frustrated and just turn the darn thing off... but I do miss my eye candy...

Compiz resize should work the same as Gnome resize. The Alt-F8 "feature" is counterintuitive and is a bug. You can see how many people are in agreement -- Though perhaps if they would share their particular use cases, we could get a better understanding of "requirements."

I'm not on the list of developers, and I don't right now have the energy to figure out Compiz, dig in, and fix it, but I suppose that if I want it fixed, I'll have to take a look at the code... when I get the chance.

Revision history for this message
Travis Watkins (amaranth) wrote :

The only way we'll get the old behavior back is if someone implements edge snapping on resize, like it works on move now. Otherwise the reason for making this change still exists and I'd say overwhelms this issue.

Revision history for this message
mback (mback) wrote :

@Travis -- I see hints from Cornelius and you about the issue in the postings, but will you fully describe the "reason for making this change" here (or provide a link), because to us it just seems like this is a misfeature and inconvenient...

I think I remember the menu gnome sometimes folding over/under the menus on maximize, but can't remember, and I don't think I really cared... Seemed to me that this behavior was preferable to the current situation and OK on older versions of Compiz prior to the Ubuntu 9.10 release... And it's that behavior I want regardless of the perception of bugginess.

o Can you point us to the place in the code, or patch, that modified the behavior so that I/we can revert the change that caused the breakage, or disable the misfeature when working with multiple monitors?

o Can you help us understand what is involved in implementing "edge snap on resize?"

Revision history for this message
vida (kiki-h) wrote :

I was able to resize windows by dragging the edges over 2 monitors using 9.04 with Nvidia drivers. After upgrading via 9.10 to 10.04 this is not possible anymore. I lost over an hour to find out about the issue.

The workarounds ALT-F8 and ALT-middle button do work - but I find it rather inconvenient to have to manually enable this in the compiz settings and still be forced to change the way I worked.
It also makes it harder for people switching from Windows where it also works simply by dragging an edge or corner across to the second monitor.

mback's questions remain open.

Revision history for this message
mback (mback) wrote :

With Maverick, now I am able to left-click and drag across screens... I'm not certain which setting in compiz enabled this... However one issue still remains especially WRT VNC clients...

My job requires me to access offline systems that span multiple monitors. "Coincidentally" my laptop when docked is connected to dual monitors with the exact same resolution as my offline systems. When I full-screen my VNC session, I expect full-screen to span multiple monitors -- however, with compiz, full-screen snaps to one monitor.

So thanks guys -- work is almost done... If you guys can help me with the configuration setting in compiz that will allow full-screen to span monitors, that would be awesome.

Revision history for this message
mback (mback) wrote :

Thinking about this more... There are situations where I want full-screen and maximize to mean different things... At work with VLC, it definitely means "span all screens" so that F11 in Vinagre or Remmina can work effectively with my remote workstations, so that some games can span multiple windows when in full-screen, or so that my Excel application will either full-screen or Maximize to multiple monitors for those /really/ big spreadsheets... However, I may want full-screen to mean "span 1 screen" when I am viewing a DVD or full-screening/Maximizing my email client, /sometimes/ full-screening or maximizing a Terminal session, or running OoLite with only 2 monitors.

So... is there a (script-able) way to configure Compiz to switch between full-screen and maximize modes?

Revision history for this message
Anthony Francis (anthony-g-francis) wrote :

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.

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Re: [Compiz] [Bug 455378] Re: Can't resize windows to be displayed on several monitors
Download full text (3.2 KiB)

On Tue, Dec 7, 2010 at 7:10 AM, Anthony Francis
<email address hidden> wrote:
> 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
>

Hi Anthony.

According to the EWMH the default expected behavior for all window
managers is to fullscreen windows only on the *active* monitor (See
_NET_WM_STATE_FULLSCREEN[1]). However if your application wants to
expand over *multiple* monitors then it needs to set the
_NET_WM_FULLSCREEN_MONITORS hint[2] on the root window.

So this behaviour is already supported in compiz - but your
application which wants to fullscreen over multiple monitors needs to
specify this hint in order to do that. The reason we don't fullscreen
over multiple monitors by default is because it doesn't make sense in
the majority of usecases - eg most fullscreened applications on both
monitors actually just looks awful, such as web browsers, video
players etc. However it makes sense in some cases such as yours which
is why we include that hint.

Let the author of your VNC client know that they should support this
hint and when they do your application should just work.

[1] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2551694
[2] http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552578

> Title:
>  Can't resize windows to be displayed on several monitors
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to     : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help   : https://help.launchpad....

Read more...

Revision history for this message
Jeff Ebert (jeffrey-ebertland) wrote :

Hi Sam,

Useful input. I have a patch for remmina that specifies the _NET_WM_FULLSCREEN_MONITORS hint with the number of coordinates of monitors to both of my monitors (when I had two).

The binary choice of "fullscreen in one monitor" and "fullscreen across all monitors" is not too much to ask an application to provide. The configuration code for my patch is still needed. If anybody wants to take it on, I will help you get started.

The general case of NxM monitors in a grid, which is supported by this hint, is pretty difficult to configure and it is not something that each application should need to provide. I suggest that it's a desktop environment function to help the user decide, say, that VNC viewer #1 should fullscreen across monitors 1&2 and VNC viewer #2 should fullscreen across monitors 3&4, and mplayer should fullscreen on monitor #5 only.

It would be great to have a tool that could modify the hint for any application. Does anybody know if this is possible and/or being worked on? I envision a small utility that can set the hint on any running window with a nice gui to arrange fullscreen windows.

I might add that in the old days, there would have been a configuration knob *somewhere* in the WM to let the user choose the default behavior of _NET_WM_STATE_FULLSCREEN. :-|

Jeff

Revision history for this message
Jeff Ebert (jeffrey-ebertland) wrote :

Whoops, this issue is probably unrelated to the FULLSCREEN WM hints, since it has to do with resizing windowed applications.

Anthony, I am interested in your change, so please post it here or email me when you are ready to share it!

Revision history for this message
Sam Spilsbury (smspillaz) wrote :

On Tue, Dec 7, 2010 at 11:39 AM, Jeff Ebert <email address hidden> wrote:
> Hi Sam,
>
> Useful input. I have a patch for remmina that specifies the
> _NET_WM_FULLSCREEN_MONITORS hint with the number of coordinates of
> monitors to both of my monitors (when I had two).
>
> The binary choice of "fullscreen in one monitor" and "fullscreen across
> all monitors" is not too much to ask an application to provide. The
> configuration code for my patch is still needed. If anybody wants to
> take it on, I will help you get started.
>
> The general case of NxM monitors in a grid, which is supported by this
> hint, is pretty difficult to configure and it is not something that each
> application should need to provide. I suggest that it's a desktop
> environment function to help the user decide, say, that VNC viewer #1
> should fullscreen across monitors 1&2 and VNC viewer #2 should
> fullscreen across monitors 3&4, and mplayer should fullscreen on monitor
> #5 only.
>
> It would be great to have a tool that could modify the hint for any
> application. Does anybody know if this is possible and/or being worked
> on? I envision a small utility that can set the hint on any running
> window with a nice gui to arrange fullscreen windows.

There is no tool as of yet, but I don't see writing one as
particularly difficult. Maybe you might want something like this in
your application

Atom netWmFullscreenMonitors = XInternAtom (display,
"_NET_WM_FULLSCREEN_MONITORS");
Window root = RootWindow (ScreenOfDisplay (display));
XEvent msg;

msg.message_type = netWmFullscreenMonitors;
msg.format = 32;
msg.data.l[0] = MonitorId1;
msg.data.l[1] = MonitorId1;
msg.data.l[2] = MonitorId1;
msg.data.l[3] = MonitorId2;
msg.data.l[4] = 1;

XSendEvent (display, root, msg);

That should send a ClientMessage to the root window with that hint,
which compiz will receive and process. Next time an application tries
to go fullscreen it will fullscreen to those dimensions.

>
> I might add that in the old days, there would have been a configuration
> knob *somewhere* in the WM to let the user choose the default behavior
> of _NET_WM_STATE_FULLSCREEN. :-|
>
> Jeff
>
> --
> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to     : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help   : https://help.launchpad.net/ListHelp
>

--
Sam Spilsbury

Revision history for this message
Sam Spilsbury (smspillaz) wrote :

On Thu, Nov 4, 2010 at 10:03 PM, vida <email address hidden> wrote:
> I was able to resize windows by dragging the edges over 2 monitors using
> 9.04 with Nvidia drivers. After upgrading via 9.10 to 10.04 this is not
> possible anymore. I lost over an hour to find out about the issue.
>
> The workarounds ALT-F8 and ALT-middle button do work - but I find it rather inconvenient to have to manually enable this in the compiz settings and still be forced to change the way I worked.
> It also makes it harder for people switching from Windows where it also works simply by dragging an edge or corner across to the second monitor.
>
> mback's questions remain open.

Yes this is a regression (just saw it now when doing some other
fixes). I will be making it an option in 0.9 (should hit Natty
sometime this week)

>
> --
> Can't resize windows to be displayed on several monitors
> https://bugs.launchpad.net/bugs/455378
> You received this bug notification because you are a member of compiz
> packagers, which is subscribed to compiz in ubuntu.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to     : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help   : https://help.launchpad.net/ListHelp
>

--
Sam Spilsbury

Revision history for this message
Gerry (gerry-spm+lnchpad) wrote :

Sam, after trying to work around this for two releases of Ubuntu, I would seriously consider proposing to you if you did that! Kidding, that would only discourage you, but in all seriousness, THANK YOU if you do add this option. :)

Revision history for this message
Sam Spilsbury (smspillaz) wrote :

On Tue, Dec 7, 2010 at 8:14 PM, Gerry <email address hidden> wrote:
> Sam, after trying to work around this for two releases of Ubuntu, I
> would seriously consider proposing to you if you did that! Kidding, that
> would only discourage you, but in all seriousness, THANK YOU if you do
> add this option. :)
>

It only takes two lines of code ....

> --
> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to     : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help   : https://help.launchpad.net/ListHelp
>

--
Sam Spilsbury

Revision history for this message
Anthony Francis (anthony-g-francis) wrote :

Sam, thank you for your detailed response! I can see what you are saying about fullsizing something to multiple monitors. However, in the use case I have I'm using multiple portrait-oriented monitors to display a single desktop so that creates some weirdness as the fullscreen window is tall and narrow.

More particularly, the new problem I've noticed is restricted to resize. Thinking back, I don't think the behavior of fullscreen has changed - it is as you describe it. I simply noticed the blender issue after the resize issue but I've seen this behavior with other apps. It never mattered because before I could resize the window to take up 90% of the two screens, which was my preferred pattern anyway. The behavior of No Machine is actually a bit comical with resize, even using the Alt-F8 trick, as it will appear to size correctly, wriggle itself a bit, then shake the new size off. I'm sorry I sounded so frustrated in my earlier email but since No Machine doesn't do it all the time - just 95% of the time - I got bitten when a window I thought was stably resized suddenly, making the machine on the other end effectively unusable through No Machine.

Jeff, if I get it working I'll let you know. I've looked at the code changes and it *seemed* relatively straighforward but I had build issues on the machines I have available to me. Since this is a problem I have on my work machine, if I can use a workaround (e.g., running No Machine on my laptop's monitor screen) I have to prioritize doing normal work to working with Compiz. However, if I get it running I will definitely send it to you.

Revision history for this message
Sam Spilsbury (smspillaz) wrote :

On Wed, Dec 8, 2010 at 3:06 AM, Anthony Francis
<email address hidden> wrote:
> Sam, thank you for your detailed response! I can see what you are saying
> about fullsizing something to multiple monitors. However, in the use
> case I have I'm using multiple portrait-oriented monitors to display a
> single desktop so that creates some weirdness as the fullscreen window
> is tall and narrow.
>
> More particularly, the new problem I've noticed is restricted to resize.
> Thinking back, I don't think the behavior of fullscreen has changed - it
> is as you describe it. I simply noticed the blender issue after the
> resize issue but I've seen this behavior with other apps. It never
> mattered because before I could resize the window to take up 90% of the
> two screens, which was my preferred pattern anyway. The behavior of No
> Machine is actually a bit comical with resize, even using the Alt-F8
> trick, as it will appear to size correctly, wriggle itself a bit, then
> shake the new size off.  I'm sorry I sounded so frustrated in my earlier
> email but since No Machine doesn't do it all the time - just 95% of the
> time - I got bitten when a window I thought was stably resized suddenly,
> making the machine on the other end effectively unusable through No
> Machine.

Fix committed upstream. The new behaviour is this:

Calculate possible resize area based on the area of the output between
panels and docks. If two outputs are next to each other *exactly* (eg,
no gap between them) and there is also no panel in the way, then the
possible resize area is expanded to the output. Also if a window was
already underneath a dock that dock is ignored when calculating
possible resize area.

>
> Jeff, if I get it working I'll let you know. I've looked at the code
> changes and it *seemed* relatively straighforward but I had build issues
> on the machines I have available to me. Since this is a problem I have
> on my work machine, if I can use a workaround (e.g., running No Machine
> on my laptop's monitor screen) I have to prioritize doing normal work to
> working with Compiz. However, if I get it running I will definitely send
> it to you.
>
> --
> 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
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to     : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help   : https://help.launchpad.net/ListHelp
>

--
Sam Spilsbury

Revision history for this message
Sam Spilsbury (smspillaz) wrote :

I forgot to mention, the upstream gnome bug report is here https://bugzilla.gnome.org/show_bug.cgi?id=636842

Revision history for this message
Sam Spilsbury (smspillaz) wrote :
Download full text (3.3 KiB)

On Thu, Dec 9, 2010 at 6:25 PM, Sam Spilsbury <email address hidden> wrote:
> On Wed, Dec 8, 2010 at 3:06 AM, Anthony Francis
> <email address hidden> wrote:
>> Sam, thank you for your detailed response! I can see what you are saying
>> about fullsizing something to multiple monitors. However, in the use
>> case I have I'm using multiple portrait-oriented monitors to display a
>> single desktop so that creates some weirdness as the fullscreen window
>> is tall and narrow.
>>
>> More particularly, the new problem I've noticed is restricted to resize.
>> Thinking back, I don't think the behavior of fullscreen has changed - it
>> is as you describe it. I simply noticed the blender issue after the
>> resize issue but I've seen this behavior with other apps. It never
>> mattered because before I could resize the window to take up 90% of the
>> two screens, which was my preferred pattern anyway. The behavior of No
>> Machine is actually a bit comical with resize, even using the Alt-F8
>> trick, as it will appear to size correctly, wriggle itself a bit, then
>> shake the new size off.  I'm sorry I sounded so frustrated in my earlier
>> email but since No Machine doesn't do it all the time - just 95% of the
>> time - I got bitten when a window I thought was stably resized suddenly,
>> making the machine on the other end effectively unusable through No
>> Machine.
>
> Fix committed upstream. The new behaviour is this:
>
> Calculate possible resize area based on the area of the output between
> panels and docks. If two outputs are next to each other *exactly* (eg,
> no gap between them) and there is also no panel in the way, then the
> possible resize area is expanded to the output. Also if a window was
> already underneath a dock that dock is ignored when calculating
> possible resize area.

Note that there is a bug with gnome-panel where if you have a panel on
the side of a screen where there is an adjacent screen then the panel
does not set the strut property correctly which causes all window
managers to ignore that panel. I have filed a bug upstream about this
[1]. This is visible if you put a panel on the right side of screen 1
and then have another screen on the right side of screen 1 and then
maximize a window on screen 1. The window will go underneath the panel
this happens with both metacity and compiz.

[1] https://bugzilla.gnome.org/show_bug.cgi?id=636842

>
>>
>> Jeff, if I get it working I'll let you know. I've looked at the code
>> changes and it *seemed* relatively straighforward but I had build issues
>> on the machines I have available to me. Since this is a problem I have
>> on my work machine, if I can use a workaround (e.g., running No Machine
>> on my laptop's monitor screen) I have to prioritize doing normal work to
>> working with Compiz. However, if I get it running I will definitely send
>> it to you.
>>
>> --
>> 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
>>
>> _______________________________________________
>> Mailing list: http...

Read more...

Changed in compiz (Ubuntu):
status: Confirmed → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package compiz - 1:0.9.2.1+glibmainloop3-0ubuntu1

---------------
compiz (1:0.9.2.1+glibmainloop3-0ubuntu1) natty; urgency=low

  * new glibmainloop branch snapshot:
    - fix launching an application set it to the wrong place (LP: #683273)
    - Can't resize windows to be displayed on several monitors (LP: #455378)
    - Scale All Windows gets its suffixes wrong for a 3x3 layout (LP: #683063)
    - Compiz sometimes loses focus when closing some windows (LP: #671459)
    - Fix hanging when session exit (LP: #683121)
  * debian/patches/000_fix_OOo_crash1.patch
    debian/patches/000_fix_OOo_crash2.patch
    debian/patches/001_fix_gconf_path.patch
    debian/patches/003_more_gconf_parser_fix.patch:
   - remove, upstreamed.
  * debian/patches/060_move_checks_to_compiz.patch:
    - adapt to new version
  * debian/patches/01_backport_trunk_fix.patch:
    - backport some additional fixes from trunk, otherwise compiz crash at start
  * debian/source_compiz.py:
    - fix gconf path
  * debian/compiz-gnome.gconf-defaults, debian/rules, debian/unity.ini,
    debian/patches/030_no_fade_in_staticswicher.patch:
    - change order to load fade before staticswichter to avoid the fade effect
      when alt + tabbing (LP: #683635)
    - add snap and workarounds by default as well
  * debian/compiz-gnome.gconf-defaults,
    debian/compiz-keybindings.sed,
    debian/patches/021_hide_tooltip_on_decorator.patch,
    debian/patches/057_update_gnome_bindings.patch:
    - update the gconf path from allscreens to screen0 as new gconf path in the
      gconf backend
  * debian/control:
    - handle the ABI breakage with other compiz components
 -- Didier Roche <email address hidden> Mon, 13 Dec 2010 16:38:10 +0100

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

Duplicates of this bug

Other bug subscribers

Remote bug watches

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