- xmonad - Haskell.org

emacs making itself sticky and copyToAllToggle
by Antoine Beaupre 13 Apr '17

13 Apr '17

Hi, I've been working on improving the integration between the great [writeroom-mode][] and Xmonad here, in what is probably the worst case of procrastination, yak-shaving level. Writeroom is a "distraction-free writing" mode for emacs. It turns out the "sticky" signal it sends is not recognized by Xmonad, a known limitation which I will not expand on here - other people more familiar with Xmonad may fix or talk about this better than me. [writeroom-mode]: https://github.com/joostkremers/writeroom-mode/ But, needing to scratch that particular itch, and with the help of clever people from the IRC channel, I was able to basically accomplish what I needed. This involved creating a new function which I think could be useful in the CopyWindow library: -- | Toggle between "copyToAll" or "killAllOtherCopies". Copies to all -- workspaces, or remove from all other workspaces, depending on -- previous state (checked with "wsContainingCopies"). copyToAllToggle :: X () copyToAllToggle = do -- check which workspaces have copies copies <- wsContainingCopies if null copies then windows copyToAll -- no workspaces, make sticky else killAllOtherCopies -- already other workspaces, unstick There are probably better ways of implementing this directly in the CopyWindow code - wsContainingCopies, in particular, is probably overkill. But it's all I can use directly from my xmonad.hs, so that's what I did. The other bit I needed was something to trigger that function from the outside. I rejected the ServerMode hook because it looked a bit too complicated and there is a built-in facility within X that works without this, which, from Emacs' point of view, is the `x-send-client-message` function. So I made up a new message identifier and wrote a event hook handler to process it: -- | handle X client messages that tell Xmonad to make a window appear -- on all workspaces -- -- this should really be using _NET_WM_STATE and -- _NET_WM_STATE_STICKY. but that's more complicated: then we'd need -- to inspect a window and figure out the current state and act -- accordingly. I am not good enough with Xmonad to figure out that -- part yet. -- -- Instead, just check for the relevant message and check if the -- focused window is already on all workspaces and toggle based on -- that. -- -- this is designed to interoperate with Emacs's writeroom-mode module -- and called be called from elisp with: -- -- (x-send-client-message nil 0 nil "XMONAD_COPY_ALL_SELF" 8 '(0)) myClientMessageEventHook :: Event -> X All myClientMessageEventHook (ClientMessageEvent {ev_message_type = mt, ev_data = dt}) = do dpy <- asks display -- the client message we're expecting copyAllMsg <- io $ internAtom dpy "XMONAD_COPY_ALL_SELF" False -- if the event matches the message we expect, toggle sticky state when (mt == copyAllMsg && dt /= []) $ do copyToAllToggle -- we processed the event completely return $ All True All that was left was to hook that into emacs, and I was done! Whoohoo! Full screen total domination, distraction free work! :) Attached is the patch to my configuration files that accomplished the whole thing. I would love to hear from others what they think of that approach, if they have improvements or if the above copyToAllToggle function could be merged in. Ideally, Xmonad would just parse the STICKY client messages and do the right thing - maybe even directly in CopyWindow - but I have found this enough Haskell for one day.. :) Thanks for your attention, A. -- Instead of worrying about what somebody else is going to do, which is not under your control, the important thing is, what are you going to decide about what is under your control? - Richard Stallman

1 0

Cntr-F not working in several apps and Chrome has no menubar
by Gregory Propf 30 Mar '17

30 Mar '17

