- xmonad - Haskell.org

trigger xmonad commands with shell script
by Sepp Tannhuber 16 Sep '14

16 Sep '14

Dear all, I would like to raise a certain window from within a shell script. Is it possible to trigger xmonad to execute something like raiseMaybe (runInTerm "-title myWindow" "myWindow") (title =? "myWindow") with a shell script? Or do you know any other possibility to raise a window from a shell?

2 2

xmonad --recompile breakage
by Carsten Mattner 15 Sep '14

15 Sep '14

xmonad --recompile stopped working here this week and fails with scope errors in stuff from xmonadcontrib. Anyone else see this?

2 4

Issue 568 in xmonad: Actions.DynamicWorkspaceGroups viewWSGroup changes which workspace has focus incorrectly
by codesite-noreply＠google.com 13 Sep '14

13 Sep '14

Status: New Owner: ---- New issue 568 by nwfila...(a)gmail.com: Actions.DynamicWorkspaceGroups viewWSGroup changes which workspace has focus incorrectly http://code.google.com/p/xmonad/issues/detail?id=568 When running viewWSGroup, the focus is set to whichever display is last in the windowset's visible set. It would be better, IMHO, if focus were considered part of the WSGroup. Simply reversing the list of workspaces should mean that the last greedyView serves to restore focus to the workspace (and screen) focused-at-group-creation-time. --- old-XMonadContrib/XMonad/Actions/DynamicWorkspaceGroups.hs 2014-05-06 20:26:25.919864085 -0400 +++ new-XMonadContrib/XMonad/Actions/DynamicWorkspaceGroups.hs 2014-05-06 20:26:26.163865644 -0400 @@ -93,7 +93,7 @@ -- | Give a name to the current workspace group. addCurrentWSGroup :: WSGroupId -> X () addCurrentWSGroup name = withWindowSet $ \w -> - addWSGroup name $ map (W.tag . W.workspace) (W.current w : W.visible w) + addWSGroup name $ map (W.tag . W.workspace) (reverse $ W.current w : W.visible w) -- | Delete the named workspace group from the list of workspace -- groups. Note that this has no effect on the workspaces involved; A different, equally-defensible behavior, would be to consider the focus to not be part of the WSGroup and to hold the current focus across the viewWSGroup operation. A wrapper like this may be useful: holdScreenFocus a = do s <- gets (S.screen . S.current . windowset) r <- a screenWorkspace s >>= maybe (return ()) (windows . S.view) return r Thanks! --nwf; -- You received this message because this project is configured to send all issue notifications to this address. You may adjust your notification preferences at: https://code.google.com/hosting/settings

1 2

update: chromium slow redraw
by Carsten Mattner 13 Sep '14

13 Sep '14

Due to my local xmonad --recompile breakage I had to fall back to dwm and was surprised to see that the very slow non-floating Chromium window redraw evident in XMonad since Chromium switched to Aura does NOT happen in dwm. Any idea what's different in the dwm X11 code that doesn't make Chromium window (content) redraws super visible (slow)?

1 1

What happened to ScreenWorkspaces?
by Mike Sullivan 02 Sep '14

02 Sep '14

Does anybody know what happened to the ScreenWorkspaces module, mentioned briefly here? http://article.gmane.org/gmane.comp.lang.haskell.xmonad/7223 It sounds useful, as it seems like it would extend Xmonad.Layout.IndependentScreens to also allow for a more polished experience (notably, perhaps it would fix CycleWS behavior as discussed at http://www.haskell.org/pipermail/xmonad/2009-December/009466.html) Also, it would allow for a more Gnome-like multi-head experience (as mentioned at http://article.gmane.org/gmane.comp.lang.haskell.xmonad/7774) Mike

1 0

Leak... somewhere... I periodically restart xmonad to recover gobs of swap space
by Michael Witten 02 Sep '14

02 Sep '14

