compiz team mailing list archive

["Sam \"SmSpillaz\" Spilsbury" <smspillaz@xxxxxxxxx>]

On Thu, Dec 9, 2010 at 6:25 PM, Sam Spilsbury <smspillaz@xxxxxxxxx> wrote:
> On Wed, Dec 8, 2010 at 3:06 AM, Anthony Francis
> <455378@xxxxxxxxxxxxxxxxxx> 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: https://launchpad.net/~compiz
>> Post to     : compiz@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~compiz
>> More help   : https://help.launchpad.net/ListHelp
>>
>
>
>
> --
> Sam Spilsbury
>


-- 
Sam Spilsbury

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