Ubuntu
metacity package

Maximizing ignores docked panles with Xinerama

Bug #58977 reported by Haggai Eran
132
This bug affects 22 people
Affects Status Importance Assigned to Milestone
Metacity
Fix Released
Low
compiz (Ubuntu)
Fix Released
Undecided
Unassigned
kdebase-workspace (Ubuntu)
Invalid
Undecided
Unassigned
metacity (Debian)
Fix Released
Unknown
metacity (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: metacity

Hi
When I add another screen using Xinerama, the gnome panels remain in the first screen, which is great, but when the panel is aligned vertically near the border between the two screens (either on the right of the left screen, or on the left of the right screen), maximizing a window ignores the panel, and the window is maximized right to the edge of the screen.

Steps to reproduce:
1. Use xinerama with the second screen to the right of the first.
2. Add a vertical gnome panel to the right edge of the left screen.
3. maximize a window in the left screen.
4. The screen is maximized right to the edge of the screen, instead of the edge of the panel.

Tags: xinerama
Revision history for this message
In , Antoinecailliau (antoinecailliau) wrote :

On maximize, the window should be stopped along the panel as when the panel is
on the top

Other information:
I attached a screenshot of the bug.

Revision history for this message
In , Antoinecailliau (antoinecailliau) wrote :

Created attachment 64267
Screenshot

Revision history for this message
In , Sergej Kotliar (sigge) wrote :

Ah, so you mean that the X icon is hidden... strange...

Can't reproduce it here, have been using a right-side panel since forever, and never seen that...

Are you using metacity window manager? (the default one installed)
If you try to move the panel somewhere else, and then put it back, does this bug appear again?

Revision history for this message
In , Antoinecailliau (antoinecailliau) wrote :

Yes i'm using the default window manager, Metacity.

When I move the panel somewhere and then put it back, the bug appear again, nothing changed.

I've dual screen and the bug appear when the panel is in the "middle" of the both screen, there is no bug when the panel is on the right of the right screen, sorry never think that it could be that.

Revision history for this message
In , Sergej Kotliar (sigge) wrote :

Yeah, I think that's the cause of it then. Retitling the bug. Don't have two screens, so I'll let someone else confirm this one.

Revision history for this message
In , Elijah (newren) wrote :

The EWMH provides no way to reserve any area of the screen except the portion at the edges. (Note that in a xinerama setup, there is only one "screen" which spans both monitors, so that rules out reserving the area this bug report talks about) So, the panel can't tell metacity that this area is reserved. metacity-2.14.x does have most of the code necessary to handle reserved area that isn't at screen edges, but not quite all of it. So three bugs:
  1) EWMH needs to be extended to handle xinerama edges too
  2) Metacity needs to support the new hints
  3) gnome-panel needs to use the new hints

EWMH is first, so I'll move to metacity for now and try to remember to bring this up on wm-spec-list at some point.

Revision history for this message
In , Antoinecailliau (antoinecailliau) wrote :

Ok, tanks for the information, I'll try to follow my bug ^^

Bug Watch Updater (bug-watch-updater)
Changed in metacity:
status: Unknown → Confirmed
Revision history for this message
In , Sebastien Bacher (seb128) wrote :

Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/metacity/+bug/58977

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thanks for your bug. What version of Ubuntu do you use? Has pointed by Elijah that's known upstream as http://bugzilla.gnome.org/show_bug.cgi?id=339692

Changed in metacity:
assignee: nobody → desktop-bugs
importance: Untriaged → Low
status: Unconfirmed → Confirmed
Revision history for this message
Haggai Eran (haggai-eran) wrote : Re: [Bug 58977] Re: Maximizing ignores docked panles with Xinerama

thanks, I'm using ubuntu dapper.

Haggai

