- xmonad - Haskell.org

FZF integration
by Thomas Droxler 01 Sep '17

01 Sep '17

Hi all, I'm a big fan of FZF <https://github.com/junegunn/fzf> and I wanted to make an xmonad integration, to work like Util.Dmenu <https://hackage.haskell.org/package/xmonad-contrib-0.13/docs/XMonad-Util-Dm…>. I'm quite new to Haskell and I got some problems to do it. The main problem I have is that fzf needs to run in a shell and when I run an external terminal, it sucessfully pops up, but then the rest of the code continue to be executed and I can't wait for the output of fzf. Moreover, fzf give an output in the terminal, but then how do I get the output in my haskell code? I tried several think and the closest I got is to write the result of fzf in a file and read it back, but I cannot wait until my terminal shutdown to read my file, I have something like: *(filePath, handle) <- openTempFile "*path*" "fzf"* *hClose handle* *(_, _, _, procHandle) <- runInteractiveCommand ("xterm -e '*dataForFZF* | fzf >" ++ filePath ++"'")* *-- Here I need to wait that my term close, I tried: waitForProcess procHandle* *-- But it just freeze my Xmonad, and not sure a while loop on getProcessExitCode is better* *str <- readFile filePath* doSomethingWith* str* *removeFile filePath* Anyone has a hint to do this? Thanks a lot, cheers. Thomas Droxler

2 2

user-visible windows
by Matt 30 Jun '17

30 Jun '17

Hi all, I'm writing an extension and would like to know if there's some way to get a set of all windows visible to the user? I'm aware of StackSet.visible and StackSet.current. The windows obtained from these are not necessarily visible to the user- some may be totally obscured by others. I could get a list of the windows in z-order and calculate this myself, but was wondering whether anything existed that might suit my needs? Thanks in advance, Matt

2 1

ManageDocks issue
by Tim DuBois 01 Jun '17

01 Jun '17

Hi everyone, I haven't altered my configuration for almost a year now, but recently my layouts have not been respecting my dzen bar. I understand that ManageDocks should be handling this, although that's seemingly no longer the case. If you take a look at my config: https://github.com/Libbum/xmonad/blob/master/xmonad.hs you'll see I have manageDocks here 92 newManageHook = myManageHook <+> manageHook defaultConfig <+> manageDocks which is incorporated here: 190 main = do 191 dzenLeftBar <- spawnPipe myXmonadBar 192 dzenRightBar <- spawnPipe myStatusBar 193 xmonad $ defaultConfig 194 { terminal = myTerminal ... 201 , manageHook = newManageHook Has something changed that I'm overlooking, or is there anything in my config you can see is causing this? I'm at a loss at how to debug the problem at the moment. Regards, --Tim

2 1

XMonad.Hooks.ManageDocks: can't toggle dock gap since 0.13
by Mekeor Melire 10 May '17

10 May '17

Hello, since version 0.13 of xmonad(-contrib) and upgrading my config to that version, I find my config not to work as expected. Specifically, my binding for `sendMessage ToggleStruts` doesn't toggle the dock gap anymore. Instead, all windows overlap over my dock (dzen2) all the time. I followed the instructions at the documentation (of XMonad.Hooks.ManageDocks@xmonad-contrib): https://hackage.haskell.org/package/xmonad-contrib-0.13/docs/XMonad-Hooks-M… i.e. I apply `docks` on the XConfig and `avoidStruts` on the layout. You can find my current config on GitHub (repo: "config"; branch: "xmonad-0.13"): https://github.com/mekeor/config/blob/xmonad-0.13/home/mekeor/.xmonad/xmona… I also checked CHANGES.md but version 0.13 only seems to fix bugs in that module. What am I doing wrong? Am I missing something? -- mekeor ~ EDD3 DFFA 76F6 11C0 145F 9A99 AC85 BAD8 A2F8 C868

3 3

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

14 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