Issue 168 in xmonad: gnome-panel with autohide enabled appears behind main windows

Issue 168: gnome-panel with autohide enabled appears behind main windows http://code.google.com/p/xmonad/issues/detail?id=168 Comment #1 by gwern0: Just to add a comment: I can reproduce this in darcs XMonad, Ubuntu Hardy Heron, using ManageDocks as well (see my xmonad.hs). This bug is kind of annoying, since autohide is the best way to save gnome-panel wasted space (once you've consolidated into a single panel and have shrunk it down as much as possible), even if you can work around it by going to an empty workspace. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org wrote:
Issue 168: gnome-panel with autohide enabled appears behind main windows http://code.google.com/p/xmonad/issues/detail?id=168
Comment #1 by gwern0: Just to add a comment: I can reproduce this in darcs XMonad, Ubuntu Hardy Heron, using ManageDocks as well (see my xmonad.hs).
This bug is kind of annoying, since autohide is the best way to save gnome-panel wasted space (once you've consolidated into a single panel and have shrunk it down as much as possible), even if you can work around it by going to an empty workspace.
I've attached a fix, it keeps struts at the top of the stacking order all the time. Tested in gnome.

Thanks for that! (Not yet tested by me, but this has been a minor gripe of mine.) Groetjes, <>< Marnix -- Marnix Klooster | Software Engineer, ERP LN Enterprise Server | Infor | (+31 or 0)342-428511 | marnix.klooster@infor.com | Infor Global Solutions (Barneveld) BV | P.O. box 143 | 3770 AC Barneveld | The Netherlands REGISTER NOW! | Inforum 2008 | The Venetian Hotel and Sands Expo | Las Vegas | October 14 - 16 | http://www.inforum2008.com
-----Original Message----- From: xmonad-bounces@haskell.org [mailto:xmonad-bounces@haskell.org] On Behalf Of Justin Bogner Sent: Thursday, 26 June, 2008 22:12 To: xmonad@haskell.org Subject: [xmonad] Re: Issue 168 in xmonad: gnome-panel with autohide enabled appears behind main windows
Issue 168: gnome-panel with autohide enabled appears behind
codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org wrote: main windows
http://code.google.com/p/xmonad/issues/detail?id=168
Comment #1 by gwern0: Just to add a comment: I can reproduce this in darcs XMonad, Ubuntu Hardy Heron, using ManageDocks as well (see my xmonad.hs).
This bug is kind of annoying, since autohide is the best way to save gnome-panel wasted space (once you've consolidated into a single panel and have shrunk it down as much as possible), even if you can work around it by going to an empty workspace.
I've attached a fix, it keeps struts at the top of the stacking order all the time. Tested in gnome.

Justin Bogner wrote:
codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org wrote:
Issue 168: gnome-panel with autohide enabled appears behind main windows http://code.google.com/p/xmonad/issues/detail?id=168
Comment #1 by gwern0: Just to add a comment: I can reproduce this in darcs XMonad, Ubuntu Hardy Heron, using ManageDocks as well (see my xmonad.hs).
This bug is kind of annoying, since autohide is the best way to save gnome-panel wasted space (once you've consolidated into a single panel and have shrunk it down as much as possible), even if you can work around it by going to an empty workspace.
I've attached a fix, it keeps struts at the top of the stacking order all the time. Tested in gnome.
Don't apply this, it thoroughly breaks toggleStruts.

Justin Bogner wrote:
codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org wrote:
Issue 168: gnome-panel with autohide enabled appears behind main windows http://code.google.com/p/xmonad/issues/detail?id=168
Comment #1 by gwern0: Just to add a comment: I can reproduce this in darcs XMonad, Ubuntu Hardy Heron, using ManageDocks as well (see my xmonad.hs).
This bug is kind of annoying, since autohide is the best way to save gnome-panel wasted space (once you've consolidated into a single panel and have shrunk it down as much as possible), even if you can work around it by going to an empty workspace.
I've attached a fix, it keeps struts at the top of the stacking order all the time. Tested in gnome.
I've come up with another fix, which hides (ie, unmaps the window of) any struts that its not avoiding as well as keeping struts on the very top. Doing it this way allows the gnome panel with autohide and without autohide to work sanely. Unfortunately, this makes the AvoidStrutsOn variant of AvoidStruts behave very predictably wrong (though I'm not really sure why someone would want to avoid struts in only certain directions...). I think the proper approach to fixing this is to have three states, instead of two. That is, Avoid, Hide, and Ignore --- but nobody would ever want to toggle between all three, you'd probably want to ignore some and toggle between avoid and hide. To make something like that work, I would presumably add the list of struts to hide to AvoidStruts' state, which would, as a bonus, make the module more efficient. Does anyone use AvoidStrutsOn? I'd like to hear some use cases for its existence... -- Justin Bogner

Justin Bogner wrote:
Justin Bogner wrote:
codesite-noreply-hpIqsD4AKlfQT0dZR+AlfA-XMD5yJDbdMReXY1tMh2IBg@public.gmane.org wrote:
Issue 168: gnome-panel with autohide enabled appears behind main windows http://code.google.com/p/xmonad/issues/detail?id=168
Comment #1 by gwern0: Just to add a comment: I can reproduce this in darcs XMonad, Ubuntu Hardy Heron, using ManageDocks as well (see my xmonad.hs).
This bug is kind of annoying, since autohide is the best way to save gnome-panel wasted space (once you've consolidated into a single panel and have shrunk it down as much as possible), even if you can work around it by going to an empty workspace.
I've attached a fix, it keeps struts at the top of the stacking order all the time. Tested in gnome.
I've come up with another fix, which hides (ie, unmaps the window of) any struts that its not avoiding as well as keeping struts on the very top. Doing it this way allows the gnome panel with autohide and without autohide to work sanely.
Unfortunately, this makes the AvoidStrutsOn variant of AvoidStruts behave very predictably wrong (though I'm not really sure why someone would want to avoid struts in only certain directions...).
I think the proper approach to fixing this is to have three states, instead of two. That is, Avoid, Hide, and Ignore --- but nobody would ever want to toggle between all three, you'd probably want to ignore some and toggle between avoid and hide.
To make something like that work, I would presumably add the list of struts to hide to AvoidStruts' state, which would, as a bonus, make the module more efficient.
Does anyone use AvoidStrutsOn? I'd like to hear some use cases for its existence...
Just want to bump this thread. It appears from some IRC discussionn that AvoidStrutsOn is indeed used by some people, so a fix that allows it to work too would be desirable. a-9 was asking about this on IRC, so I just thought I'd bump this thread to keep this alive. Also, the patch(es) should probably be uploaded to the bug tracker, so we don't lose them in the mists. Braden Shepherdson shepheb

On Thu, Jul 03, 2008 at 05:27:40PM -0600, Justin Bogner wrote:
I think the proper approach to fixing this is to have three states, instead of two. That is, Avoid, Hide, and Ignore --- but nobody would ever want to toggle between all three, you'd probably want to ignore some and toggle between avoid and hide.
What happened to this idea? Is it hard to do?

Devin Mullins wrote:
On Thu, Jul 03, 2008 at 05:27:40PM -0600, Justin Bogner wrote:
I think the proper approach to fixing this is to have three states, instead of two. That is, Avoid, Hide, and Ignore --- but nobody would ever want to toggle between all three, you'd probably want to ignore some and toggle between avoid and hide.
What happened to this idea? Is it hard to do?
I wouldn't say it's hard to do, but I'm not entirely certain how it should work. Please take a look at the patches I sent to the bug tracker and give some feedback if possible.
participants (5)
-
Braden Shepherdson
-
codesite-noreply@google.com
-
Devin Mullins
-
Justin Bogner
-
Marnix Klooster