I'm kinda busy this weekend with a machine migration, so I haven't been following this very closely.

On Sat, Aug 30, 2014 at 11:22 AM, Paul Fertser <fercerpav@gmail.com> wrote:
On Fri, Aug 29, 2014 at 06:41:14PM -0700, Anton Vorontsov wrote:
> +signalLocalWindow :: Signal -> Window -> X ()
> +signalLocalWindow s w  = do
> +    host <- io $ getEnvDefault "HOSTNAME" ""
> +    hasProperty (Machine host) w >>= flip when (signalWindow s w)

HOSTNAME is a bash-specific variable and it's not exported by default,
so neither XMonad nor ghci sees it (even though I actually use bash on
this machine):

It's actually worse than that, because the format of WM_CLIENT_MACHINE is not specified; for example, on the local host it could be any of:

    "localhost"
    short hostname
    fully qualified hostname
    dotted quad (IP address)
    conceivably, IPv6 address
    occasionally "localhost" qualified by local domain

An additional stinger in the tail is that two (arguably misconfigured... but virtually every Linux default install for the most common distributions is misconfigured in this way) hosts may both end up getting "localhost" (== an address on 127/8) when asking for their canonical network name, and you can't tell which one it refers to. So if WM_CLIENT_MACHINE resolves to a loopback address (::1 or 127.0.0.0/8; 127.0.0.1 is not good enough, several Linuxes use 127.0.1.1 as a dhcp hack) you pretty much have to ignore it and assume you can't know what machine it is running on. Same if WM_CLIENT_MACHINE is not set at all.

I also recently determined that the Haskell X11 bindings have a buggy interface to retrieving WM_CLIENT_MACHINE via Xlib instead of fetching the property directly, and xmonad can dump core if the bug is triggered.

I've noticed another unpleasant side-effect of this: urxvtd is a
single process that can have many windows (each spawned with
urxvtc). So if the stoppable workspace has a urxvtd window, all the
other terminal windows get frozen too. Should an optional filtering
facility be added?

Probably, although spotting window factories is difficult in general.

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