black/dead space problem in terminal windows in tiling window managers

mkoco · 03-17-2010, 12:45 AM

Hi all,

I've been playing around with two tiling window managers, scrotwm, and xmonad. I like xmonad better, but that's not the point. The point is that they both produce these strange black bars at the bottom when a terminal window is opened. note that this does not happen in fluxbox/openbox, my other wm.

its hard to explain, so please see the screenshots below:

http://snowpine.net/images/exhibita.png
http://snowpine.net/images/exhibitb.png
http://snowpine.net/images/exhibitc.png

Note the black bar, or just dead at space the bottom of the the terminal windows. In the third image, the prompt is at the "bottom" of the window, or what should be.

Again, this only happens in scrotwm and xmondad, no other wm's I've tested.

Any idea what could be causing that?

GrapefruiTgirl · 03-17-2010, 12:53 AM

Based on my experience using i3 tiling WM, I seem to have discovered that it is caused by having a background color set to something other than the black default (it still happens when it's black, you just can't see it).

If you use your mouse, and sloooowly resize the terminal window from the lower right corner (note: the window needs to be floating for this to work), you may see that the 'dead area' gets only as wide/high as your font is, in pixels, and then at just the right moment, when your terminal exactly corresponds in size to an exact number of characters in lengthxheight, there is no dead area., Then, when you enlarge it again by one or two pixels, there will be a dead area again, which is part-of-one-character in width.

Does this describe how it behaves for you?

For me, this is the case in `xterm` where I have set a white background -- I get a black dead area if the terminal window is not exactly xx characters wide/high.

If you are finding a slightly different dead area on the right/left side, which does NOT seem to be font related, it may be that you have not told the terminal to make the scrollbar size=0px -- even with the scrollbar disabled, some terminal emulators still leave a scroll-bar width of uselessness, unless you tell it to make it 0 pixels.

Hope this sheds some light

but if not, do tell!

Sasha

mkoco · 03-17-2010, 01:13 AM

Sasha, thanks, at least I'm not the only one experiencing this weirdness!

For me, as soon as I float the window, the dead space disappears. Its always on the bottom, and somewhat variable in size. I've attached a another screen shot showing another variation of this issue:

http://snowpine.net/images/exhibitd.png

Sometimes parts of the previous screen buffer get caught in the dead space.

I am using urxvt, but the problem is the same with xterm and aterm as well.

T3slider · 03-17-2010, 01:18 AM

In xmonad I think you can use the hinted layout to add space under the terminal if there is less than a full row at the bottom (it just shortens the window while keeping it tiled, so you see a bit of your background). This is a shortfall of the terminal but how it is displayed is partly the fault of the WM. I use xmonad as well and I just don't care enough to fix it, but you can either investigate the terminal that you use to see if there is an option to hide that if there is a buffer at the bottom, or fix it in your WM (though this will pad the bottom, as said above).

For xmonad check out the XMonad.Layout.LayoutHints module (contrib) or use one of the other contrib modules that are hinted already (like XMonad.Layout.HintedTile). Good luck.

GrapefruiTgirl · 03-17-2010, 01:21 AM

Hmm, that screenshot shows what I believe is not the exact same issue that I experience.. Looks similar at first, but I do not get any left-over text or screen buffer in my dead space; only a lack of background color it seems, and for me, it's definitely corresponding to the pixel-size of my font characters..

Does it manifest identically with either WM you use? Or is there differences depending on which WM you use?

I'm curious: You say that if you float the window, it goes away, right? So, if you float a window, and then use the keyboard/mouse to resize the window a pixel at a time, does the dead area get bigger, bigger, bigger, then GONE, then start again getting bigger? Or is the problem just completely not there with floating windows?

T3slider · 03-17-2010, 02:15 AM

Alright, well I just did a remarkably fast fix by modifying my xmonad.hs file. I already knew the issue so my above post is correct, but if you want the fix for xmonad, I just added

Code:

import XMonad.Layout.LayoutHint

to my list of imports and just added

Code:

layoutHintsToCenter

to my layoutHook (my xmonad.hs file is highly customized so I won't give the actual line, but it would look like the following):

Code:

layoutHook         = layoutHintsToCenter myLayout,

Of course there are other options in the XMonad.Layout.LayoutHint layout.

There is likely a similar option for scrotwm or other tiling WMs that don't hint automatically.

mkoco · 03-17-2010, 10:50 AM

Thanks! I'll those things out when I'm back from work and let you both know.

mkoco · 03-17-2010, 07:38 PM

Sasha: The dead space just goes away completely when I float window. So far I've only seen this behavior in xmonad and scrotwm, the two dynamic tiling window managers I've used.

T3slider: I found this is mentioned in the xmonad faq as well, here:http://haskell.org/haskellwiki/Xmona...C_urxvt.2Cetc.

I'm trying the fix you suggested, but I'm new to haskell and xmonad, so I'm having problems. Would you mind elaborating just a bit? Here is my (very) short xmonad.hs:

Code:

import XMonad
import Data.Monoid
import System.Exit
import XMonad.Layout.LayoutHints

import qualified XMonad.StackSet as W
import qualified Data.Map        as M


myTerminal = "urxvt"
myLayout = layoutHintsToCenter

main = xmonad defaults

defaults = defaultConfig {
      -- simple stuff
        terminal           = myTerminal,
     -- focusFollowsMouse  = myFocusFollowsMouse,
     -- borderWidth        = myBorderWidth,
     -- modMask            = myModMask,
     -- numlockMask        = myNumlockMask,
     -- workspaces         = myWorkspaces,
     -- normalBorderColor  = myNormalBorderColor,
     -- focusedBorderColor = myFocusedBorderColor,

      -- key bindings
     -- keys               = myKeys,
     -- mouseBindings      = myMouseBindings,

      -- hooks, layouts
        layoutHook         = myLayout
     -- manageHook         = myManageHook,
     -- handleEventHook    = myEventHook,
     -- logHook            = myLogHook,
     -- startupHook        = myStartupHook
    }

But I getting these errors:

Code:

xmonad.hs:13:7:
    No instances for (LayoutClass l Window, Read (l Window))
      arising from a use of `xmonad' at xmonad.hs:13:7-21
    Possible fix:
      add an instance declaration for
      (LayoutClass l Window, Read (l Window))
    In the expression: xmonad defaults
    In the definition of `main': main = xmonad defaults

xmonad.hs:31:29:
    Couldn't match expected type `GHC.Word.Word32'
           against inferred type `XMonad.Layout.LayoutModifier.ModifiedLayout
                                    XMonad.Layout.LayoutHints.LayoutHintsToCenter l a'
      Expected type: l a -> Window
      Inferred type: l a
                     -> XMonad.Layout.LayoutModifier.ModifiedLayout
                          XMonad.Layout.LayoutHints.LayoutHintsToCenter l a
    In the `layoutHook' field of a record
    In the expression:
        defaultConfig {terminal = myTerminal, layoutHook = myLayout}

Of course I'll be reading up on this also, but any suggestions?

Edit: Actually got that sorted out

. Off to hack haskell..