I've been looking around for others with these problem but haven't found anything so far, much less a fix. The subject line sums up the problems. Cntr-F isn't working in a few apps I use a lot. I think there are others but the main ones are Google Chrome (Version 57.0.2987.98 (64-bit)) and the Arduino IDE (v 1.8.0). I'm running a recent install of Arch Linux and Xmonad 0.13-1 from the Arch repository. I don't have a complex xmonad.hs but I'll post it here. There are a few other glitches like the fact that the menus in the Arduino IDE appear off to the side from the menu labels but I can live with that. Being able to search is kind of important though. What I do right now in both Chrome and Arduino IDE is click on the file menu and then select "Find" from the drop-down menu. It's workable but quite cumbersome. My Haskell skills are actually pretty good BTW so I'm not afraid of the code. I'd even be willing to contribute at some point. import XMonad import XMonad.Hooks.DynamicLog import XMonad.Hooks.ManageDocks import XMonad.Util.Run(spawnPipe) import XMonad.Util.EZConfig(additionalKeys) import System.IO main = do xmproc <- spawnPipe "/usr/bin/xmobar -d /home/gregory/.xmobarrc" xmonad $ docks defaultConfig -- xmonad $ defaultConfig { manageHook = manageDocks <+> manageHook defaultConfig , layoutHook = avoidStruts $ layoutHook defaultConfig , logHook = dynamicLogWithPP xmobarPP { ppOutput = hPutStrLn xmproc , ppTitle = xmobarColor "green" "" . shorten 50 } , modMask = mod4Mask -- Rebind Mod to the Windows key , terminal = "urxvt" }

2 6

xmonad monitor resolution
by Dusan Popovic 30 Mar '17

30 Mar '17

Hi, I have replaced old 1680x1050 monitor with the new one which works at 1920x1080 resolution. I am running everything on arch so latest xorg, xmonad and xmonad-contrib available in repos. Not using xorg.conf at all. Xorg properly detects resolution so xmobar and feh use whole monitor area to show bar and wallpaper. Xrandr also shows proper resolution. So it all works well until I open any window, or several of them: they tile like there is still 1680x1050 monitor; top left coordinate of the tiling area starts right below xmobar (it is at the right position) but there is unused gap on the right and bottom (exact difference between old/new monitor resolution). It is like xmonad remembered old resolution somewhere and sticks with it no matter what I try. I also tried i3 and it detects/uses whole screen area properly. I have also recompiled xmonad.hs but nothing changed. Help? Thanks.

3 2

auto start apps on login, but not reloads
by Sam Halliday 25 Mar '17

25 Mar '17

Hi all, I am trying to set up auto start of my main applications. Following http://stackoverflow.com/questions/10976044/ I have added the following to my `startupHook` startup :: X () startup = do setWMName "LG3D" spawnOn "workspace1" "urxvt" spawnOn "workspace2" "emacs" spawnOn "workspace3" "chromium" but there are three problems: 1. I am duplicating the definition of my terminal. It seems like I should be using [`shellPromptOn`](http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-SpawnOn.html) but it takes an extra parameter and I don't know where to get it from. 2. this is putting everything on my current workspace. How can I find out what my workspaces are called? I don't believe I've customised the names, you can see [my .xmonad/xmonad.hs on github to confirm](https://github.com/fommil/dotfiles/blob/master/.xmonad/xmonad.hs) 3. This will start the apps again on a `xmonad --restart`. How can we guard against that? It is very useful to be able to restart xmonad without quitting and I don't want to lose that ability. NOTE: re-post of tumbleweed http://stackoverflow.com/questions/42467774 -- Best regards, Sam

5 8

Border widths
by Dominik Schrempf 20 Mar '17

20 Mar '17

Hello, is it possible to decrease border width when windows are adjacent? E.g., if the border width is 1px, adjacent windows are separated by a border of 2px while windows are separated by borders of size 1px from the edges of the screen. It would be nice to be able to merge borders between adjacent windows, focusedBorderColor should have precedence such that windows facing a focussed window actually do not have a border with normalBorderColor on that side. Thank you, Dominik

3 2

GLFW fullscreen
by Tuncer Ayaz 20 Mar '17

20 Mar '17

I wrote a patch[1] for MuPDF's OpenGL viewer (which makes use of GLFW) to enable fullscreen toggle, but XMonad doesn't like GLFW's implementation. Also, since glfwSetWindowTitle sets X11's title, class, and instance to the same value, it's currently impossible[2] to apply a rule for the window, but it's easy to patch and test if you think this can be solved with a manageHook rule. Entering and returning from fullscreen does work correctly with FVWM, Fluxbox, WindowMaker, dwm, Weston, and sway, of which two are Wayland compositors and dwm is a tiling wm like XMonad. What happens with XMonad is that it enters GLFW fullscreen after a multi-second delay and is not able to return from it on toggle. If I patch mupdf to not update the title, add a doFloat rule, and toggle fullscreen, it does not enter fullscreen until I manually interact with the still visibly floating window by trying to move it with a mouse. However, it does return from fullscreen into its original size/position when I press 'f' again. My config is a a personal extension of https://github.com/xmonad/xmonad-testing/blob/master/example-config.hs. Is GLFW's fullscreen toggle implementation generally problematic in XMonad, or can I solve this in my config? As noted in [1], llpp fullscreen toggle works with XMonad, and it uses OpenGL as well, but it doesn't rely on GLFW, so this isn't a general issue with OpenGL but specific to GLFW. [1] https://bugs.ghostscript.com/show_bug.cgi?id=697593 [2] https://bugs.ghostscript.com/show_bug.cgi?id=697634

