Switching away from and back to a tabbed workspace
Hey all,
Not sure if I'm the only one seeing this or not, but what I'm seeing
when I have a tabbed workspace, is that if I have >1 tab in the
workspace and I switch to another workspace that requires my current
workspace be hidden (so not resulting in a swap of two visual
workspaces), and then switch back to it, the visual presentation of
the tabs is some strange munge of the tab I had selected, and the tab
that had been viewing before I chose the currently selected one.
This behaviour doesn't seem to show up in the other default layouts
that I use such as tiled or full.
I'm using the following src checkouts,
xmonad
David Roundy
On Mon, Aug 27, 2007 at 09:42:05AM +1000, Dave Harrison wrote:
Hey all,
Not sure if I'm the only one seeing this or not, but what I'm seeing when I have a tabbed workspace, is that if I have >1 tab in the workspace and I switch to another workspace that requires my current workspace be hidden (so not resulting in a swap of two visual workspaces), and then switch back to it, the visual presentation of the tabs is some strange munge of the tab I had selected, and the tab that had been viewing before I chose the currently selected one.
I don't see this (obviously), and more detail is needed in order to make a guess as to how to reproduce it. How many screens do you have? If you use only one screen, does this show up? My best guess (given no information) is that this is a xinerama-related bug, since I only have one screen. But I'll definitely need more details if I'm to figure out what's going wrong. A screenshot might also be helpful. -- David Roundy http://www.darcs.net
David Roundy wrote:
On Mon, Aug 27, 2007 at 09:42:05AM +1000, Dave Harrison wrote:
Hey all,
Not sure if I'm the only one seeing this or not, but what I'm seeing when I have a tabbed workspace, is that if I have >1 tab in the workspace and I switch to another workspace that requires my current workspace be hidden (so not resulting in a swap of two visual workspaces), and then switch back to it, the visual presentation of the tabs is some strange munge of the tab I had selected, and the tab that had been viewing before I chose the currently selected one.
I don't see this (obviously), and more detail is needed in order to make a guess as to how to reproduce it. How many screens do you have? If you use only one screen, does this show up? My best guess (given no information) is that this is a xinerama-related bug, since I only have one screen. But I'll definitely need more details if I'm to figure out what's going wrong. A screenshot might also be helpful.
Hi David, I have two screens using Xinerama, since the second screen is the output adapter on my laptop I can't really turn it off so I can't speak for a single headed environment. I don't think a screenshot would help much, frequently I "see" the previous tab, but my input is going to the "active" tab. I have to cycle the tabs to get things back the way they should be. Any debug output etc I can provide ?? Cheers Dave
On Tue, Aug 28, 2007 at 09:44:35AM +1000, Dave Harrison wrote:
David Roundy wrote:
On Mon, Aug 27, 2007 at 09:42:05AM +1000, Dave Harrison wrote:
Hey all,
Not sure if I'm the only one seeing this or not, but what I'm seeing when I have a tabbed workspace, is that if I have >1 tab in the workspace and I switch to another workspace that requires my current workspace be hidden (so not resulting in a swap of two visual workspaces), and then switch back to it, the visual presentation of the tabs is some strange munge of the tab I had selected, and the tab that had been viewing before I chose the currently selected one.
I don't see this (obviously), and more detail is needed in order to make a guess as to how to reproduce it. How many screens do you have? If you use only one screen, does this show up? My best guess (given no information) is that this is a xinerama-related bug, since I only have one screen. But I'll definitely need more details if I'm to figure out what's going wrong. A screenshot might also be helpful.
Hi David,
I have two screens using Xinerama, since the second screen is the output adapter on my laptop I can't really turn it off so I can't speak for a single headed environment.
I don't think a screenshot would help much, frequently I "see" the previous tab, but my input is going to the "active" tab. I have to cycle the tabs to get things back the way they should be.
Any debug output etc I can provide ??
Hmmm. I don't know. Perhaps another developer, who has two screens could try to reproduce this? If you can give a specific sequence to trigger the bug, that would be great. e.g. if you could post a (preferably simple) Config.hs file, and directions such as: start up xmonad hit <insert key combo here> to bring up an xterm twice (so tabs are visible) switch to other head with mod-w ... This might even allow me to track this down using brain-power alone. -- David Roundy http://www.darcs.net
David Roundy wrote:
On Tue, Aug 28, 2007 at 09:44:35AM +1000, Dave Harrison wrote:
David Roundy wrote:
Hey all,
Not sure if I'm the only one seeing this or not, but what I'm seeing when I have a tabbed workspace, is that if I have >1 tab in the workspace and I switch to another workspace that requires my current workspace be hidden (so not resulting in a swap of two visual workspaces), and then switch back to it, the visual presentation of the tabs is some strange munge of the tab I had selected, and the tab that had been viewing before I chose the currently selected one. I don't see this (obviously), and more detail is needed in order to make a guess as to how to reproduce it. How many screens do you have? If you use only one screen, does this show up? My best guess (given no information) is
On Mon, Aug 27, 2007 at 09:42:05AM +1000, Dave Harrison wrote: that this is a xinerama-related bug, since I only have one screen. But I'll definitely need more details if I'm to figure out what's going wrong. A screenshot might also be helpful. Hi David,
I have two screens using Xinerama, since the second screen is the output adapter on my laptop I can't really turn it off so I can't speak for a single headed environment.
I don't think a screenshot would help much, frequently I "see" the previous tab, but my input is going to the "active" tab. I have to cycle the tabs to get things back the way they should be.
Any debug output etc I can provide ??
Hmmm. I don't know. Perhaps another developer, who has two screens could try to reproduce this? If you can give a specific sequence to trigger the bug, that would be great. e.g. if you could post a (preferably simple) Config.hs file, and directions such as:
start up xmonad hit <insert key combo here> to bring up an xterm twice (so tabs are visible) switch to other head with mod-w ...
This might even allow me to track this down using brain-power alone.
Hi David, A repeatable way I can make it misbehave is to, - Switch to an empty workspace - Open a firefox, an xterm, and an xterm of another color [ Put some stuff in each of those windows ] - Now switch to be on the "primary" window for the workspace - Now switch to another workspace that has something in it - Now switch back to the first workspace Hopefully you should now see "window pollution". Interestingly, this _only_ seems to happen to me (or at least just now as I was testing this) when I leave that workspace with focus on the primary window. The changed (ie. relevant) parts of my Config.hs are below. Cheers Dave --- % diff OrigConfig.hs Config.hs 31a32,35
import XMonadContrib.Tabbed import XMonadContrib.DynamicLog import XMonadContrib.Dmenu
89c93 < defaultLayouts = [ tiled , mirror tiled , full ] ---
defaultLayouts = [ tabbed shrinkText defaultTConf, tiled , mirror tiled , full ] 110c114 < logHook = return ()
logHook = dynamicLogXinerama 121,122c125,126 < [ ((modMask .|. shiftMask, xK_Return), spawn "xterm") -- @@ Launch an xterm < , ((modMask, xK_p ), spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\"") -- @@ Launch dmenu
[ ((modMask .|. shiftMask, xK_Return), spawn "urxvt -fn
\"xft:Monospace:pixelsize=15\" -sr") -- @@ Launch an xterm
, ((modMask, xK_p ), spawn "exe=`cat
/home/dave/.dmenulist | dmenu -b -p \"$\"` && eval \"exec $exe\"") -- @@ Launch dmenu 131a136
, ((modMask .|. shiftMask, xK_Tab ), focusUp) -- @@ Move focus
to the previous window 141,142c146,147 < , ((modMask, xK_h ), sendMessage Shrink) -- @@ Shrink the master area < , ((modMask, xK_l ), sendMessage Expand) -- @@ Expand the master area ---
, ((modMask, xK_Left ), sendMessage Shrink) --
@@ Shrink the master area
, ((modMask, xK_Right ), sendMessage Expand) --
@@ Expand the master area 168c173 < | (key, sc) <- zip [xK_w, xK_e, xK_r] [0..] ---
| (key, sc) <- zip [xK_l, xK_h, xK_r] [0..]
On Wed, Aug 29, 2007 at 08:37:59PM +1000, Dave Harrison wrote:
Hi David,
A repeatable way I can make it misbehave is to,
- Switch to an empty workspace - Open a firefox, an xterm, and an xterm of another color [ Put some stuff in each of those windows ] - Now switch to be on the "primary" window for the workspace - Now switch to another workspace that has something in it - Now switch back to the first workspace
Hopefully you should now see "window pollution". Interestingly, this _only_ seems to happen to me (or at least just now as I was testing this) when I leave that workspace with focus on the primary window.
The changed (ie. relevant) parts of my Config.hs are below.
Alas, I still haven't been able to reproduce this, and I don't see anything suggestive in your Config. :( Sorry! -- David Roundy http://www.darcs.net
Dave Harrison wrote:
Not sure if I'm the only one seeing this or not, but what I'm seeing when I have a tabbed workspace, is that if I have >1 tab in the workspace and I switch to another workspace that requires my current workspace be hidden (so not resulting in a swap of two visual workspaces), and then switch back to it, the visual presentation of the tabs is some strange munge of the tab I had selected, and the tab that had been viewing before I chose the currently selected one.
This behaviour doesn't seem to show up in the other default layouts that I use such as tiled or full.
Hey all, At the moment, I haven't been able to resolve the above issue, but I have managed to capture some screenshots of the bug in action. The screenshots can be seen at these URLs: These two are the tabs as they look when viewed (correct): http://www.nullcube.com/xmonad/XmonadTabbed_Tab1.png http://www.nullcube.com/xmonad/XmonadTabbed_Tab2.png This is what happens after I switch away, and then back (buggy) : http://www.nullcube.com/xmonad/XmonadTabbed_Munged.png Help ? Cheers Dave
On Thursday 30 August 2007 19:12:45 Dave Harrison wrote:
Dave Harrison wrote:
Not sure if I'm the only one seeing this or not, but what I'm seeing when I have a tabbed workspace, is that if I have >1 tab in the workspace and I switch to another workspace that requires my current workspace be hidden (so not resulting in a swap of two visual workspaces), and then switch back to it, the visual presentation of the tabs is some strange munge of the tab I had selected, and the tab that had been viewing before I chose the currently selected one.
This behaviour doesn't seem to show up in the other default layouts that I use such as tiled or full.
Hey all,
At the moment, I haven't been able to resolve the above issue, but I have managed to capture some screenshots of the bug in action. The screenshots can be seen at these URLs:
These two are the tabs as they look when viewed (correct):
http://www.nullcube.com/xmonad/XmonadTabbed_Tab1.png http://www.nullcube.com/xmonad/XmonadTabbed_Tab2.png
This is what happens after I switch away, and then back (buggy) :
http://www.nullcube.com/xmonad/XmonadTabbed_Munged.png
Help ?
Cheers Dave _______________________________________________ Xmonad mailing list Xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
Ah, so the contents of the *windows* are scrambled, not the tabs themselves. In this example, which window is supposed to have keyboard focus? Which window actually receives keyboard input? Does mod-n have any effect on these scrambled windows? Cheers, Spencer Janssen
Spencer Janssen wrote:
On Thursday 30 August 2007 19:12:45 Dave Harrison wrote:
Dave Harrison wrote:
Not sure if I'm the only one seeing this or not, but what I'm seeing when I have a tabbed workspace, is that if I have >1 tab in the workspace and I switch to another workspace that requires my current workspace be hidden (so not resulting in a swap of two visual workspaces), and then switch back to it, the visual presentation of the tabs is some strange munge of the tab I had selected, and the tab that had been viewing before I chose the currently selected one.
This behaviour doesn't seem to show up in the other default layouts that I use such as tiled or full. Hey all,
At the moment, I haven't been able to resolve the above issue, but I have managed to capture some screenshots of the bug in action. The screenshots can be seen at these URLs:
These two are the tabs as they look when viewed (correct):
http://www.nullcube.com/xmonad/XmonadTabbed_Tab1.png http://www.nullcube.com/xmonad/XmonadTabbed_Tab2.png
This is what happens after I switch away, and then back (buggy) :
http://www.nullcube.com/xmonad/XmonadTabbed_Munged.png
Help ?
Cheers Dave
Ah, so the contents of the *windows* are scrambled, not the tabs themselves. In this example, which window is supposed to have keyboard focus? Which window actually receives keyboard input? Does mod-n have any effect on these scrambled windows?
The vim window (far left) is meant to have focus, and it does have keyboard focus, it's just that the window image (so to speak) is scrambled - as I type, the stuff I'm typing appears where it should too, but the rest of the page remains scrambled until I alt-tab cycle the windows. mod-n has no effect, and I have seen this behaviour with other apps such as Gaim and Skype that I immediately remember - I'm pretty sure I've seen it happen with most of my apps.
Dave Harrison wrote:
Spencer Janssen wrote:
On Thursday 30 August 2007 19:12:45 Dave Harrison wrote:
Dave Harrison wrote:
Not sure if I'm the only one seeing this or not, but what I'm seeing when I have a tabbed workspace, is that if I have >1 tab in the workspace and I switch to another workspace that requires my current workspace be hidden (so not resulting in a swap of two visual workspaces), and then switch back to it, the visual presentation of the tabs is some strange munge of the tab I had selected, and the tab that had been viewing before I chose the currently selected one.
This behaviour doesn't seem to show up in the other default layouts that I use such as tiled or full. Hey all,
At the moment, I haven't been able to resolve the above issue, but I have managed to capture some screenshots of the bug in action. The screenshots can be seen at these URLs:
These two are the tabs as they look when viewed (correct):
http://www.nullcube.com/xmonad/XmonadTabbed_Tab1.png http://www.nullcube.com/xmonad/XmonadTabbed_Tab2.png
This is what happens after I switch away, and then back (buggy) :
http://www.nullcube.com/xmonad/XmonadTabbed_Munged.png
Help ?
Cheers Dave Ah, so the contents of the *windows* are scrambled, not the tabs themselves. In this example, which window is supposed to have keyboard focus? Which window actually receives keyboard input? Does mod-n have any effect on these scrambled windows?
The vim window (far left) is meant to have focus, and it does have keyboard focus, it's just that the window image (so to speak) is scrambled - as I type, the stuff I'm typing appears where it should too, but the rest of the page remains scrambled until I alt-tab cycle the windows.
mod-n has no effect, and I have seen this behaviour with other apps such as Gaim and Skype that I immediately remember - I'm pretty sure I've seen it happen with most of my apps.
Hi all, Interestingly, I _think_ I might have isolated the problem to urxvt. I've been unable to trigger the problem when I use konsole instead of urxvt despite many many attempts using the same behaviours that cause the weirdness when I'm using urxvt. Has anyone else seen strange behaviour with urxvt ? Cheers Dave
On Thu, Sep 13, 2007 at 08:40:46PM +1000, Dave Harrison wrote:
Interestingly, I _think_ I might have isolated the problem to urxvt. I've been unable to trigger the problem when I use konsole instead of urxvt despite many many attempts using the same behaviours that cause the weirdness when I'm using urxvt.
I haven't looked at the screenshots, but I also observe that urxvt windows contain "garbage" below the last line, if the window height is not a multiple of the line height. (For example, when opening a new urxvt window, the old master window might be pushed to the right column and made smaller. At that time, below the last line I might see output from the previous, larger, content. Ctrl-L does not fix this. But switching to another workspace and back does.) This is using the normal tiled layout, not with the tabbed layout. Kai
On Thursday 30 August 2007 19:12:45 Dave Harrison wrote:
Dave Harrison wrote:
Not sure if I'm the only one seeing this or not, but what I'm seeing when I have a tabbed workspace, is that if I have >1 tab in the workspace and I switch to another workspace that requires my current workspace be hidden (so not resulting in a swap of two visual workspaces), and then switch back to it, the visual presentation of the tabs is some strange munge of the tab I had selected, and the tab that had been viewing before I chose the currently selected one.
This behaviour doesn't seem to show up in the other default layouts that I use such as tiled or full.
Hey all,
At the moment, I haven't been able to resolve the above issue, but I have managed to capture some screenshots of the bug in action. The screenshots can be seen at these URLs:
These two are the tabs as they look when viewed (correct):
http://www.nullcube.com/xmonad/XmonadTabbed_Tab1.png http://www.nullcube.com/xmonad/XmonadTabbed_Tab2.png
This is what happens after I switch away, and then back (buggy) :
http://www.nullcube.com/xmonad/XmonadTabbed_Munged.png
Help ?
Cheers Dave _______________________________________________ Xmonad mailing list Xmonad@haskell.org http://www.haskell.org/mailman/listinfo/xmonad
One more thing: does this window munging happen with xterms only, or do other clients have this problem too?
participants (4)
-
Dave Harrison -
David Roundy -
Kai Grossjohann -
Spencer Janssen