Re: [xmonad] bug using NoBorders and HintedTile

Guillaume Pinot
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 ...
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...
-- 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.
-- 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.
-- 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.
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...
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? -- Ivan Lazar Miljenovic Ivan.Miljenovic@gmail.com IvanMiljenovic.wordpress.com

Ivan Lazar Miljenovic
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
participants (2)
-
Ivan Lazar Miljenovic
-
TeXitoi