3 9

Firefox redraw
by Tuncer Ayaz 19 Mar '17

19 Mar '17

The recent urxvt slow rendering thread reminded me that xmonad sometimes suffers from an interesting redraw slowdown with Firefox that doesn't happen in dwm or spectrwm. Sometimes Firefox as the sole window in a tag/desk takes longer to redraw itself upon entering the tag/desk when the previous tag/desk was an empty one. If you switch from a tag/desk with one or more windows, then it's quicker to redraw. Put differently, you either notice the redraw or you don't. I say sometimes because I haven't been able to reproduce it today, but I wonder if anyone else has seen this. The config is xmonad-testing/example-config.hs or my extended version with personalized settings, and I use compton to enable vsync, if that matters.

1 0

urxvt slow rendering
by Richard Watson 08 Mar '17

08 Mar '17

Hello I've been a long-time xmonad user (over 5 years) on all my machines, installing using the Debian package. I'm currently running Debian jessie kernel 3.16 on my main desktop. Recently I upgraded Debian on my primary desktop (jessie kernel 3.16). I'm running xmonad v0.11, instead of v0.10 on my other machines. I notice that when certain GUI application are running (e.g. Chrome, vmplayer, but not firefox & thunderbird) my urxvt terminal renders *really* slowly, redrawing the window line at a time! I also notice a huge X server CPU load (25-50%, as shown by top). I've looked at X server logs and config and cannot see anything that is unusual. Could there be an xmonad issue here? Has anyone else experienced something similar? Any hints as to how to debug this? --Richard Watson

5 7

Cycle through all visible windows
by alexsu04＠gmail.com 23 Feb '17

23 Feb '17

Hi all, I’ve been trying to get XMonad set up for dual monitor, but have been struggling with finding a way to cycle focus through every window (not workspace) visible on either screen. The behavior would be similar to XMonad.Actions.WindowNavigation (the experimental module), but the cycling wouldn’t be bound to any direction, just cycle through all visible windows in the normal Alt-Tab sequence (left to right, top to bottom). I’ve found some code in a previous thread that supposedly manipulates the StackSet, but it didn’t work for me: > -- top of config > import qualified XMonad.StackSet as W > -- somewhere at top level > onAllWS f = windows $ \ws(a)W.StackSet{ W.current = c, W.visible = vs } -> > let screenNext x = W.current . f $ ws { W.current = x } > c':vs' = map screenNext (c:vs) > in ws{ W.current = c', W.visible = vs' } ... > -- in keybindings: there are much more W.swap* W.focus* and W.shift* functions to use. > ,((modm, xK_f), onAllWS W.focusDown) > ,((modm, xK_d), onAllWS W.focusUp) > ,((modm, xK_g), onAllWS W.swapMaster) Unfortunately, I’m still too terrible at Haskell to fix whatever is wrong with the above code, and haven’t found any other modules that have the functionality I want. Any help would be appreciated! Thanks! Alex

6 12

Not inheriting default Keybindings
by Dave Macias 20 Feb '17

20 Feb '17

Hello everyone been using xmonad for about 2 years now and it's great! something that was mention resently on another mail was something about "default keybindings being inherited or overwritten" That is actually what happens with my xmonad.hs. I have to manually code every default keybinding for them to work. It would be nice to shrink the xmonad.hs file by inheriting the default keybindings but i have no clue what to change. Im assuming my issue is in 'main' or 'defaults'. I tested mod+shift+enter which should run 'myTerminal' but it does not :( Here is a snippet of the config. Note that i pass 'hostname' down for perHost keybindings. http://pastebin.com/Msec53xJ Thank you for the assistance -dave

2 2