Software: xmonad 0.11 xmobar 0.10 Xorg 1.14.1 After a while (say, a month) of normal activity, my swap space becomes almost entirely eaten up; the problem can be solved by restarting xmonad (`mod-q'). The problem could well be `xmobar' or `X' itself.

5 10

darcs patch: Add Stoppable layout for power saving (and 1 more)
by Anton Vorontsov 01 Sep '14

01 Sep '14

In this version I addressed further comments by Paul Fertser, plus implemented the remote/local clients identification scheme that I was talking about: it is in XMonad.Util.RemoteWindows module with documentation and all. I split the work into two logical changes, for easier review and so that the first patch won't depend on the second. Thanks, Anton 2 patches for repository http://code.haskell.org/XMonadContrib: Mon Sep 1 00:21:41 PDT 2014 Anton Vorontsov <anton(a)enomsg.org> * Add Stoppable layout for power saving This module implements a special kind of layout modifier, which when applied to a layout, causes xmonad to stop all non-visible processes. In a way, this is a sledge-hammer for applications that drain power. For example, given a web browser on a stoppable workspace, once the workspace is hidden the web browser will be stopped. Note that the stopped application won't be able to communicate with X11 clipboard. For this, the module actually stops applications after a certain delay, giving a chance for a user to complete copy-paste sequence. By default, the delay equals to 15 seconds, it is configurable via 'Stoppable' constructor. The stoppable modifier prepends a mark (by default equals to "Stoppable") to the layout description (alternatively, you can choose your own mark and use it with 'Stoppable' constructor). The stoppable layout (identified by a mark) spans to multiple workspaces, letting you to create groups of stoppable workspaces that only stop processes when none of the workspaces are visible, and conversely, unfreezing all processes even if one of the stoppable workspaces are visible. To stop the process we use signals, which works for most cases. For processes that tinker with signal handling (debuggers), another (Linux-centric) approach may be used. See https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt Mon Sep 1 00:21:58 PDT 2014 Anton Vorontsov <anton(a)enomsg.org> * Implement proper handling of dynamically changing hostname The module implements a proper way of finding out whether the window is remote or local. Just checking for a hostname and WM_CLIENT_MACHINE being equal is often not enough because the hostname is a changing subject (without any established notification mechanisms), and thus WM_CLIENT_MACHINE and the hostname can diverge even for a local window. This module solves the problem. As soon as there is a new window created, we check the hostname and WM_CLIENT_MACHINE, and then we cache the result into the XMONAD_REMOTE property. Notice that XMonad itself does not know anything about hostnames, nor does it have any dependency on Network.* modules. For this module it is not a problem: you can provide a mean to get the hostname through your config file (see usage). Or, if you don't like the hassle of handling dynamic hostnames (suppose your hostname never changes), it is also fine: this module will fallback to using environment variables.

1 0

Re: [xmonad] darcs patch: Add Stoppable layout for power saving
by Paul Fertser 31 Aug '14

31 Aug '14

Hi, 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): Prelude System.Posix.Env> getEnv "HOSTNAME" Nothing As the result, this version doesn't work as expected. 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? On an unrelated note, where do you get opportunities to apply your Haskell skills? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com

3 4

darcs patch: Add Stoppable layout for power saving
by Anton Vorontsov 29 Aug '14

29 Aug '14

Changes: - Per Brandon Allbery's suggestion the module now checks WM_CLIENT_MACHINE, and thus no longer tries to stop remote clients. - Per Paul Fertser's suggestion improved documentation, and also implemented a delay to make X11 clipboard limitations less noticeable. 1 patch for repository http://code.haskell.org/XMonadContrib: Fri Aug 29 18:03:14 PDT 2014 Anton Vorontsov <anton(a)enomsg.org> * Add Stoppable layout for power saving This module implements a special kind of layout modifier, which when applied to a layout, causes xmonad to stop all non-visible processes. In a way, this is a sledge-hammer for applications that drain power. For example, given a web browser on a stoppable workspace, once the workspace is hidden the web browser will be stopped. Note that the stopped application won't be able to communicate with X11 clipboard. For this, the module actually stops applications after a certain delay, giving a chance for a user to complete copy-paste sequence. By default, the delay equals to 15 seconds, it is configurable via 'Stoppable' constructor. The stoppable modifier prepends a mark (by default equals to \"Stoppable\") to the layout description (alternatively, you can choose your own mark and use it with 'Stoppable' constructor). The stoppable layout (identified by a mark) spans to multiple workspaces, letting you to create groups of stoppable workspaces that only stop processes when none of the workspaces are visible, and conversely, unfreezing all processes even if one of the stoppable workspaces are visible. To stop the process we use signals, which works for most cases. For processes that tinker with signal handling (debuggers), another (Linux-centric) approach may be used. See https://www.kernel.org/doc/Documentation/cgroups/freezer-subsystem.txt

1 0

Re: [xmonad] darcs patch: Add Stoppable layout for power saving
by Paul Fertser 29 Aug '14

29 Aug '14

On Thu, Aug 28, 2014 at 01:12:31PM -0700, Anton Vorontsov wrote: > On Thu, Aug 28, 2014 at 11:00:28PM +0400, Paul Fertser wrote: > > Handy for the shit-sites that make firefox spin violently even when > > it's not visible! > > Exactly. :) Extends laptop on-battery time drastically. This has an unpleasant side-effect though, I'm usually having firefox (duh, should be using emacs-w3m more but it sucks in its own ways) fullscreen and when I copy a link from it or just select some text, and switch to a different workspace, the pasting from X selection doesn't happen until I switch back to unfreeze the shit-browser. That's less annoying than wasting cpu cycles but as a known limitation should better be documented. -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav@gmail.com

2 1