On 9/10/06, Sebastien Bacher <email address hidden> wrote:
> Thanks for your bug. What version of Ubuntu do you use? Has pointed by
> Elijah that's known upstream as
> http://bugzilla.gnome.org/show_bug.cgi?id=339692
>
> ** Bug watch removed: GNOME Bug Tracker #http://bugzilla.gnome.org/show_bug.cgi?id=339692
> http://bugzilla.gnome.org/show_bug.cgi?id=http://bugzilla.gnome.org/show_bug.cgi?id=339692
>
> ** Bug watch added: GNOME Bug Tracker #339692
> http://bugzilla.gnome.org/show_bug.cgi?id=339692
>
> ** Changed in: metacity (Ubuntu)
> Importance: Untriaged => Low
> Assignee: (unassigned) => Ubuntu Desktop Bugs
> Status: Unconfirmed => Confirmed
>
> --
> Maximizing ignores docked panles with Xinerama
> https://launchpad.net/bugs/58977
>

--
Haggai Eran

Revision history for this message
In , Elijah (newren) wrote :

*** Bug 420626 has been marked as a duplicate of this bug. ***

Revision history for this message
Adam Bolte (boltronics) wrote :

I believe I am also experiencing this bug. I use two monitors using Xinerama, however they are positioned one on top of the other in a vertical layout.

When I have my GNOME Panel at the top of the bottom monitor, maximising a window on the bottom monitor hides the window titlebar behind the panel.

However, when I move the GNOME Panel to the top of the top monitor, maximising a window on the top monitor does not extend the window behind the GNOME panel.

I'm using Ubuntu Feisty, and have found reference to this bug on the GNOME website also:
http://bugzilla.gnome.org/show_bug.cgi?id=339692

Revision history for this message
In , Marnanel Thurman (marnanel) wrote :

*** Bug 520713 has been marked as a duplicate of this bug. ***

Revision history for this message
In , 0-marco (0-marco) wrote :

*** Bug 527547 has been marked as a duplicate of this bug. ***

Revision history for this message
elleP (pelle-quicknet) wrote :

Could https://bugs.launchpad.net/metacity/+bug/120818 be a duplicate of this?

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

yeh I'm seeing what sounds like the same as both of these;

two monitors stacked vertically; panels at the top and bottom of the top screen and bottom of the bottom screen.
If I hit maximize on a window on the top screen it is partially hidden by the bottom panel on the top screen.

This is on Interpid's beta as of today; metacity 1:2.24.0-0ubuntu1 with GL desktop off.

Dave

Revision history for this message
In , Gnome-2 (gnome-2) wrote :

I wonder if this can be solved in the restricted case of n-monitors in line without changing anything except the STRUT_PARTIAL hint set by the panel.

In my case I have two monitors stacked vertically (as far as X thinks); with a panel at the top of the top monitor, another at the bottom of the bottom monitor
and the troublesome one which is at the bottom of the top monitor.

If that 3rd one was said to be a strut on the left, and said it was as wide
as the monitor but it's start and end 'y' corresponded to it's top and bottom would that work?

As it is the STRUT_PARTIAL value on the middle panel looks meaningless:

_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1919
_NET_WM_STRUT(CARDINAL) = 0, 0, 0, 0

(Top monitor is 1920x1080).

It wouldn't cure everyone, but it should sort most users out.

Would metacity cope with that?

Revision history for this message
In , Gnome-2 (gnome-2) wrote :

Created attachment 127673
Hack for the vertical case - for comment

This is a hack to gnome-panel that addresses the case of monitors in a vertical stack and a panel at the bottom of the not-bottom monitor;
this hack seems to work with metacity - it would be easy to generalise to the other edges.

What do people think - sure it's not a full answer - and I don't know what other window managers would make of it?

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

I've attached a hack/patch to gnome-panel for the bottom/vertical case of this to the gnome bug here:

http://bugzilla.gnome.org/attachment.cgi?id=127673&action=view

It's a nasty hack but it seems to work for the case I covered.

Dave

Revision history for this message
In , Gnome-2 (gnome-2) wrote :

Just a word of warning; while plain metacity is OK with this, compiz doesn't like it. (It puts everything at the side).

Revision history for this message
Conan (richard-connon) wrote :

I have the same problem with my screen setup:
1024x768+0+357
1680x1050+1024+75
1920x1200+2704+0
1280x1024+4624+0

It appears to be that more generally: maximising ignores any panel which is not at the extreme top, bottom, left or right of the entire virtual display.

