[xmonad] Re: bug using NoBorders and HintedTile

[TeXitoi]

Ivan Lazar Miljenovic <ivan.miljenovic at gmail.com> writes:

> Guillaume Pinot <guillaume.pinot at tremplin-utc.net> 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