Dialog window (zenity) not floated when ewmhFullscreen present

[mrozigor]

Problem Description

When ewmhFullscreen is present, then fullscreen apps (i.e. Firefox in fullscreen mode) works OK - by that I mean properly overlapping xmobar/temporarily removing bar from screen. But with these settings zenity dialogs don't work properly - they are not floated at all and are normally tiled. When I remove ewmhFullscreen from config, then dialogs works as expected - properly floated - but fullscreen apps don't (xmobar is always visible).

I'm not sure if this is my config mistake (probably) or something is wrong with xmonad. I'll be thankful for any help or documentation page that will help resolving the issue ;) Thanks.

Steps to Reproduce

Run zenity dialog (e.g. zenity --info --title "TITLE") with given config.

Configuration File

import XMonad
import XMonad.Hooks.DynamicLog
import XMonad.Hooks.EwmhDesktops
import XMonad.Hooks.ManageDocks
import XMonad.Hooks.ManageHelpers
import XMonad.Util.Run(spawnPipe)
import XMonad.Util.EZConfig(additionalKeys)
import XMonad.Hooks.SetWMName
import XMonad.Layout.NoBorders
import XMonad.Layout.IndependentScreens
import XMonad.Layout.Fullscreen
import qualified XMonad.StackSet as W
import System.IO
import Control.Monad
import Data.Maybe
import Data.List
import XMonad.Util.WorkspaceCompare (getSortByXineramaRule) 
import Data.Ratio
import XMonad.StackSet

-- Check if window is modal
checkModal :: Query Bool
checkModal = isInProperty "_NET_WM_STATE" "_NET_WM_STATE_MODAL"

main = do
  xmproc <- spawnPipe "xmobar"

  xmonad $ ewmhFullscreen . ewmh $ docks $ def
    { manageHook = manageDocks <+> composeAll
      [ isDialog --> doCenterFloat,
        checkModal --> doCenterFloat,
         --isFullscreen --> doFullFloat,
         title =? "Ediff" --> doCenterFloat,
         className =? "zenity" --> doFloat,
         transience' ]
    , layoutHook = smartBorders . avoidStruts $ Full ||| Tall 1 0.02 0.5 ||| Mirror (Tall 1 0.02 0.5) -- layoutHook def
    , handleEventHook = handleEventHook def
    , terminal = "urxvt"
    , logHook = dynamicLogWithPP xmobarPP
      { ppOutput = hPutStrLn xmproc
      , ppTitle = xmobarColor "cyan" "" . shorten 50
      , ppSort = getSortByXineramaRule
      , ppVisible = wrap "(" ")"
      }
    , modMask = mod4Mask
    , startupHook = setWMName "LG3D"
    } `additionalKeys`
    [ ((mod4Mask .|. shiftMask, xK_z), spawn "xtrlock -f")
    , ((mod4Mask, xK_r), spawn "/home/igor/scripts/setup_screens")
    ]

Checklist

• I've read CONTRIBUTING.md

• I tested my configuration

  • With xmonad version 0.17.0
  • With xmonad-contrib version 0.17.1

[geekosaur]

For some reason, when I run this config in my test harness xmonad crashes on startup with a BadAtom error.

[liskin]

I can't reproduce this with the config provided nor with a simple main = xmonad $ ewmhFullscreen $ desktopConfig{ terminal = "urxvt" } config either. I tried git master of everything but I'm not aware of any related changes since 0.17.

[mrozigor]

I wasn't able to fix it either, but it helped to change ewmhFullscreen to fullscreenSupport. I guess I can close the issue. Thanks for help :)

[jecaro]

I have a similar issue. I'm running nixos-23.05, with these versions: xmonad-0.17.2 and xmonad-contrib-0.17.1

This is the most simple repro:

import XMonad
import XMonad.Hooks.EwmhDesktops

main = do
    xmonad
        . ewmhFullscreen
        $ def
            { manageHook = appName =? "gnome-calculator" --> doFloat
            , terminal = "kitty"
            }

With this config, when one starts gnome-calculator it does not appear in the floating layer but it is tiled like any other window. Remove the config added by ewmhFullscreen, and gnome-calculator rightly appears in the floating layer when started.

Using fullscreenSupport doesn't work for me. When quitting a fullscreen window, for example, YouTube on Chrome, the Chrome window does not sink back among the tiled windows.

Digging a bit further down, this code block is responsible for sinking the window:

https://github.com/xmonad/xmonad-contrib/blob/afd6824ce00063bb8e9b7a1c5daf0737c2f61616/XMonad/Hooks/EwmhDesktops.hs#L442C5-L444

I do not know if gnome-calculator is issuing wrong commands here or if there is something wrong in the logic of this function. In any case, I worked around the issue by changing the condition for:

        when (isFull && (action == remove || action == toggle)) $ do

It seems to work OK so far. However, that's not a proper fix but just a wild guess.

I'd be happy to have feedback about this and ofc to debug even more to come up with a better fix. But I need someone to give me a bit of information about ewmh and how this function works from a high-level perspective.

[geekosaur]

Sorry for sitting on this a while, I've been a bit behind.

The only way you can hit that code block is if the application sends a _NET_WM_STATE ClientMessage to the root window, explicitly requesting that the window's state be changed. So it sounds like gnome-calculator is doing something unexpected here. (More likely it's a Gtk or GNOME library thing, restoring a window's state on startup.)

That said, your change looks reasonable from a "principle of least surprise" perspective.

Details of EWMH, specifically _NET_WM_STATE: https://specifications.freedesktop.org/wm-spec/latest/ar01s05.html#idm45709699729664