[xmonad] darcs patch: Add Stoppable layout for power saving
Brandon Allbery
allbery.b at gmail.com
Sat Aug 30 16:05:06 UTC 2014
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 at 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 at gmail.com ballbery at sinenomine.net
unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/xmonad/attachments/20140830/fd3a8301/attachment.html>
More information about the xmonad
mailing list