In fact, the problem appears when leaving a decorated layout controlled by IfMax, even if not from IfMax. Going to Full with a ToggleLayout, if toggling between full and IfMax n a b, exhibits the same behavior. I'd say, although I'm not sure, that leaving in any way any decorated layout controlled by IfMax leads to the same problem.

I had a look at the code to try and understand the difference between IfMax and ToggleLayouts, but couldn't spot the origin of the problem.

On Mon, Aug 15, 2016 at 12:39 PM, Thibault notifications@github.com wrote:

In fact, the problem appears when leaving a decorated layout controlled by
IfMax, even if not from IfMax. Going to Full with a ToggleLayout, if
toggling between full and IfMax n a b, exhibits the same behavior. I'd
say, although I'm not sure, that leaving in any way any decorated layout
controlled by IfMax leads to the same problem.

Have you tried it with a layout not controlled by IfMax? Decoration has
some known bugs where it does not clean up after itself properly, and
ToggleLayout is likely to provoke them. And it is entirely possible that
layout modifiers --- not just IfMax, but any conditional layout modifier
--- would make these worse by not allowing what cleanup it does to happen.

brandon s allbery kf8nh sine nomine associates
allbery.b@gmail.com ballbery@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

Thanks for your answer. Layouts not controlled by IfMax switches from decorated to undecorated without any visible problems: myLayoutHook = toggleLayouts Full $ noFrillsDeco shrinkText def $ emptyBSP works perfectly. NoFrills is my decorated layout of choice, but not the only one with the bug: I tried with some others, and all are affected as long as they're controlled by IfMax, but none with ToggleLayouts alone. I also tried using the git version of IfMax, with same results.

I'll write a few MWEs, so you can see if the bug is reproductible. I'm using latest packaged XMonad (from main repositories) on an up-to-date ArchLinux.

there are some fixes in X.L.IfMax in master, try it. 0.12 hasn't that fixes

@f1u77y : As I said in my previous message, I already tried with the git version of IfMax, not the full git xmonad-contrib though.

I'll write a MWE later today.

couldn't you give your conf? i experienced sort of that bug and thought it was fixed in master
UPD: ahh found that case in topic, will try to reproduce

Hi again,

Here's a MWE, as promised:

import XMonad
import XMonad.Config.Azerty
import XMonad.Layout.BinarySpacePartition (emptyBSP, ResizeDirectional(..), SelectMoveNode(..), Rotate(Rotate))
import XMonad.Layout.IfMax
-- import MyIfMax
import XMonad.Layout.NoFrillsDecoration
import XMonad.Layout.ToggleLayouts (toggleLayouts, ToggleLayout (ToggleLayout))

myLayoutHook = IfMax 1 Full $ noFrillsDeco shrinkText def emptyBSP

main :: IO ()
main = do
  xmonad azertyConfig {
    terminal = "urxvt"
    , layoutHook = myLayoutHook
    }

Apologies for using AzertyConfig: feel free to replace with def. This is the version I've been testing with.

With this MWE, and using git IfMax (imported as MyIfMax):

• When reducing the number of windows on a given workspace below IfMax's threshold, decorations correctly disappear (this is not the case with packaged IfMax). OK.
• When switching from a decorated workspace (that is, a workspace with number of windows above threshold, triggering use of decorated layout) to another decorated workspace, the decorations change according to the new workspace layout. OK.
• When switching from a decorated workspace to another, undecorated workspace, either empty or with only 1 window, the decorations remain visible above the background or the single window.

@f1u77y, FWIW, my full config is here, but this one doesn't use IfMax, so shouldn't be of any help.

i think i got the problem. IfMax gets number of windows from other workspace when it handles the Hide message. will try to fix

UPD: as i can see, we cannot get the number of the windows on the workspace where layout runs in handleMessage(when this workspace is not focused). but we need it to handle messages correctry. i can propose a workaround(handle Hide messages separately) but other messages sent to inactive layouts will cause other bugs with IfMax. so, i don't have any idea for fixing it now(except breaking api), maybe @geekosaur can give a tip on this

Thanks for looking into it! By the way, what I'm actually trying to achieve is to have decorations if and only if there's more than one (non-floating) window in the current workspace. I really prefer decorations over borders to indicate focus. If you have any idea :-) I'm currently doing this with a custom MultiToggle Transformer, but that's obviously not automatic.

you can use X.L.IfMax version with a workaround as a temporary solution but you can experience other problems with messages(e.g. struts may work badly or smth else)

I just tried it, it seems to work perfectly, including struts (XMobar), toggling them, and layout messages. I haven't tested exhaustively, but everything in this config seems to work well.
Thanks again!

@f1u77y Did your fixes for X.L.IfMax make it into xmonad-contrib?

@pjones that fix is just a workaround. Layout should know, what(in this case at least how many) windows are there on its workspace at every moment; that's the only way that allows to fix this bug.

Weeding old stuff in my inbox... how completely should it need to know this, @f1u77y ? Because some things require actually running the layout, and you can't do that if it's not displayed. (Notably, if I doShift in the manageHook, this increases the number of windows in the layout without notifying it; layouts only "exist" when rendering a workspace, not when manipulating the StackSet.)

I just countered the same issue in version 0.16. I haven't tried the work around yet.

I decided to go with the approach shared here: https://www.reddit.com/r/xmonad/comments/glkc6r/can_xmonad_apply_window_decorations_nofrillsdeco/fqy1vda/
Here's the commit where I added it to my config in case anyone is wondering how to add and use it.
willbush/system@0b502f9

I think the correct way to fix this is to add an L | R field (state) to the IfMax data type so that handleMessage doesn't need to guess which one of the two layouts is active.

That being said, @f1u77y's workaround is probably quite safe as well, as sending extra Hide messages shouldn't harm anything, and is actually being done by IfMax's runLayout function all the time. But propagation of other messages to IfMax layouts on inactive (visible/hidden) workspaces is entirely broken still.

I'm not an IfMax user myself so this is low-prio for me but I'd be happy to review/mentor any efforts towards fixing this.