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
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