[xmonad] Re: bug using NoBorders and HintedTile

2 Jun 2010

      Ivan Lazar Miljenovic  writes:
...
Guillaume Pinot  writes:
...
I'll try to be more descriptive. I've seen the bug on xmonad 9.1 on
Debian testing and OpenBSD. This is a xmonad-contrib related bug.
I hope you mean 0.9.1 ...
yes, sorry.
...
...
...
...
I post here a bug report. Sumbit it to the bug tracker if you want.
The xmonad.hs showing the bug with comments:
########
import XMonad hiding (Tall)
import XMonad.Layout.NoBorders
import XMonad.Layout.HintedTile
import XMonad.Hooks.ManageDocks
-- open 2 terminals. focus on one. launch top inside. change layout twice
The goal of this procedure is to change from a Full layout with no
border from smartBorders to HintedTile on a hinted window.
Did you mean applying smartBorders to both of them?  Because that's what
you're doing here...
Yes, I mean when smartBorders is applied to both, the trouble is seen
when I change from a layout where smartBorders choose no borders to a
layout where smartBorders choose borders. The problem raizes only on
the focused window.
...
...
...
...
-- focused window do not follow hints
buggy = defaultConfig {
       manageHook = manageHook defaultConfig <+> manageDocks,
       layoutHook = avoidStruts . smartBorders $ tiled ||| Full
}
Using this config, the hinted window seems 2 pixels smaller in width
and height to follow the hints. Changing focus to the other window
will change the size of this window, making it follows the hints.
Which sounds like what you want.
After changing the focus, yes, it is the behavior that I expect.
Also, putting smartBorders before or after avoidStruts has the same
effect.
...
...
...
...
-- focused window will first not follow hints, and then follow.
flashing = defaultConfig {
       layoutHook = smartBorders $ tiled ||| Full
}
Using this config, in a first step, we have the same effect than with
the buggy config, but the layout is recalculated very fast to the good
size following hints. The result is that the window is redraw 2 times,
resulting in a flashing window. This is not problematic, but show that
the bug in not only related to manageDocks. ManageDocks only prevents
the second rendering, letting the window in the incorect size.
Because you're not doing any strut avoiding, so less finangling is needed.
I do not understand why the layout is applied 2 successive times in
this context.

I can reproduce the flashing effect using
  layoutHook = desktopLayoutModifiers . layoutHints . smartBorders $ tiled ||| Full
and the buggy effect using
  layoutHook = desktopLayoutModifiers . smartBorders . layoutHints $ tiled ||| Full

(with (tiled = Tall 1 0.03 0.5) and layoutHints from
XMonad.Layout.LayoutHints)
...
...
...
...
-- normal behavior, distributing smartBorders
workarround = defaultConfig {
       manageHook = manageHook defaultConfig <+> manageDocks,
       layoutHook = avoidStruts $ smartBorders tiled ||| smartBorders Full
}
When smartBorders is distributed to the different layouts, the size
follows hints. smartBorders is duplicated, so any "state" of
smartBorders is not shared between HintedTile and Full.
I think that it is because smartBorder use redoLayout from
XMonad.Layout.LayoutModifier.  From the doc of redoLayout:

  redoLayout allows you to intercept a call to runLayout on workspaces
  with at least one window, *after* it is called on the underlying
  layout...

Maybe to do it right, smartBorders should do its stuffs before calling
the underlying layout. I'll try this evening to implements
smartBorders using modifyLayout.
...
...
...
...
main = xmonad buggy
tiled = HintedTile 1 0.03 0.5 TopLeft Tall
########
I didn't find the explaination, but I suspect smartBorder saying to
the layout that the focused window do not have border (because of the
previous layout without border) and that HintedTile compute the size
of the window as there is no border, and then smartBorders add the
borders (resulting of a smaller window that do not follows hints).
You can find screenshots of the bug here :
http://texitoi.eu/~texitoi/xmonad-hints-bug/
hinted-bug.png : on the left window, you can see that the size does
not follow hints, resulting of garbadge at the bottom of the
window. We can see that the window is 2 pixels smaller than necessary,
comparing the size with the right window.
Well, stating which application that is would probably help...
uxterm on OpenBSD and urxvtc on Debian. The screenshots are done on
Debian with my normal config:
http://www.haskell.org/haskellwiki/Xmonad/Config_archive/TeXitoi's_xmonad.hs
...
...
hinted-good.png : the same after changing focus 2 times. The hints are
this time respected. The terminal is 1 line and 1 column bigger that
on hinted-bug.png
Changing borderWidth to 2 results in a 4 pixels too small size,
validating that the size of the window is calculated as if there is no
borders.
So, let me get this straight: your problem is that if smartBorders is
applied to the entire combined Layout (tiled ||| Full), then it redraws
worse than explicitly applying smartBorders to each sub-layout?
Yes.

-- 
Guillaume Pinot               http://www.irccyn.ec-nantes.fr/~pinot/

« Les grandes personnes ne comprennent jamais rien toutes seules, et
c'est fatigant, pour les enfants, de toujours leur donner des
explications... » -- Antoine de Saint-Exupéry, Le Petit Prince

()  ASCII ribbon campaign      -- Against HTML e-mail
/\  http://www.asciiribbon.org -- Against proprietary attachments