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