Revision history for this message
Nick A (nickalleyne) wrote :

This affects me also.
It also does it with twinview which I was using previously to upgrading to Jaunty.

I agree with what Conan posted above, any non-extreme edge panel is ignored from my experience.

I am using a Dell D630 laptop with the main screen being the bottom.

I have attached a screenshot.

Revision history for this message
Conan (richard-connon) wrote :

Recent testing with all current updates suggests that for horizontal panels (that is ones at the top or bottom of a monitor) this bug only now occurs if the panel was put there since logon time.
Luckily this means that there is now at least a workaround for this bug (create and position all your panels, log off, log on, run other applications)

Revision history for this message
Nick A (nickalleyne) wrote :

really? that does not change it for me, I just restarted and it still does the same as in my screenshot above.

Revision history for this message
Conan (richard-connon) wrote :

Ah... I'm not actually using vertically stacked monitors. I just have some horizontal ones which aren't at the top or bottom extremes of the virtual desktop.

Seems this is more of an issue if there is another display above or below the panel in question...

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

Still does it on jaunty up to date as of today - note that a different change has caused some of the panels to move around.

Dave

Revision history for this message
In , 1nomdeplume (1nomdeplume) wrote :

(In reply to comment #12)
> Created an attachment (id=127673) [details]
> Hack for the vertical case - for comment
>
> This is a hack to gnome-panel that addresses the case of monitors in a vertical
> stack and a panel at the bottom of the not-bottom monitor;
> this hack seems to work with metacity - it would be easy to generalise to the
> other edges.
>
> What do people think - sure it's not a full answer - and I don't know what
> other window managers would make of it?

I've tried the patch and windows maximize correctly now. I don't use compiz because it breaks with the intel driver in Fedora. The patch header had to be tweaked to build with the Fedora source rpm.

Revision history for this message
Christian Stöveken (excogitation) wrote :

Problem still persists on Karmic.

Pedro Villavicencio (pedro)
Changed in metacity (Ubuntu):
status: Confirmed → Triaged
Revision history for this message
Roland Neary (abcccc) wrote :

Problem still persists on Lucid.

Bug Watch Updater (bug-watch-updater)
Changed in metacity (Debian):
status: Unknown → Confirmed
Bug Watch Updater (bug-watch-updater)
Changed in metacity:
importance: Unknown → Low
Revision history for this message
Olivier Berger (olivierberger) wrote :

Hi.
Note that https://bugzilla.gnome.org/show_bug.cgi?id=583538 also seems related to that issue.

Revision history for this message
Helge Willum Thingvad (helgesdk) wrote :

I can also confirm this bug in Lucid.
LVDS: 1280x800
VGA: 1280x1024

Placing the monitors horizontally gives me a "deadzone" on LVDS because of the difference in resolution (see https://bugs.launchpad.net/ubuntu/+source/libxrandr/+bug/373367).

Placing the monitors vertically causes maximized windows to overlap one of the horizontal panels.

Revision history for this message
Jakob Unterwurzacher (jakobunt) wrote :

Also in compiz: http://ubuntuforums.org/showthread.php?p=10229694#post10229694
Also in kwin: http://newyork.ubuntuforums.org/showthread.php?t=1632382

Revision history for this message
Sam Spilsbury (smspillaz) wrote : Re: [Compiz] [Bug 58977] Re: Maximizing ignores docked panles with Xinerama

Known issue in the panel.

On 12/12/10, Jakob Unterwurzacher <email address hidden> wrote:
> ** Also affects: compiz (Ubuntu)
> Importance: Undecided
> Status: New
>
> --
> 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/58977
>
> Title:
> Maximizing ignores docked panles with Xinerama
>
> _______________________________________________
> Mailing list: https://launchpad.net/~compiz
> Post to : <email address hidden>
> Unsubscribe : https://launchpad.net/~compiz
> More help : https://help.launchpad.net/ListHelp
>

--
Sent from my mobile device

Sam Spilsbury

Revision history for this message
Michel Filipe (mfilipe) wrote :

I find out a workaround but I'm using TwinView.

See: https://bugs.launchpad.net/ubuntu/+source/gnome-panel/+bug/375503/comments/10

Revision history for this message
Aaron Masover (amasover) wrote :

Do Compiz and Kwin need separate bugs filed against them?

Revision history for this message
Aaron Masover (amasover) wrote :

Nevermind, forgive my noob comment :)

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

The bug is in gnome-panel actually

Revision history for this message
Dave Gilbert (ubuntu-treblig) wrote :

It's more complicated than that; as I remember (from a couple of years ago when I posted the patch in #6 above) there are limitations in the 'strut' notification where a window tells the window manager to avoid an area; it can't really cope with an arbitrary area in the middle of the screen. So really it's a standardisation issue that the wm and panel need to understand; although heck knows if any of that has changed in the last couple of years.

Dave

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

On Sun, Jan 30, 2011 at 10:27 PM, Dave Gilbert <email address hidden> wrote:
> It's more complicated than that; as I remember (from a couple of years
> ago when I posted the patch in #6 above) there are limitations in the
> 'strut' notification where a window tells the window manager to avoid an
> area; it can't really cope with an arbitrary area in the middle of the
> screen.  So really it's a standardisation issue that the wm and panel
> need to understand; although heck knows if any of that has changed in
> the last couple of years.

My understanding of the specification is that the strut notification
just says "avoid this area of the screen" as defined by
_NET_WM_STRUT_PARTIAL (since that allows you to specify the full
extents of the strut) [1]. So in that case the window manager should
not use that area for placement OR maximization. Of course, things get
tricky when you start considering snap-to, but I think in that case it
is reasonable to ignore the snap-to case where a strut does not share
an edge of the screen.

Both Compiz, Docky and Avant Window Navigator seem to follow this
mantra of doing things - the strut is set perfectly fine if you make
Docky adjacent to another screen edge.

Of course, the specification makes it clear that struts are only to be
used on screen edges and makes it doubly as clear that struts are not
to be reserved at the edge of Xinerama screens, but I haven't seen any
problems with allowing this. If you can point me to the discussion in
light of this bug, that would be much appreciated.

[1] http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html

>
> Dave
>
> --
> 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/58977
>
> Title:
>  Maximizing ignores docked panles with Xinerama
>
> _______________________________________________
> 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
AmenophisIII (amenophisiii) wrote :

unsurprisingly in maverick/10.10 the problem persists.

Launchpad Janitor (janitor)
Changed in compiz (Ubuntu):
status: New → Confirmed
Changed in kdebase-workspace (Ubuntu):
status: New → Confirmed
Sam Spilsbury (smspillaz)
Changed in compiz (Ubuntu):
status: Confirmed → Fix Committed
Revision history for this message
Olivier Berger (olivierberger) wrote :

Care to elaborate on what was fixed/how/where (version) regarding compiz in ubuntu ?

Revision history for this message
Harald Sitter (apachelogger) wrote :

Please report at bugs.kde.org.

Changed in kdebase-workspace (Ubuntu):
status: Confirmed → Invalid
Revision history for this message
Daniel van Vugt (vanvugt) wrote :

Sam, could you clarify the status of this bug?

Revision history for this message
Ilkka Pohlainen (ilkka-pohjalainen) wrote :

This is still an issue in gnome-panel 3.8.0 while using Ubuntu 13.04 fallback mode.

Alberts Muktupāvels (muktupavels)
Changed in compiz (Ubuntu):
status: Fix Committed → Confirmed
Bug Watch Updater (bug-watch-updater)
Changed in metacity (Debian):
status: Confirmed → Fix Released
Revision history for this message
Dmitry Shachnev (mitya57) wrote :

This is now fixed in both Metacity and Compiz, but it will require also changes in gnome-panel and GTK.

Changed in metacity:
importance: Low → Unknown
status: Confirmed → Unknown
Changed in metacity (Ubuntu):
status: Triaged → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in metacity:
importance: Unknown → Low
status: Unknown → Fix Released
Alberts Muktupāvels (muktupavels)
Changed in compiz (Ubuntu):
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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