From allbery.b at gmail.com Sun Aug 3 01:55:45 2014 From: allbery.b at gmail.com (allbery.b at gmail.com) Date: Sat, 2 Aug 2014 21:55:45 -0400 (EDT) Subject: [xmonad] darcs patch: debug-debug Message-ID: <20140803015545.A6FD441386F5@vikktakkht.kf8nh.com> 1 patch for repository http://code.haskell.org/XMonadContrib: Sat Aug 2 21:49:01 EDT 2014 allbery.b at gmail.com * debug-debug Various fixes and enhancements to DebugWindow and DebugStack. ManageDebug requires these fixes, but some of them are significant even if not using ManageDebug. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-preview.txt Type: text/x-darcs-patch Size: 12593 bytes Desc: Patch preview URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug_debug.dpatch Type: application/x-darcs-patch Size: 28185 bytes Desc: A darcs patch for your repository! URL: From allbery.b at gmail.com Sun Aug 3 01:56:05 2014 From: allbery.b at gmail.com (allbery.b at gmail.com) Date: Sat, 2 Aug 2014 21:56:05 -0400 (EDT) Subject: [xmonad] darcs patch: debug-managehook Message-ID: <20140803015605.5D4C641386F5@vikktakkht.kf8nh.com> 1 patch for repository http://code.haskell.org/XMonadContrib: Sat Aug 2 21:51:24 EDT 2014 allbery.b at gmail.com * debug-managehook A set of hooks, and convenience combinators, to help with ManageHook debugging. Ordinary users may well want to use debugManageHookOn in normal configs, specifying a key sequence which can be pressed before running a command in order to capture debug information just for that command's main window. This is especially useful when trying to diagnose issues such as programs that do not play well with SpawnOn, or ManageHook matching on 'title' when the program does not set the window title until after it is mapped. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-preview.txt Type: text/x-darcs-patch Size: 4991 bytes Desc: Patch preview URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug_managehook.dpatch Type: application/x-darcs-patch Size: 20583 bytes Desc: A darcs patch for your repository! URL: From allbery.b at gmail.com Sun Aug 3 01:57:10 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 2 Aug 2014 21:57:10 -0400 Subject: [xmonad] darcs patch: debug-managehook In-Reply-To: <20140803015605.5D4C641386F5@vikktakkht.kf8nh.com> References: <20140803015605.5D4C641386F5@vikktakkht.kf8nh.com> Message-ID: On Sat, Aug 2, 2014 at 9:56 PM, wrote: > 1 patch for repository http://code.haskell.org/XMonadContrib: > On second thought, ignore both these patches until I do something like full testing. -- 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: From allbery.b at gmail.com Sun Aug 3 02:07:53 2014 From: allbery.b at gmail.com (allbery.b at gmail.com) Date: Sat, 2 Aug 2014 22:07:53 -0400 (EDT) Subject: [xmonad] darcs patch: debug-debug Message-ID: <20140803020753.4E1CA4209C68@vikktakkht.kf8nh.com> ** tested version ** 1 patch for repository http://code.haskell.org/XMonadContrib: Sat Aug 2 22:05:30 EDT 2014 allbery.b at gmail.com * debug-debug Various fixes and enhancements to DebugWindow and DebugStack. ManageDebug requires these fixes, but some of them are significant even if not using ManageDebug. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-preview.txt Type: text/x-darcs-patch Size: 12597 bytes Desc: Patch preview URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug_debug.dpatch Type: application/x-darcs-patch Size: 28189 bytes Desc: A darcs patch for your repository! URL: From allbery.b at gmail.com Sun Aug 3 02:08:11 2014 From: allbery.b at gmail.com (allbery.b at gmail.com) Date: Sat, 2 Aug 2014 22:08:11 -0400 (EDT) Subject: [xmonad] darcs patch: debug-managehook Message-ID: <20140803020811.B5D4D4209C68@vikktakkht.kf8nh.com> ** tested version ** 1 patch for repository http://code.haskell.org/XMonadContrib: Sat Aug 2 22:06:01 EDT 2014 allbery.b at gmail.com * debug-managehook A set of hooks, and convenience combinators, to help with ManageHook debugging. Ordinary users may well want to use debugManageHookOn in normal configs, specifying a key sequence which can be pressed before running a command in order to capture debug information just for that command's main window. This is especially useful when trying to diagnose issues such as programs that do not play well with SpawnOn, or ManageHook matching on 'title' when the program does not set the window title until after it is mapped. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-preview.txt Type: text/x-darcs-patch Size: 5376 bytes Desc: Patch preview URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: debug_managehook.dpatch Type: application/x-darcs-patch Size: 20968 bytes Desc: A darcs patch for your repository! URL: From allbery.b at gmail.com Sun Aug 3 02:08:34 2014 From: allbery.b at gmail.com (allbery.b at gmail.com) Date: Sat, 2 Aug 2014 22:08:34 -0400 (EDT) Subject: [xmonad] darcs patch: config-mate Message-ID: <20140803020835.003034209C68@vikktakkht.kf8nh.com> ** tested version ** 1 patch for repository http://code.haskell.org/XMonadContrib: Sat Aug 2 22:06:59 EDT 2014 allbery.b at gmail.com * config-mate Initial support for the Mate desktop environment (http://mate-desktop.org). Based on existing Gnome 2 support, since Mate is a maintained fork of Gnome 2. -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-preview.txt Type: text/x-darcs-patch Size: 3441 bytes Desc: Patch preview URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: config_mate.dpatch Type: application/x-darcs-patch Size: 19033 bytes Desc: A darcs patch for your repository! URL: From codesite-noreply at google.com Mon Aug 4 23:19:07 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Mon, 04 Aug 2014 23:19:07 +0000 Subject: [xmonad] Issue 575 in xmonad: Typo on web page Message-ID: <0-3425899027203913298-4099690262145614987-codesite-noreply=google.com@googlecode.com> Status: New Owner: ---- New issue 575 by rrt at sc3d.org: Typo on web page http://code.google.com/p/xmonad/issues/detail?id=575 xmonad.org/tour.html "ito" ? "into" -- 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 From codesite-noreply at google.com Tue Aug 5 02:29:19 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 05 Aug 2014 02:29:19 +0000 Subject: [xmonad] Issue 575 in xmonad: Typo on web page In-Reply-To: <0-3425899027203913298-4099690262145614987-codesite-noreply=google.com@googlecode.com> References: <0-3425899027203913298-4099690262145614987-codesite-noreply=google.com@googlecode.com> Message-ID: <1-3425899027203913298-4099690262145614987-codesite-noreply=google.com@googlecode.com> Updates: Status: Fixed Comment #1 on issue 575 by vogt.a... at gmail.com: Typo on web page http://code.google.com/p/xmonad/issues/detail?id=575 Thanks. I've just fixed it now. -- 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 From codesite-noreply at google.com Tue Aug 5 08:12:22 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 05 Aug 2014 08:12:22 +0000 Subject: [xmonad] Issue 348 in xmonad: Encoding task force In-Reply-To: <8-3425899027203913298-2682020412763794708-codesite-noreply=google.com@googlecode.com> References: <8-3425899027203913298-2682020412763794708-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-2682020412763794708-codesite-noreply=google.com@googlecode.com> Message-ID: <9-3425899027203913298-2682020412763794708-codesite-noreply=google.com@googlecode.com> Comment #9 on issue 348 by vej.... at gmail.com: Encoding task force http://code.google.com/p/xmonad/issues/detail?id=348 Such problems still exist, at least at two places: - In XMonad.Core, the spawn function breaks Unicode strings. For instance, if I do "spawn "notify-send \"R?veille-toi !\"" the "?" character in the notification becomes "?(c)". - In XMonad.Util.Dmenu, the menu arguments are similarly broken if they contain such characters. In the second case, I could solve the problem by removing all "encodeString" occurrences in the function runProcessWithInput from XMonad.Util.Run (there are other occurrences of "encodeString"in XMonad.Util.Run which may cause the same problem). I suspect (but have not tried) that removing "encodeString" in spawnPID (from XMonad.Core) would solve the first problem. -- 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 From codesite-noreply at google.com Tue Aug 5 08:13:34 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 05 Aug 2014 08:13:34 +0000 Subject: [xmonad] Issue 348 in xmonad: Encoding task force In-Reply-To: <9-3425899027203913298-2682020412763794708-codesite-noreply=google.com@googlecode.com> References: <9-3425899027203913298-2682020412763794708-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-2682020412763794708-codesite-noreply=google.com@googlecode.com> Message-ID: <10-3425899027203913298-2682020412763794708-codesite-noreply=google.com@googlecode.com> Comment #10 on issue 348 by vej.... at gmail.com: Encoding task force http://code.google.com/p/xmonad/issues/detail?id=348 Such problems still exist, in least at two places: - In XMonad.Core, the spawn function breaks Unicode strings. For instance, if I do "spawn "notify-send \"R?veille-toi !\""" the "?" character in the notification becomes "?(c)". - In XMonad.Util.Dmenu, the menu arguments are similarly broken if they contain such characters. In the second case, I could solve the problem by removing all "encodeString" occurrences in the function runProcessWithInput from XMonad.Util.Run (there are other occurrences of "encodeString"in XMonad.Util.Run which may cause the same problem). I suspect (but have not tried) that removing "encodeString" in spawnPID (from XMonad.Core) would solve the first problem. -- 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 From codesite-noreply at google.com Tue Aug 5 13:17:15 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 05 Aug 2014 13:17:15 +0000 Subject: [xmonad] Issue 348 in xmonad: Encoding task force In-Reply-To: <10-3425899027203913298-2682020412763794708-codesite-noreply=google.com@googlecode.com> References: <10-3425899027203913298-2682020412763794708-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-2682020412763794708-codesite-noreply=google.com@googlecode.com> Message-ID: <11-3425899027203913298-2682020412763794708-codesite-noreply=google.com@googlecode.com> Comment #11 on issue 348 by allber... at gmail.com: Encoding task force http://code.google.com/p/xmonad/issues/detail?id=348 Actually the problem here is that we fixed encoding issues once... and then ghc was changed to deal with encoding issues, and later the core libraries were modified to use ghc's encoding support, and we were left with a backward compatibility issue. Making sure that everything works properly on everything from Debian (typically with an ancient ghc that doesn't fully handle encoding) to Arch (typically bleeding edge) without either losing encoding or double-encoding is difficult. -- 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 From ant.b at hacari.org Thu Aug 7 07:44:12 2014 From: ant.b at hacari.org (Antonio Bibiano) Date: Thu, 7 Aug 2014 07:44:12 +0000 (UTC) Subject: [xmonad] xmonad hides xfce4-panel References: <539D3B43.6020205@gmx.net> <53B19880.7050107@gmx.net> Message-ID: Hi, I incurred in the same problem! I followed the hint in the first reply about the "order" in which the different components are called, but that turned out to not solve the issue unless I disable xfdesktop. (you can play with the order by having a look at the xfce4-settings-editor in the xfce4-session group, and change them using xfconf-query) Anyway no matter what the order seems that starting xfdesktop along with xmonad always hides the xfce4-panel. My solution is to start xmonad using a small script: #!/bin/bash sleep 2 xmonad --replace That's it , a little delay for xmonad allows xfdesktop to do it's thing safely with xfce4-panel and xfwm4 and everyone is happy :) I assume that this happens because xmonad is faster than xfdesktop and does something unexpected (perhaps ovverriding some environment variable as the first reply suggested?), or maybe simply doesn't give xfdesktop sufficient time to talk to xfwm4? hope this helps Antonio Damian Philipp writes: From xmonad at mail.nosreme.org Thu Aug 7 08:57:43 2014 From: xmonad at mail.nosreme.org (Chris Emerson) Date: Thu, 7 Aug 2014 09:57:43 +0100 Subject: [xmonad] xmonad hides xfce4-panel In-Reply-To: References: <539D3B43.6020205@gmx.net> <53B19880.7050107@gmx.net> Message-ID: <20140807085743.GA32419@visage.nosreme.org> Hi, On Thu, Aug 07, 2014 at 07:44:12AM +0000, Antonio Bibiano wrote: > Hi, > I incurred in the same problem! I also have had the same problem (on both a real computer and a VirtualBox VM). [...] > My solution is to start xmonad using a small script: My workaround has been to run "xfce4-panel --restart" after logging in (which was an improvement over killing xmonad/xfwm4/xmonad --replace). Starting xmonad with a delay at least has the advantage that it's an automated bodge, so I may do that for now, thanks. :-) Regards, Chris From codesite-noreply at google.com Thu Aug 7 20:31:50 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Thu, 07 Aug 2014 20:31:50 +0000 Subject: [xmonad] Issue 168 in xmonad: gnome-panel with autohide enabled appears behind main windows In-Reply-To: <9-3425899027203913298-9057318336818219204-codesite-noreply=google.com@googlecode.com> References: <9-3425899027203913298-9057318336818219204-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-9057318336818219204-codesite-noreply=google.com@googlecode.com> Message-ID: <10-3425899027203913298-9057318336818219204-codesite-noreply=google.com@googlecode.com> Comment #10 on issue 168 by jhy... at gmail.com: gnome-panel with autohide enabled appears behind main windows http://code.google.com/p/xmonad/issues/detail?id=168 Any update on this? I am thinking of switching to a tiling window manager. -- 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 From codesite-noreply at google.com Fri Aug 8 08:41:43 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Fri, 08 Aug 2014 08:41:43 +0000 Subject: [xmonad] Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes Message-ID: <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Status: New Owner: ---- New issue 576 by martin.s... at gmail.com: On FreeBSD Xmonad loses first hotkey sometimes http://code.google.com/p/xmonad/issues/detail?id=576 What steps will reproduce the problem? 1. Install FreeBSD (amd64). 2. Write a minimal xmonad.hs with xterm binding. 3. Start xmonad in Xorg. 4. Try (multiple times) Mod+Shift+Return. What is the expected output? What do you see instead? It's expected that xterm opens with the first time Mod+Shift+Return is pressed. Sometimes Xmonad loses the key-combo and you need to press it twice in fast succession. If you wait too long between the first and the second time in sequence, the hotkey will be lost again and again. I repeat once again: it happens SOMETIMES, but on average every 4th time. Try to open terminal and exit it again (Mod+Shift+Return -> Ctrl-D -> Mod+Shift+Return -> Ctrl-D -> ...). What version of the product are you using? On what operating system? hs-xmonad-0.11_7 FreeBSD 10.0 RELEASE (amd64). Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". You don't need mine. Use a minimal one: import XMonad main = xmonad defaultConfig { modMask = mod1Mask , terminal = "xterm" } Additional info: Cannot be reproduced on Linux. Everything works as expected there. -- 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 From codesite-noreply at google.com Fri Aug 8 08:56:35 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Fri, 08 Aug 2014 08:56:35 +0000 Subject: [xmonad] Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes In-Reply-To: <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> References: <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Message-ID: <1-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Comment #1 on issue 576 by martin.s... at gmail.com: On FreeBSD Xmonad loses first hotkey sometimes http://code.google.com/p/xmonad/issues/detail?id=576 I forgot something essential: This is only noticeable when trying to open a terminal. I don't notice this buggy behavior when doing something else (switching workspaces, focus, shifting windows etc). That means, everything else works on first press of a hotkey. It has to be something very special about how Xmonad sends Mod+Shift+Return and when a terminal application is to be opened. It does not depend on which Mod key I use (reproducible with Mod1 and Mod4) and it does not depend on which terminal application I use. It also does not depend whether a terminal application is in focus or not. Sometimes I use Firefox or something else and the hotkey for the terminal is lost. I have really no idea how to diagnose it further. -- 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 From codesite-noreply at google.com Sat Aug 9 15:42:45 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 09 Aug 2014 15:42:45 +0000 Subject: [xmonad] Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes In-Reply-To: <1-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> References: <1-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Message-ID: <2-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Comment #2 on issue 576 by martin.s... at gmail.com: On FreeBSD Xmonad loses first hotkey sometimes http://code.google.com/p/xmonad/issues/detail?id=576 Further information: Key bindings that are not affected: - Mod+<1...> - Mod+Shift+<1...> - Mod+Tab - Mod+M - Mod+Return - Mod+ - ... Key bindings which are affected by bug above: - Mod+Shift+Return - Mod+Shift+Backspace - Mod+P - Mod+Shift+P - ... -- 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 From codesite-noreply at google.com Sat Aug 9 16:16:24 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 09 Aug 2014 16:16:24 +0000 Subject: [xmonad] Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes In-Reply-To: <2-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> References: <2-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Message-ID: <3-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Comment #3 on issue 576 by allber... at gmail.com: On FreeBSD Xmonad loses first hotkey sometimes http://code.google.com/p/xmonad/issues/detail?id=576 Note that, of the affected keybindings, all but one are "spawn"s -- and the exception isn't even an xmonad keybinding (see http://www.haskell.org/wikiupload/b/b8/Xmbindings.png and http://xmonad.org/xmonad-docs/xmonad/src/XMonad-Config.html#line-170) but an X server internal binding that is usually disabled by default. -- 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 From codesite-noreply at google.com Sat Aug 9 16:39:57 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 09 Aug 2014 16:39:57 +0000 Subject: [xmonad] Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes In-Reply-To: <3-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> References: <3-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Message-ID: <4-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Comment #4 on issue 576 by martin.s... at gmail.com: On FreeBSD Xmonad loses first hotkey sometimes http://code.google.com/p/xmonad/issues/detail?id=576 Mod+Shift+Backspace is my custom binding that starts a shell script: ((modm .|. shiftMask, xK_BackSpace), spawn "~/.xmonad/scripts/shutdown.sh") This is a good hint, you've given me here. So how to diagnose it further from here on? -- 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 From codesite-noreply at google.com Sat Aug 9 18:41:56 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 09 Aug 2014 18:41:56 +0000 Subject: [xmonad] Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes In-Reply-To: <4-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> References: <4-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Message-ID: <5-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Comment #5 on issue 576 by allber... at gmail.com: On FreeBSD Xmonad loses first hotkey sometimes http://code.google.com/p/xmonad/issues/detail?id=576 If you can get a terminal open (or switch to a virtual console), it might be worth using `truss -f` on the running xmonad process to see if something is going wrong with `spawn`. You should see xmonad fork, then the child fork again and exit, and the grandchild exec `sh -c ...`. This would not actually be the first time we've had problems on FreeBSD; but the past problems were due to various attempts to improve our process handling which tripped over certain differences in *BSD's handling of "orphaning" child processes, and showed up differently -- in particular, it could not happen on the *first* child spawned, but only after hitting the child process limit which is usually fairly high (in the hundreds at least) these days. -- 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 From codesite-noreply at google.com Sat Aug 9 20:07:14 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sat, 09 Aug 2014 20:07:14 +0000 Subject: [xmonad] Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes In-Reply-To: <5-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> References: <5-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Message-ID: <6-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Comment #6 on issue 576 by martin.s... at gmail.com: On FreeBSD Xmonad loses first hotkey sometimes http://code.google.com/p/xmonad/issues/detail?id=576 One thing I can see from the truss output is that when it does NOT work, the following happens: 1) fork() 2) child process executing 3) poll(); recvmsg; setitimer(); poll(); SIGALRM When it works this happens: 1) setitimer(); setitimer(); 2) fork() 3) setitimer(); (again) 4) child process executing (SIGALRM happening multiple times within the child process) Does it help or do you need the detailed truss output? -- 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 From codesite-noreply at google.com Sun Aug 10 00:30:21 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sun, 10 Aug 2014 00:30:21 +0000 Subject: [xmonad] Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes In-Reply-To: <6-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> References: <6-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Message-ID: <7-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Comment #7 on issue 576 by allber... at gmail.com: On FreeBSD Xmonad loses first hotkey sometimes http://code.google.com/p/xmonad/issues/detail?id=576 I would like to see the full truss output. You can, however, clean it up a bit by building your custom xmonad manually (see http://xmonad.org/xmonad-docs/xmonad/src/XMonad-Core.html#recompile) with the ghc options: -rtsopts -with-rtsopts -v0 which will disable the runtime system's GC timer (it will GC on all allocations instead, which can slow programs down a bit) and remove the itimer and SIGALRM from the trace. -- 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 From codesite-noreply at google.com Sun Aug 10 08:09:57 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Sun, 10 Aug 2014 08:09:57 +0000 Subject: [xmonad] Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes In-Reply-To: <7-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> References: <7-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Message-ID: <8-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Comment #8 on issue 576 by martin.s... at gmail.com: On FreeBSD Xmonad loses first hotkey sometimes http://code.google.com/p/xmonad/issues/detail?id=576 Here are the both xz-compressed truss output files (the one where the xterm starts is quite hard to produce). mod-shift-return-ignored.truss.txt -> Key binding did not work mod-shift-return-ok.truss.txt -> Key binding worked (some noise at the end, closing the window) Attachments: mod-shift-return-ignored.truss.txt.xz 884 bytes mod-shift-return-ok.truss.txt.xz 33.6 KB -- 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 From klaas at vanschelven.com Tue Aug 12 07:24:04 2014 From: klaas at vanschelven.com (Klaas van Schelven) Date: Tue, 12 Aug 2014 09:24:04 +0200 Subject: [xmonad] Bug? garbage screen when switching virtual workspaces. Message-ID: I suppose I should start with a rant on how XMonad sucks to get everyone's attention. However, truth is I've been enjoying xmonad for some c. 5 years now, without any problems whatsoever. However: I've recently upgraded my Ubuntu from 10.04 to 14.04. Xmonad appeared to work after changing the syntax of dmenu_run and recompiling. However, sometimes when switching workspaces, I end up with with some garbage window with the following properties: * slightly offset to the bottom & right from the normal location (slightly means: a couple of pixels) * the area usually contains the contents of the window that was displaying right before making the switch (but as I set, slightly offset to the right & bottom) * usually the window is killable using my standard kill-key-combo. * It appears (though I'm not sure) that google-chrome if often involved in this. One observed behavior: after killing the "ghost window" everything seemed to work fine again, except that chrome was gone. Tentative conclusion: the ghost window was in fact chrome. * My "unfloat" modifier (Mod-T) doesn't change anything When observing the above, I just run windows full screen and use various workspaces for the various windows. * A behavior that appears related: in a few cases I did not manage to get rid of the ghost window. In those cases I got some kind of mosaic inside the full-screen chrome window, comprised of ca. 5 times 5 smaller, mirrored rectangles which contained part of chrome. I'll try to make a screenshot next time this happens. I'm sorry if the problem description is somewhat vague, and/or if I'm not using the correct terminology. As I said, I've set up XMonad years ago, and haven't changed a thing since so I'm somewhat lost for the right words at times (the correct terminology is in my fingers) Any pointers to debugging this problem or requests for specifc configs/logs are welcome. regards, Klaas -------------- next part -------------- An HTML attachment was scrubbed... URL: From ruslan.kiianchuk at gmail.com Sun Aug 17 00:06:19 2014 From: ruslan.kiianchuk at gmail.com (Ruslan Kiianchuk) Date: Sat, 16 Aug 2014 17:06:19 -0700 Subject: [xmonad] Dim unfocused windows Message-ID: Hello. So there is XMonad.Hooks.FadeWindows module that allows to make unfocused windows slightly transparent. But is it possible to just dim unfocused windows without changing their opacity (the way fadeing option does this for URXVT?). Thanks. -- Sincerely, Ruslan Kiianchuk. -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Sun Aug 17 00:14:41 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 16 Aug 2014 20:14:41 -0400 Subject: [xmonad] Dim unfocused windows In-Reply-To: References: Message-ID: On Sat, Aug 16, 2014 at 8:06 PM, Ruslan Kiianchuk < ruslan.kiianchuk at gmail.com> wrote: > So there is XMonad.Hooks.FadeWindows > > module that allows to make unfocused windows slightly transparent. > > But is it possible to just dim unfocused windows without changing their > opacity (the way fadeing option does this for URXVT?). > Not without specific support in the compositing manager (or the application owning the window, as with urxvt). You may want to look at recent versions of compton (may need to build from git instead of using an OS package); while it doesn't seem to support a window property such as xmonad uses to communicate with compositing managers --- and if it did, you'd need to make a local copy of FadeInactive referring to the new property, *and* a local copy of FadeWindows so it links against your local FadeInactive, if you use that --- it can do inactive-dim itself with appropriate options. (I use: compton -cCfGb --inactive-dim=0.4 --detect-transient --use-ewmh-active-win --backend=glx) -- 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: From ruslan.kiianchuk at gmail.com Sun Aug 17 04:41:29 2014 From: ruslan.kiianchuk at gmail.com (Ruslan Kiianchuk) Date: Sat, 16 Aug 2014 21:41:29 -0700 Subject: [xmonad] Dim unfocused windows In-Reply-To: References: Message-ID: On Sat, Aug 16, 2014 at 5:14 PM, Brandon Allbery wrote: > compton -cCfGb --inactive-dim=0.4 --detect-transient --use-ewmh-active-win > --backend=glx Thanks a lot for the hint, compton works out great! Moved from old xcompmgr now. -- Sincerely, Ruslan Kiianchuk. -------------- next part -------------- An HTML attachment was scrubbed... URL: From codesite-noreply at google.com Mon Aug 18 07:26:30 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Mon, 18 Aug 2014 07:26:30 +0000 Subject: [xmonad] Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes In-Reply-To: <8-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> References: <8-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Message-ID: <9-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Comment #9 on issue 576 by beyer... at gmail.com: On FreeBSD Xmonad loses first hotkey sometimes http://code.google.com/p/xmonad/issues/detail?id=576 I'm also on FreeBSD, and while I haven't debugged the issue formally, I can say that they execute more reliably (haven't seen any issues since) when spawned inside tcsh. First I tried something like the following: I converted: spawn "dmenu_run" to spawn "tcsh -c 'dmenu_run'" Then, I decided to dig into the definition of spawn, and then I made an alternate version of spawn instead... eg like the following: -- | spawn. Launch an external application. Specifically, it double-forks and -- runs the 'String' you pass as a command to \/bin\/sh. -- -- Note this function assumes your locale uses utf8. spawn' :: MonadIO m => String -> m () spawn' x = spawnPIDTCSH x >> return () -- | Like 'spawn', but returns the 'ProcessID' of the launched application spawnPIDTCSH :: MonadIO m => String -> m ProcessID spawnPIDTCSH x = xfork $ executeFile "/bin/tcsh" False ["-c", encodeString x] Nothing Now, when I execute something like spawn' "dmenu_run" It works reliably. Hope this helps, although you might be experiencing a different issue. Regards, Tim -- 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 From codesite-noreply at google.com Tue Aug 19 14:37:17 2014 From: codesite-noreply at google.com (codesite-noreply at google.com) Date: Tue, 19 Aug 2014 14:37:17 +0000 Subject: [xmonad] Issue 576 in xmonad: On FreeBSD Xmonad loses first hotkey sometimes In-Reply-To: <9-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> References: <9-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> <0-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Message-ID: <10-3425899027203913298-6692653904601061105-codesite-noreply=google.com@googlecode.com> Comment #10 on issue 576 by martin.s... at gmail.com: On FreeBSD Xmonad loses first hotkey sometimes http://code.google.com/p/xmonad/issues/detail?id=576 Yes. Indeed this workaround using tcsh appears to help. I haven't tested it very extensively, yet, but the main symptoms are gone. I still suspect that it is some kind of race condition with timers/signals. Maybe the startup of /bin/sh is very fast on FreeBSD. Cannot tell for sure what's going on. I also compiled with "-rtsopts -with-rtsopts -v0" (I checked ps output during compilation if it really uses the flags). It did not improve anything and did not make truss faster (still listing setitimer, alarms etc). I am getting just about the same output as above. Btw, FreeBSD upgraded to GHC 7.8.3 a few days ago and the problem persists. Tim's workaround still helps here. -- 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 From cwbell at mail.usf.edu Mon Aug 25 17:11:25 2014 From: cwbell at mail.usf.edu (Chris Bell) Date: Mon, 25 Aug 2014 13:11:25 -0400 Subject: [xmonad] Per-workspace Application Instances Message-ID: Hi all, I started using xmonad last week, and encountered very few problems during configuration and use. It's nearly perfect for how I work. But I've run into a bothersome issue. There are times when I need to have dozens of PDFs readily available. Since I started using xmonad, I switched to qpdfview for its tabbed interface. Whenever I open a PDF from a file manager (xfe), qpdfview is called with the --unique option, so that all new windows open as tabs in the main window. The problem is that, if I want to then open a PDF on a different workspace, I either need to create a new instance of qpdfview, or use a different PDF viewer. A minor inconvenience, to be sure. But then I realized that qpdfview has a --instance option, which I imagine could be used with xmonad's workspace identifiers. So, any instance started in workspace 3 would be named 'd3', and qpdfview would be called with '--unique --instance d3'. The problem is, I don't know where to start with this. My idea was to use environment variables to identify the current workspace, but I'm not sure how to. Any suggestions/ideas are greatly appreciated! Regards, Chris From allbery.b at gmail.com Mon Aug 25 17:20:56 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 25 Aug 2014 13:20:56 -0400 Subject: [xmonad] Per-workspace Application Instances In-Reply-To: References: Message-ID: On Mon, Aug 25, 2014 at 1:11 PM, Chris Bell wrote: > The problem is, I don't know where to start with this. My idea was to > use environment variables to identify the current workspace, but I'm > not sure how to. Any suggestions/ideas are greatly appreciated! > Add EwmhDesktops to your config and use wmctrl or xprop -root to get the current desktop. Both will require processing the output: "wmctrl -d" indicates the current desktop with an asterisk and "xprop -root -notype _NET_CURRENT_DESKTOP" includes the property name. -- 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: From allbery.b at gmail.com Mon Aug 25 17:22:22 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 25 Aug 2014 13:22:22 -0400 Subject: [xmonad] Per-workspace Application Instances In-Reply-To: References: Message-ID: On Mon, Aug 25, 2014 at 1:11 PM, Chris Bell wrote: > The problem is, I don't know where to start with this. My idea was to > use environment variables to identify the current workspace, but I'm > not sure how to. > Also note that environment variables will not work if you expect to see them in e.g. shells; they're inherited at process creation time and cannot be updated by other processes afterward. -- 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: From cwbell at mail.usf.edu Mon Aug 25 18:10:01 2014 From: cwbell at mail.usf.edu (Chris Bell) Date: Mon, 25 Aug 2014 14:10:01 -0400 Subject: [xmonad] Per-workspace Application Instances In-Reply-To: References: Message-ID: On Mon, Aug 25, 2014 at 1:22 PM, Brandon Allbery wrote: > Also note that environment variables will not work if you expect to see them > in e.g. shells; they're inherited at process creation time and cannot be > updated by other processes afterward. I know, but i figured it was better than the current situation. I'd just have to remember the limitation. On Mon, Aug 25, 2014 at 1:20 PM, Brandon Allbery wrote: > Add EwmhDesktops to your config and use wmctrl or xprop -root to get the > current desktop. Both will require processing the output: "wmctrl -d" > indicates the current desktop with an asterisk and "xprop -root -notype > _NET_CURRENT_DESKTOP" includes the property name. This is an awesome solution. Thank you so very, very much. I ended up using `wmctrl -d | egrep \* | cut -b 1` to get the workspace index, and created a shell script to munge everything together. Result: each workspace works with its own qpdfview instance. Thanks again! Chris From anton at enomsg.org Thu Aug 28 18:07:22 2014 From: anton at enomsg.org (Anton Vorontsov) Date: Thu, 28 Aug 2014 18:07:22 -0000 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving Message-ID: It seems that my last email got silently eaten by spam filters. It's been a whole day, so let's try it again with a different smtp... 1 patch for repository http://code.haskell.org/XMonadContrib: Wed Aug 27 15:02:19 PDT 2014 Anton Vorontsov * 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, as soon as the workspace is hidden the web browser will be stopped. 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-preview.txt Type: text/x-darcs-patch Size: 5342 bytes Desc: Patch preview URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: add-stoppable-layout-for-power-saving.dpatch Type: application/x-darcs-patch Size: 22083 bytes Desc: A darcs patch for your repository! URL: From allbery.b at gmail.com Thu Aug 28 18:14:03 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 28 Aug 2014 14:14:03 -0400 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving In-Reply-To: <20140828180724.E3D8810DC9@haskell.org> References: <20140828180724.E3D8810DC9@haskell.org> Message-ID: On Thu, Aug 28, 2014 at 2:07 PM, Anton Vorontsov wrote: > To stop the process we use signals, which works for most cases. Please check WM_CLIENT_MACHINE so you don't try to kill a process not running on the same machine xmonad is (ssh forwarding, TCP X server connections, etc.) -- 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: From fercerpav at gmail.com Thu Aug 28 19:00:28 2014 From: fercerpav at gmail.com (Paul Fertser) Date: Thu, 28 Aug 2014 23:00:28 +0400 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving In-Reply-To: <20140828180724.E3D8810DC9@haskell.org> References: <20140828180724.E3D8810DC9@haskell.org> Message-ID: <20140828190028.GE6339@home.lan> Great idea, Anton! Handy for the shit-sites that make firefox spin violently even when it's not visible! On Thu, Aug 28, 2014 at 06:07:24PM +0000, Anton Vorontsov wrote: > +-- > main = xmonad def > +-- > { layoutHook = layoutHook def ||| stoppable (layoutHook def) } > +-- > +-- For more detailed instructions on editing the logHook see: > +-- > +-- "XMonad.Doc.Extending#The_log_hook_and_external_status_bars" Why is that you're talking about modifying the logHook when tweaking layoutHook, is this a typo? -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav at gmail.com From anton at enomsg.org Thu Aug 28 20:11:53 2014 From: anton at enomsg.org (Anton Vorontsov) Date: Thu, 28 Aug 2014 13:11:53 -0700 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving In-Reply-To: References: <20140828180724.E3D8810DC9@haskell.org> Message-ID: <20140828201123.GA28562@teo..cn> On Thu, Aug 28, 2014 at 02:14:03PM -0400, Brandon Allbery wrote: > On Thu, Aug 28, 2014 at 2:07 PM, Anton Vorontsov wrote: > > To stop the process we use signals, which works for most cases. > > Please check WM_CLIENT_MACHINE so you don't try to kill a process not > running on the same machine xmonad is (ssh forwarding, TCP X server > connections, etc.) Yeah, totally makes sense -- I probably don't want to stop random local processes that happen to share same PID with remote X clients... :) I'll wait a day or so before resending the full patch, in case there's more feedback. In the mean time, inlined below are the changes that I'll incorporate. I'm using the environment variable as I am not sure if introducing new cabal dependency (hostname package) is a good idea, plus I see some other xmonad code uses getEnv approach as well... Thanks, Anton diff -rN -u old-XMonadContrib/XMonad/Layout/Stoppable.hs new-XMonadContrib/XMonad/Layout/Stoppable.hs --- old-XMonadContrib/XMonad/Layout/Stoppable.hs 2014-08-28 12:48:56.397898832 -0700 +++ new-XMonadContrib/XMonad/Layout/Stoppable.hs 2014-08-28 12:48:56.400898832 -0700 @@ -38,11 +38,13 @@ import XMonad import XMonad.Actions.WithAll -import XMonad.Util.WindowProperties (getProp32s) +import XMonad.Util.WindowProperties import XMonad.StackSet hiding (filter) import XMonad.Layout.LayoutModifier +import System.Posix.Env import System.Posix.Signals import Data.Maybe +import Control.Monad -- $usage -- You can use this module with the following in your @~\/.xmonad\/xmonad.hs@: @@ -62,6 +64,11 @@ pid <- getProp32s "_NET_WM_PID" w io $ (signalProcess s . fromIntegral) `mapM_` fromMaybe [] pid +signalLocalWindow :: Signal -> Window -> X () +signalLocalWindow s w = do + host <- io $ getEnvDefault "HOSTNAME" "" + hasProperty (Machine host) w >>= flip when (signalWindow s w) + withAllOn :: (a -> X ()) -> Workspace i l a -> X () withAllOn f wspc = f `mapM_` integrate' (stack wspc) @@ -73,7 +80,7 @@ sigStoppableWorkspacesHook :: String -> X () sigStoppableWorkspacesHook k = do ws <- gets windowset - withAllFiltered isStoppable (hidden ws) (signalWindow sigSTOP) + withAllFiltered isStoppable (hidden ws) (signalLocalWindow sigSTOP) where isStoppable ws = k `elem` words (description $ layout ws) @@ -84,7 +91,7 @@ instance LayoutModifier Stoppable Window where modifierDescription = mark - hook _ = withAll $ signalWindow sigCONT + hook _ = withAll $ signalLocalWindow sigCONT unhook l = sigStoppableWorkspacesHook (mark l) -- | Convert a layout to a stoppable layout using the default mark From anton at enomsg.org Thu Aug 28 20:12:31 2014 From: anton at enomsg.org (Anton Vorontsov) Date: Thu, 28 Aug 2014 13:12:31 -0700 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving In-Reply-To: <20140828190028.GE6339@home.lan> References: <20140828180724.E3D8810DC9@haskell.org> <20140828190028.GE6339@home.lan> Message-ID: <20140828201231.GA28676@teo..cn> 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. > On Thu, Aug 28, 2014 at 06:07:24PM +0000, Anton Vorontsov wrote: > > +-- > main = xmonad def > > +-- > { layoutHook = layoutHook def ||| stoppable (layoutHook def) } > > +-- > > +-- For more detailed instructions on editing the logHook see: > > +-- > > +-- "XMonad.Doc.Extending#The_log_hook_and_external_status_bars" > > Why is that you're talking about modifying the logHook when tweaking > layoutHook, is this a typo? I started prototyping with logHook, but then realized I'd better switch to layout, and then didn't change the boiler plate. Thanks for catching! Anton From eniotna.t at gmail.com Thu Aug 28 20:25:50 2014 From: eniotna.t at gmail.com (ardumont) Date: Thu, 28 Aug 2014 22:25:50 +0200 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <871ttcflbd.fsf@gmail.com> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> Message-ID: <87y4u8z7ht.fsf@gmail.com> Hello, Is there no one interested, ever? Cheers, ardumont writes: > Hello, > > So I updated the code according to our last exchange. > > Enclosed in this email, you will find the amended patch. > > The documentation has been updated as well: > > #+begin_src doc > This module provides 3 XMonad.Prompt to ease passwords manipulation (generate, read, remove): > > one to lookup passwords in the password-storage. > one to generate a password for a given password label that the user inputs. > one to delete a stored password for a given password label that the user inputs. > > All those prompts benefit from the completion system provided by the module XMonad.Prompt. > > The password store is setuped through an environment variable PASSWORD_STORE_DIR. If this is set, use the content of the variable. Otherwise, the password store is located on user's home $HOME/.password-store. > > Source: > > The password storage implementation is the password-store cli. > Inspired from http://babushk.in/posts/combining-xmonad-and-pass.html > > Synopsis > #+end_src > > An insight about I tested this, I modified my xmonad.hs and reloaded xmonad: > - without the environment variable. Pass does look into the > `~/.password-store`. I have completion proposed on the prompt (my > password store is stored there) > - with the environment variable (in xmonad's main function, I added an > ugly `System.Posix.setEnv "PASSWORD_STORE_DIR" "/home/tony" True`. I > have no completion on the prompt because there is nothing there. > > Cheers, > > Daniel Schoepe writes: > >> Hi, >> >> On Tue, 22.07.2014 17:36 +0200, ardumont wrote: >>> I propose to improve the existing code with the first implementation suggestion as >>> a first step. >>> n>>> And then, if it is approved and merged, see what users say about it. >>> What do you think? >> >> sounds good to me. >> >> Best regards, >> Daniel > > > -- > @ardumont -- @ardumont From daniel at schoepe.org Thu Aug 28 21:31:18 2014 From: daniel at schoepe.org (Daniel Schoepe) Date: Thu, 28 Aug 2014 23:31:18 +0200 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <871ttcflbd.fsf@gmail.com> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> Message-ID: <87d2bkjo7t.fsf@schoepe.localhost> Hi again, I'm very sorry that it took so long for me to respond. The patch looks good now; however it causes a conflict with a change to the cabal file (just some trivial formatting stuff). The dependency on filepath is fine since it's a library that's shipped with GHC anyway (and xmonad depends on it already), so you can remove that comment on that import statement from the patch. If you resubmit the patch with the comment removed and the conflict resolved, I'll apply it ASAP and I promise it won't take a month this time. :) PS: Could you also provide a more verbose commit message for the patch? Cheers, Daniel On Wed, 23 Jul 2014 11:58 +0200, ardumont wrote: > Hello, > > So I updated the code according to our last exchange. > > Enclosed in this email, you will find the amended patch. > > The documentation has been updated as well: > > #+begin_src doc > This module provides 3 XMonad.Prompt to ease passwords manipulation (generate, read, remove): > > one to lookup passwords in the password-storage. > one to generate a password for a given password label that the user inputs. > one to delete a stored password for a given password label that the user inputs. > > All those prompts benefit from the completion system provided by the module XMonad.Prompt. > > The password store is setuped through an environment variable PASSWORD_STORE_DIR. If this is set, use the content of the variable. Otherwise, the password store is located on user's home $HOME/.password-store. > > Source: > > The password storage implementation is the password-store cli. > Inspired from http://babushk.in/posts/combining-xmonad-and-pass.html > > Synopsis > #+end_src > > An insight about I tested this, I modified my xmonad.hs and reloaded xmonad: > - without the environment variable. Pass does look into the > `~/.password-store`. I have completion proposed on the prompt (my > password store is stored there) > - with the environment variable (in xmonad's main function, I added an > ugly `System.Posix.setEnv "PASSWORD_STORE_DIR" "/home/tony" True`. I > have no completion on the prompt because there is nothing there. > > Cheers, > > Daniel Schoepe writes: > >> Hi, >> >> On Tue, 22.07.2014 17:36 +0200, ardumont wrote: >>> I propose to improve the existing code with the first implementation suggestion as >>> a first step. >>> >>> And then, if it is approved and merged, see what users say about it. >>> What do you think? >> >> sounds good to me. >> >> Best regards, >> Daniel > > > -- > @ardumont From eniotna.t at gmail.com Fri Aug 29 11:56:44 2014 From: eniotna.t at gmail.com (ardumont) Date: Fri, 29 Aug 2014 13:56:44 +0200 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <87d2bkjo7t.fsf@schoepe.localhost> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> Message-ID: <87lhq7ecg3.fsf@gmail.com> Hello, Daniel Schoepe writes: > Hi again, > > I'm very sorry that it took so long for me to respond. The patch looks > good now; however it causes a conflict with a change to the cabal file > (just some trivial formatting stuff). No problem. > > The dependency on filepath is fine since it's a library that's shipped > with GHC anyway (and xmonad depends on it already), so you can remove > that comment on that import statement from the patch. Ok good to know. I'll remove them then. > > If you resubmit the patch with the comment removed and the conflict > resolved, I'll apply it ASAP and I promise it won't take a month this > time. :) Ok, cool. I just need to adapt the code and amend the patch right? > > PS: Could you also provide a more verbose commit message for the > patch? Is it ok for you if I use the documentation description for the commit message then? Cheers, Antoine > > Cheers, > Daniel > > On Wed, 23 Jul 2014 11:58 +0200, ardumont wrote: >> Hello, >> >> So I updated the code according to our last exchange. >> >> Enclosed in this email, you will find the amended patch. >> >> The documentation has been updated as well: >> >> #+begin_src doc >> This module provides 3 XMonad.Prompt to ease passwords manipulation (generate, read, remove): >> >> one to lookup passwords in the password-storage. >> one to generate a password for a given password label that the user inputs. >> one to delete a stored password for a given password label that the user inputs. >> >> All those prompts benefit from the completion system provided by the module XMonad.Prompt. >> >> The password store is setuped through an environment variable PASSWORD_STORE_DIR. If this is set, use the content of the variable. Otherwise, the password store is located on user's home $HOME/.password-store. >> >> Source: >> >> The password storage implementation is the password-store cli. >> Inspired from http://babushk.in/posts/combining-xmonad-and-pass.html >> >> Synopsis >> #+end_src >> >> An insight about I tested this, I modified my xmonad.hs and reloaded xmonad: >> - without the environment variable. Pass does look into the >> `~/.password-store`. I have completion proposed on the prompt (my >> password store is stored there) >> - with the environment variable (in xmonad's main function, I added an >> ugly `System.Posix.setEnv "PASSWORD_STORE_DIR" "/home/tony" True`. I >> have no completion on the prompt because there is nothing there. >> >> Cheers, >> >> Daniel Schoepe writes: >> >>> Hi, >>> >>> On Tue, 22.07.2014 17:36 +0200, ardumont wrote: >>>> I propose to improve the existing code with the first implementation suggestion as >>>> a first step. >>>> >>>> And then, if it is approved and merged, see what users say about it. >>>> What do you think? >>> >>> sounds good to me. >>> >>> Best regards, >>> Daniel >> >> >> -- >> @ardumont -- @ardumont From eniotna.t at gmail.com Fri Aug 29 14:26:19 2014 From: eniotna.t at gmail.com (ardumont) Date: Fri, 29 Aug 2014 16:26:19 +0200 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <87lhq7ecg3.fsf@gmail.com> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> Message-ID: <87iolbe5is.fsf@gmail.com> Hello, Here is the latest patch according to remarks. -------------- next part -------------- A non-text attachment was scrubbed... Name: new-xmonad-prompt-patch.dpatch Type: test/x-patch Size: 24514 bytes Desc: new-xmonad-prompt-pass.dpatch URL: -------------- next part -------------- Below I detail some steps I took. Hope everything is alright. Thanks for your time. ardumont writes: > Hello, > > Daniel Schoepe writes: > >> Hi again, >> >> I'm very sorry that it took so long for me to respond. The patch looks >> good now; however it causes a conflict with a change to the cabal file >> (just some trivial formatting stuff). > > No problem. > >> >> The dependency on filepath is fine since it's a library that's shipped >> with GHC anyway (and xmonad depends on it already), so you can remove >> that comment on that import statement from the patch. > > Ok good to know. I'll remove them then. > >> >> If you resubmit the patch with the comment removed and the conflict >> resolved, I'll apply it ASAP and I promise it won't take a month this >> time. :) > > Ok, cool. > > I just need to adapt the code and amend the patch right? Actually I did (I am not darcs fluent yet), from XMonadContrib local repository: - darcs unrecord # only my last patch without touching anything - darcs revert # to revert only some part of my last working copy - darcs pull # to fetch and apply the new patches - # undid to take into account what you asked for - cabal install - # reload xmonad configuration - https://github.com/ardumont/dot-files/blob/use-xmonad-prompt-pass/.xmonad/xmonad.hs#L183 - # check everything still works as before (it does!) - darcs record - darcs send -o new-xmonad-prompt-patch.dpatch > >> >> PS: Could you also provide a more verbose commit message for the >> patch? > > Is it ok for you if I use the documentation description for the commit > message then? > I did that. > Cheers, > Antoine >> >> Cheers, >> Daniel >> >> On Wed, 23 Jul 2014 11:58 +0200, ardumont wrote: >>> Hello, >>> >>> So I updated the code according to our last exchange. >>> >>> Enclosed in this email, you will find the amended patch. >>> >>> The documentation has been updated as well: >>> >>> #+begin_src doc >>> This module provides 3 XMonad.Prompt to ease passwords manipulation (generate, read, remove): >>> >>> one to lookup passwords in the password-storage. >>> one to generate a password for a given password label that the user inputs. >>> one to delete a stored password for a given password label that the user inputs. >>> >>> All those prompts benefit from the completion system provided by the module XMonad.Prompt. >>> >>> The password store is setuped through an environment variable PASSWORD_STORE_DIR. If this is set, use the content of the variable. Otherwise, the password store is located on user's home $HOME/.password-store. >>> >>> Source: >>> >>> The password storage implementation is the password-store cli. >>> Inspired from http://babushk.in/posts/combining-xmonad-and-pass.html >>> >>> Synopsis >>> #+end_src >>> >>> An insight about I tested this, I modified my xmonad.hs and reloaded xmonad: >>> - without the environment variable. Pass does look into the >>> `~/.password-store`. I have completion proposed on the prompt (my >>> password store is stored there) >>> - with the environment variable (in xmonad's main function, I added an >>> ugly `System.Posix.setEnv "PASSWORD_STORE_DIR" "/home/tony" True`. I >>> have no completion on the prompt because there is nothing there. >>> >>> Cheers, >>> >>> Daniel Schoepe writes: >>> >>>> Hi, >>>> >>>> On Tue, 22.07.2014 17:36 +0200, ardumont wrote: >>>>> I propose to improve the existing code with the first implementation suggestion as >>>>> a first step. >>>>> >>>>> And then, if it is approved and merged, see what users say about it. >>>>> What do you think? >>>> >>>> sounds good to me. >>>> >>>> Best regards, >>>> Daniel >>> >>> >>> -- >>> @ardumont > > > -- > @ardumont Cheers, -- @ardumont From zev at bewilderbeest.net Fri Aug 29 15:55:32 2014 From: zev at bewilderbeest.net (Zev Weiss) Date: Fri, 29 Aug 2014 10:55:32 -0500 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <87iolbe5is.fsf@gmail.com> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> Message-ID: <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> On Aug 29, 2014, at 9:26 AM, ardumont wrote: > Hello, > > Here is the latest patch according to remarks. > > > Below I detail some steps I took. > > Hope everything is alright. > > Thanks for your time. > Hi, Much as I hate to be a wet blanket here (and obviously don't speak from a position of any authority or influence on xmonad), I'd just like to voice my from-the-sidelines preference that this patch *not* be applied. This is not due to any objection to the patch itself, nor to the functionality it adds (which I think could be quite genuinely useful), but rather to the 'pass' tool itself. From the description on its web site (http://www.passwordstore.org/), it seems in my opinion rather poorly designed. The biggest (or at least most immediately obvious) problem is that keeping separate files/directories for each password (which I guess it doesn't strictly require, but is clearly geared toward) is a *massive* and completely unnecessary information leak. Further, its dependencies (http://git.zx2c4.com/password-store/tree/README#n15) seem to me rather bulky for something that should/could be a very simple, lightweight thing. (Also, the hubris of its author immediately declaring it "standard" is rather off-putting, and actually kind of laughable given how obviously-not-a-standard it is -- perhaps that's just some dry humour, but I get the sense it's meant sincerely.) If an alternate backend that didn't have these problems could be used to provide this xmonad interface instead I'd be all for it -- but as is I'm opposed to it if only on the grounds of it serving to encourage further adoption of 'pass', which I simply think is a bad idea. Thanks, Zev Weiss From fercerpav at gmail.com Fri Aug 29 17:10:19 2014 From: fercerpav at gmail.com (Paul Fertser) Date: Fri, 29 Aug 2014 21:10:19 +0400 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving In-Reply-To: <53ff8d35.815f460a.6962.66daSMTPIN_ADDED_BROKEN@mx.google.com> References: <20140828180724.E3D8810DC9@haskell.org> <20140828190028.GE6339@home.lan> <53ff8d35.815f460a.6962.66daSMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: <20140829171019.GH6339@home.lan> 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 at gmail.com From eniotna.t at gmail.com Fri Aug 29 17:56:10 2014 From: eniotna.t at gmail.com (ardumont) Date: Fri, 29 Aug 2014 19:56:10 +0200 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> Message-ID: <87ha0vdvt1.fsf@gmail.com> Hello Zev, Zev Weiss writes: > On Aug 29, 2014, at 9:26 AM, ardumont wrote: > >> Hello, >> >> Here is the latest patch according to remarks. >> >> >> Below I detail some steps I took. >> >> Hope everything is alright. >> >> Thanks for your time. >> > > Hi, > > Much as I hate to be a wet blanket here I learned a new expression, thanks. > (and obviously don't speak from a position of any authority or > influence on xmonad), I'd just like to voice my from-the-sidelines > preference that this patch *not* be applied. It would have been good to hear this before I patched it thrice. :D > > This is not due to any objection to the patch itself, nor to the > functionality it adds (which I think could be quite genuinely useful), Good. >but rather to the 'pass' tool itself. From the description on its web > site (http://www.passwordstore.org/), it seems in my opinion rather > poorly designed. The biggest (or at least most immediately obvious) > problem is that keeping separate files/directories for each password > (which I guess it doesn't strictly require, but is clearly geared > toward) is a *massive* and completely unnecessary information leak. Do not use it online then. > Further, its dependencies > (http://git.zx2c4.com/password-store/tree/README#n15) seem to me > rather bulky for something that should/could be a very simple, > lightweight thing. I think it simply aligns with the the Unix' sphilosophy to reuse what's already there. Using brick composition to provide higher functionalities. In that way of seeing thing, this sounds standard to me. > (Also, the hubris Yet another new expression, thanks. > of its author immediately declaring it "standard" is > rather off-putting, and actually kind of laughable given how > obviously-not-a-standard it is -- It's all perception. For example, I for one, dislike the term `obvious` (even more in my native language which sounds pretentious). So I become suspicious when people uses it (and you used it twice already). I am sorry but nothing for me is that `apparent` except that you sound pretty much like what you described. Like I said perception. In any case, how is it apparent for you that this is not standard? It's free software, and it's available for multiple GNU/Linux distributions (even some are not referenced, NixOS for one), Mac OS X and FreeBSD. (from its dependencies, it seems there may be even ways to make it work on windows platform, though it's not referenced.) Yet other qualities that sounds standard to me. > perhaps that's just some dry humour, > but I get the sense it's meant sincerely.) > > If an alternate backend that didn't have these problems could be used > to provide this xmonad interface instead I'd be all for it I provided something to start with, you may provide an alternate backend (if you know some or intend to write some) from there. The code is attached to this thread if you want to improve on it, feel free. > -- but as is I'm opposed to it if only on the grounds of it serving to > encourage further adoption of 'pass', It is not my intention to encourage further adoption of pass. I thought this use case was very interesting and tried it. I got confident about it being useful. And as it did not exist on xmonad-contrib, acted on it to permit others to benefit from it. > which I simply think is a bad > idea. > > > Thanks, Thanks too > Zev Weiss Cheers, -- @ardumont From mlists at pmade.com Fri Aug 29 18:09:04 2014 From: mlists at pmade.com (Peter Jones) Date: Fri, 29 Aug 2014 12:09:04 -0600 Subject: [xmonad] XMonad.Prompt.Pass patch References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> <87ha0vdvt1.fsf@gmail.com> Message-ID: <87ha0v88xr.fsf@pmade.com> ardumont writes: > In any case, how is it apparent for you that this is not standard? It's not a default package on any distro that I'm aware of. Since your contribution depends on a non-standard package I think it would fit in better with xmonad-extras: https://hackage.haskell.org/package/xmonad-extras -- Peter Jones, Founder, Devalot.com Defending the honor of good code From eniotna.t at gmail.com Fri Aug 29 19:31:37 2014 From: eniotna.t at gmail.com (ardumont) Date: Fri, 29 Aug 2014 21:31:37 +0200 Subject: [xmonad] XMonad.Prompt.Pass patch In-Reply-To: <87ha0v88xr.fsf@pmade.com> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> <87ha0vdvt1.fsf@gmail.com> <87ha0v88xr.fsf@pmade.com> Message-ID: <87vbpb9jom.fsf@gmail.com> Peter Jones writes: > ardumont writes: >> In any case, how is it apparent for you that this is not standard? > > It's not a default package on any distro that I'm aware of. ? Like I said, from pass's documentation (I just added the links): - Ubuntu - https://launchpad.net/ubuntu/+source/password-store - Debian - https://packages.debian.org/source/sid/password-store - Gentoo - http://packages.gentoo.org/?search=pass&bgresponse= - Arch - https://www.archlinux.org/packages/community/any/pass/ - NixOS - https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/security/pass/default.nix#L17 - FreeBSD - http://svnweb.freebsd.org/ports/head/sysutils/password-store/ - ... This is all `default` (it's in the main repository distribution) so I do not understand. Also, I believe those distributions are the main linux families (every other in a way or another deriving from one of those). So I must misunderstand the term `default` package, can you explicit it for me? > Since your contribution depends on a non-standard package Can you please, clarify the term non-standard package? > I think it would fit in better with xmonad-extras: > > https://hackage.haskell.org/package/xmonad-extra I was not aware of this (I must have missed it on the main site). >From the definition `Various modules for xmonad that cannot be added to xmonad-contrib because of additional dependencies.` pass is indeed an additional dependencies so it seems completely reasonable. Thanks. Cheers, -- @ardumont From anton at enomsg.org Fri Aug 29 19:34:59 2014 From: anton at enomsg.org (Anton Vorontsov) Date: Fri, 29 Aug 2014 12:34:59 -0700 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving In-Reply-To: <20140829171019.GH6339@home.lan> References: <20140828180724.E3D8810DC9@haskell.org> <20140828190028.GE6339@home.lan> <53ff8d35.815f460a.6962.66daSMTPIN_ADDED_BROKEN@mx.google.com> <20140829171019.GH6339@home.lan> Message-ID: <20140829193459.GA19230@d1stkfactory> On Fri, Aug 29, 2014 at 09:10:19PM +0400, Paul Fertser wrote: > 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. Yea, this is pretty much how X11's clipboard works. In case of pasting I kinda used to revert to stoppable workspace momentary, so that stopped application had a chance to transfer things. I was also thinking of making a delay, say 10 seconds before stopping, that will cover most cases and might be a nice additional feature by itself. Thanks, Anton From mlists at pmade.com Fri Aug 29 20:39:08 2014 From: mlists at pmade.com (Peter Jones) Date: Fri, 29 Aug 2014 14:39:08 -0600 Subject: [xmonad] XMonad.Prompt.Pass patch References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> <87ha0vdvt1.fsf@gmail.com> <87ha0v88xr.fsf@pmade.com> <87vbpb9jom.fsf@gmail.com> Message-ID: <87a96n81zn.fsf@pmade.com> ardumont writes: > Like I said, from pass's documentation (I just added the links): - > > [...snip...] > > This is all `default` (it's in the main repository distribution) so I > do not understand. Also, I believe those distributions are the main > linux families (every other in a way or another deriving from one of > those). > > So I must misunderstand the term `default` package, can you explicit it > for me? Maybe I'm splitting hairs but when I think of a "standard" or "default" package I think of things like coreutils that are installed automatically when I installed my operating system. Think about it this way: since xmonad is in the "main repository distribution" for many operating systems, would you call it a "standard" package? Just because I can install a package doesn't mean it's a "standard" package. I'm sure my operating system has dozens of password managers to choose from, just like it has dozens of windows managers. I would only call one of them the "standard" package if it was automatically installed by the base system. -- Peter Jones, Founder, Devalot.com Defending the honor of good code From daniel at schoepe.org Fri Aug 29 20:45:49 2014 From: daniel at schoepe.org (Daniel Schoepe) Date: Fri, 29 Aug 2014 22:45:49 +0200 Subject: [xmonad] XMonad.Prompt.Pass patch In-Reply-To: <87vbpb9jom.fsf@gmail.com> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> <87ha0vdvt1.fsf@gmail.com> <87ha0v88xr.fsf@pmade.com> <87vbpb9jom.fsf@gmail.com> Message-ID: <877g1rm3cy.fsf@schoepe.localhost> Hi, the intention for xmonad-extras was to house modules requiring additional Haskell libraries as dependencies to prevent pulling in a lot of other stuff just for compiling xmonad and xmonad-contrib. This is not a problem here, the module just won't do anything. The same point can be made about all the modules to support dzen-based status bars, (like Util.Dzen), for which dzen is needed for the modules to be useful. In my view, it's up to the user to ensure these binaries are present when they want to use what is clearly a module that's supposed to integrate pass/dzen/whatever with xmonad. Therefore I think that this module can go into contrib. Cheers, Daniel On Fri, 29 Aug 2014 21:31 +0200, ardumont wrote: > Peter Jones writes: > >> ardumont writes: >>> In any case, how is it apparent for you that this is not standard? >> >> It's not a default package on any distro that I'm aware of. > > ? > > Like I said, from pass's documentation (I just added the links): > - Ubuntu - https://launchpad.net/ubuntu/+source/password-store > - Debian - https://packages.debian.org/source/sid/password-store > - Gentoo - http://packages.gentoo.org/?search=pass&bgresponse= > - Arch - https://www.archlinux.org/packages/community/any/pass/ > - NixOS - https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/security/pass/default.nix#L17 > - FreeBSD - http://svnweb.freebsd.org/ports/head/sysutils/password-store/ > - ... > > This is all `default` (it's in the main repository distribution) so I do not understand. > Also, I believe those distributions are the main linux families (every > other in a way or another deriving from one of those). > > So I must misunderstand the term `default` package, can you explicit it > for me? > >> Since your contribution depends on a non-standard package > > Can you please, clarify the term non-standard package? > >> I think it would fit in better with xmonad-extras: >> >> https://hackage.haskell.org/package/xmonad-extra > > I was not aware of this (I must have missed it on the main site). > > From the definition `Various modules for xmonad that cannot be added to > xmonad-contrib because of additional dependencies.` > pass is indeed an additional dependencies so it seems completely reasonable. > > Thanks. > > Cheers, > -- > @ardumont > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://www.haskell.org/mailman/listinfo/xmonad From mlists at pmade.com Fri Aug 29 20:51:32 2014 From: mlists at pmade.com (Peter Jones) Date: Fri, 29 Aug 2014 14:51:32 -0600 Subject: [xmonad] XMonad.Prompt.Pass patch References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> <87ha0vdvt1.fsf@gmail.com> <87ha0v88xr.fsf@pmade.com> <87vbpb9jom.fsf@gmail.com> <877g1rm3cy.fsf@schoepe.localhost> Message-ID: <8761hb81ez.fsf@pmade.com> Daniel Schoepe writes: > the intention for xmonad-extras was to house modules requiring > additional Haskell libraries as dependencies to prevent pulling in a lot > of other stuff just for compiling xmonad and xmonad-contrib. This is not > a problem here, the module just won't do anything. Good point. I concede. -- Peter Jones, Founder, Devalot.com Defending the honor of good code From daniel at schoepe.org Fri Aug 29 21:01:49 2014 From: daniel at schoepe.org (Daniel Schoepe) Date: Fri, 29 Aug 2014 23:01:49 +0200 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> Message-ID: <874mwvm2ma.fsf@schoepe.localhost> Hi, On Fri, 29 Aug 2014 17:55 +0200, Zev Weiss wrote: > The biggest (or at least most immediately obvious) problem is that > keeping separate files/directories for each password (which I guess it > doesn't strictly require, but is clearly geared toward) is a *massive* > and completely unnecessary information leak. I agree, this does leak information, namely the names given to the passwords, as well as their length, if the files contain just the passwords and nothing else. I raised the point about the length on the pass mailing list, but I didn't propose a patch either (http://article.gmane.org/gmane.comp.encryption.pass/766). However, I think that people who use pass are aware of these limitations and based on their assumptions and usage of the tool, they might be okay with them (this includes me). In favour of pass I have to say that I find reusing a well-audited tool like gpg to handle the encryption a lot nicer than rolling your own file format, thereby risking to use encryption primitives incorrectly, etc.. Moreover, the issues in pass can be fixed without changing it's interface, which I prefer to GUI-based password managers. More importantly however, I don't think that it's the job of the window manager libraries to tell the user what applications they should or shouldn't use. I think that there are more people besides me and ardumont who use pass, so I believe that this module is useful to people (I use something very similar to ardumont's Prompt module, based on dmenu). That is reason enough for me to argue for its inclusion. > If an alternate backend that didn't have these problems could be used > to provide this xmonad interface instead I'd be all for it -- but as > is I'm opposed to it if only on the grounds of it serving to encourage > further adoption of 'pass', which I simply think is a bad idea. I think one big part of the "idea" behind pass is that it's a command-line password manager as opposed to a GUI application. Reusing existing tools like gpg to handle encryption is also a good idea. Basically all the issues that I can see that make its current implementation problematic could be solved by encrypting a tar file with the password files instead of the password files themselves. However, given that there is some controversy about this now, I would be happy about other people's opinions on whether or not this should be included. Cheers, Daniel From zev at bewilderbeest.net Sat Aug 30 01:07:34 2014 From: zev at bewilderbeest.net (Zev Weiss) Date: Fri, 29 Aug 2014 20:07:34 -0500 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <87ha0vdvt1.fsf@gmail.com> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> <87ha0vdvt1.fsf@gmail.com> Message-ID: <9A81EF32-CA2F-464F-AF1E-1CD5C7C39DD4@bewilderbeest.net> On Aug 29, 2014, at 12:56 PM, ardumont wrote: > > Hello Zev, > > Zev Weiss writes: > >> On Aug 29, 2014, at 9:26 AM, ardumont wrote: >> >>> Hello, >>> >>> Here is the latest patch according to remarks. >>> >>> >>> Below I detail some steps I took. >>> >>> Hope everything is alright. >>> >>> Thanks for your time. >>> >> >> Hi, >> >> Much as I hate to be a wet blanket here > > I learned a new expression, thanks. > >> (and obviously don't speak from a position of any authority or >> influence on xmonad), I'd just like to voice my from-the-sidelines >> preference that this patch *not* be applied. > > It would have been good to hear this before I patched it thrice. > :D > Sorry about that; for a while it was looking like it was just going to fall through the cracks, so I thought maybe it would be easiest for everyone to just let that happen rather than potentially inciting a flamewar over it (which I'm trying to avoid here...). >> but rather to the 'pass' tool itself. From the description on its web >> site (http://www.passwordstore.org/), it seems in my opinion rather >> poorly designed. The biggest (or at least most immediately obvious) >> problem is that keeping separate files/directories for each password >> (which I guess it doesn't strictly require, but is clearly geared >> toward) is a *massive* and completely unnecessary information leak. > > Do not use it online then. > Huh? If the threat model is that the attacker doesn't have access to the local filesystem, why bother with encryption at all? >> Further, its dependencies >> (http://git.zx2c4.com/password-store/tree/README#n15) seem to me >> rather bulky for something that should/could be a very simple, >> lightweight thing. > > I think it simply aligns with the the Unix' sphilosophy to reuse what's already > there. Using brick composition to provide higher functionalities. > > In that way of seeing thing, this sounds standard to me. > >> (Also, the hubris > > Yet another new expression, thanks. > >> of its author immediately declaring it "standard" is >> rather off-putting, and actually kind of laughable given how >> obviously-not-a-standard it is -- > > It's all perception. > For example, I for one, dislike the term `obvious` (even more in my > native language which sounds pretentious). > So I become suspicious when people uses it (and you used it twice > already). > > I am sorry but nothing for me is that `apparent` except that you sound pretty much like > what you described. > Like I said perception. > > In any case, how is it apparent for you that this is not standard? > > It's free software, and it's available for multiple GNU/Linux distributions (even some are not > referenced, NixOS for one), Mac OS X and FreeBSD. > (from its dependencies, it seems there may be even ways to make it work > on windows platform, though it's not referenced.) > > Yet other qualities that sounds standard to me. > When people say things like "ed is the standard text editor", they're typically (hopefully, if they're using the term correctly) referring to actual, real standards, like SUS. For example, here's the SUS entry for ed: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html If you (or anyone else) can point to a real standard that specifies the inclusion and behavior of 'pass', I'll retract my statement -- though I sincerely doubt such a standard exists. If you want to try get 'pass' into SUS, you can file a bug at http://www.austingroupbugs.net (I won't be holding my breath). There are also so-called "de facto" standards, which are not technically, officially standardized, but whose use is sufficiently widespread that their presence/behavior can to some extent be assumed -- for example in the Haskell world, I think it'd be fair to say that GHC is the de facto standard implementation of the language. Perhaps an even better example would be GCC as the de facto standard in the world of *nix C compilers -- it's not really officially standardized, but is so well-established that other C compilers (Clang, and icc as well I think) are essentially forced to mimic its command-line flags and language extensions if they want to have a chance of seeing any significant real-world use. Here again I don't think 'pass' has anywhere *near* the adoption or general familiarity to have any reasonable ground to stand on in claiming to be even a de facto standard. I for one don't recall having ever once encountered it "in the wild" on any system I've ever logged in to. Availability != adoption, and I'd say widespread adoption is kind of a prerequisite for de facto standardization. And on the issue of dependencies -- I probably should have been a bit clearer there. GPG seems entirely fine here (certainly preferable to hand-rolled-and-probably-buggy crypto, as pointed out by Daniel elsewhere in the thread); I have no objection to that. Implementation as a shell script also doesn't strike me as inherently unreasonable, though if the author's intent is really to create something "standard", I'd think a standard shell (Bourne) would be a much more sensible choice than bash. The rest, however, seem to me to be an assortment of frivolous, unnecessary, and/or absurd stuff. All that said, it of course does not actively *harm* XMonad to have this support, so if the maintainers feel it's a good fit, go right ahead. But from my perspective, all the existing instances I can see of support for external software packages in xmonad{,-contrib} are for substantially better-designed programs. Might pass's contrib/ directory be another (better, in my opinion) place to consider putting this code? Zev From anton at enomsg.org Sat Aug 30 01:41:11 2014 From: anton at enomsg.org (Anton Vorontsov) Date: Sat, 30 Aug 2014 01:41:11 -0000 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving Message-ID: 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 * 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-preview.txt Type: text/x-darcs-patch Size: 6685 bytes Desc: Patch preview URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: add-stoppable-layout-for-power-saving.dpatch Type: application/x-darcs-patch Size: 23426 bytes Desc: A darcs patch for your repository! URL: From eniotna.t at gmail.com Sat Aug 30 08:41:42 2014 From: eniotna.t at gmail.com (ardumont) Date: Sat, 30 Aug 2014 10:41:42 +0200 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <874mwvm2ma.fsf@schoepe.localhost> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> <874mwvm2ma.fsf@schoepe.localhost> Message-ID: <87tx4u9xo9.fsf@gmail.com> Daniel Schoepe writes: > Hi, > > On Fri, 29 Aug 2014 17:55 +0200, Zev Weiss wrote: >> The biggest (or at least most immediately obvious) problem is that >> keeping separate files/directories for each password (which I guess it >> doesn't strictly require, but is clearly geared toward) is a *massive* >> and completely unnecessary information leak. > > I agree, this does leak information, namely the names given to the > passwords, as well as their length, if the files contain just the > passwords and nothing else. I raised the point about the length on the > pass mailing list, but I didn't propose a patch either > (http://article.gmane.org/gmane.comp.encryption.pass/766). > > However, I think that people who use pass are aware of these limitations > and based on their assumptions and usage of the tool, they might be okay > with them (this includes me). > I am. > In favour of pass I have to say that I find reusing a well-audited tool like > gpg to handle the encryption a lot nicer than rolling your own file > format, thereby risking to use encryption primitives incorrectly, > etc.. Moreover, the issues in pass can be fixed without changing it's > interface, which I prefer to GUI-based password managers. > +1 > More importantly however, I don't think that it's the job of the window > manager libraries to tell the user what applications they should or > shouldn't use. Thank you. I believe so too. > I think that there are more people besides me and > ardumont who use pass, so I believe that this module is useful to people > (I use something very similar to ardumont's Prompt module, based on > dmenu). That is reason enough for me to argue for its inclusion. > +1 >> If an alternate backend that didn't have these problems could be used >> to provide this xmonad interface instead I'd be all for it -- but as >> is I'm opposed to it if only on the grounds of it serving to encourage >> further adoption of 'pass', which I simply think is a bad idea. > > I think one big part of the "idea" behind pass is that it's a > command-line password manager as opposed to a GUI application. +1 > Reusing > existing tools like gpg to handle encryption is also a good > idea. Basically all the issues that I can see that make its current > implementation problematic could be solved by encrypting a tar file with > the password files instead of the password files themselves. > > However, given that there is some controversy about this now, I would be > happy about other people's opinions on whether or not this should be > included. > This seems reasonable. > Cheers, > Daniel Thanks Daniel for such clear, complete, concise answers. I am completely aligned with your points. -- @ardumont From eniotna.t at gmail.com Sat Aug 30 08:44:14 2014 From: eniotna.t at gmail.com (ardumont) Date: Sat, 30 Aug 2014 10:44:14 +0200 Subject: [xmonad] XMonad.Prompt.Pass patch In-Reply-To: <877g1rm3cy.fsf@schoepe.localhost> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> <87ha0vdvt1.fsf@gmail.com> <87ha0v88xr.fsf@pmade.com> <87vbpb9jom.fsf@gmail.com> <877g1rm3cy.fsf@schoepe.localhost> Message-ID: <87sike9xk1.fsf@gmail.com> Daniel Schoepe writes: > Hi, > > the intention for xmonad-extras was to house modules requiring > additional Haskell libraries as dependencies to prevent pulling in a lot > of other stuff just for compiling xmonad and xmonad-contrib. This is not > a problem here, the module just won't do anything. > Exactly. > The same point can be made about all the modules to support dzen-based > status bars, (like Util.Dzen), for which dzen is needed for the modules > to be useful. In my view, it's up to the user to ensure these binaries > are present when they want to use what is clearly a module that's > supposed to integrate pass/dzen/whatever with xmonad. > > Therefore I think that this module can go into contrib. Ok, good. Daniel, I did not see anything about xmonad-extras in the xmonad site, it would be good to add a small page about it, don't you think? In any case, thanks for the information sharing. > Cheers, > Daniel > > On Fri, 29 Aug 2014 21:31 +0200, ardumont wrote: >> Peter Jones writes: >> >>> ardumont writes: >>>> In any case, how is it apparent for you that this is not standard? >>> >>> It's not a default package on any distro that I'm aware of. >> >> ? >> >> Like I said, from pass's documentation (I just added the links): >> - Ubuntu - https://launchpad.net/ubuntu/+source/password-store >> - Debian - https://packages.debian.org/source/sid/password-store >> - Gentoo - http://packages.gentoo.org/?search=pass&bgresponse= >> - Arch - https://www.archlinux.org/packages/community/any/pass/ >> - NixOS - https://github.com/NixOS/nixpkgs/blob/master/pkgs/tools/security/pass/default.nix#L17 >> - FreeBSD - http://svnweb.freebsd.org/ports/head/sysutils/password-store/ >> - ... >> >> This is all `default` (it's in the main repository distribution) so I do not understand. >> Also, I believe those distributions are the main linux families (every >> other in a way or another deriving from one of those). >> >> So I must misunderstand the term `default` package, can you explicit it >> for me? >> >>> Since your contribution depends on a non-standard package >> >> Can you please, clarify the term non-standard package? >> >>> I think it would fit in better with xmonad-extras: >>> >>> https://hackage.haskell.org/package/xmonad-extra >> >> I was not aware of this (I must have missed it on the main site). >> >> From the definition `Various modules for xmonad that cannot be added to >> xmonad-contrib because of additional dependencies.` >> pass is indeed an additional dependencies so it seems completely reasonable. >> >> Thanks. >> >> Cheers, >> -- >> @ardumont >> _______________________________________________ >> xmonad mailing list >> xmonad at haskell.org >> http://www.haskell.org/mailman/listinfo/xmonad -- @ardumont From eniotna.t at gmail.com Sat Aug 30 08:51:14 2014 From: eniotna.t at gmail.com (ardumont) Date: Sat, 30 Aug 2014 10:51:14 +0200 Subject: [xmonad] XMonad.Prompt.Pass patch References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> <87ha0vdvt1.fsf@gmail.com> <87ha0v88xr.fsf@pmade.com> <87vbpb9jom.fsf@gmail.com> <87a96n81zn.fsf@pmade.com> Message-ID: <87r3zy9x8d.fsf@gmail.com> User-agent: mu4e 0.9.9.5; emacs 24.3.1 In-reply-to: <87a96n81zn.fsf at pmade.com> Peter Jones writes: > ardumont writes: >> Like I said, from pass's documentation (I just added the links): - >> >> [...snip...] >> >> This is all `default` (it's in the main repository distribution) so I >> do not understand. Also, I believe those distributions are the main >> linux families (every other in a way or another deriving from one of >> those). >> >> So I must misunderstand the term `default` package, can you explicit it >> for me? > > Maybe I'm splitting hairs but when I think of a "standard" or "default" > package I think of things like coreutils that are installed > automatically when I installed my operating system. --text follows this line-- Ok. I understand what you mean now. >From this definition, neither is xmonad then. > > Think about it this way: since xmonad is in the "main repository > distribution" for many operating systems, would you call it a "standard" > package? > With my definition (something like `available for install in standard distribution's packages repository`), I give earlier, yes. With your definition (which clarifies thing), no. (By the way, a subject for another time, it would be good to have a distribution which proposed xmonad as default.) > Just because I can install a package doesn't mean it's a "standard" > package. I'm sure my operating system has dozens of password managers > to choose from, just like it has dozens of windows managers. I would > only call one of them the "standard" package if it was automatically > installed by the base system. Ok. Let me put it this way, using your definition: - XMonad/XMonad-contrib are not standard packages - pass is not standard package - XMonad.Prompt.Pass uses pass (as implementation) Conclusion: We are not standard, we do not integrate this contribution because you are not standard. Do you think it's reasonable? I do not. We have an expression in France for that: `l'hopital qui se moque de la charite` :D The translation is: `it's the pot calling the kettle blackSee`. (I learned a new expression) -- Also, to clarify, the name `XMonad.Prompt.Pass` is named like `pass` but is not named after `pass`. It's just I prefer conciseness where I can and `password` was too long. Also, the names in XMonad seems pretty concise too. Cheers, -- @ardumont From eniotna.t at gmail.com Sat Aug 30 09:19:04 2014 From: eniotna.t at gmail.com (ardumont) Date: Sat, 30 Aug 2014 11:19:04 +0200 Subject: [xmonad] [xmonad-contrib] XMonad.Prompt.Pass patch In-Reply-To: <9A81EF32-CA2F-464F-AF1E-1CD5C7C39DD4@bewilderbeest.net> References: <87mwdf8r4j.fsf@gmail.com> <87wqcia2q5.fsf@gmail.com> <877g4cbrkp.fsf@gmail.com> <874myci1sy.fsf@schoepe.localhost> <8738dtflrf.fsf@gmail.com> <87r41dghes.fsf@schoepe.localhost> <871ttcflbd.fsf@gmail.com> <87d2bkjo7t.fsf@schoepe.localhost> <87lhq7ecg3.fsf@gmail.com> <87iolbe5is.fsf@gmail.com> <0A8A27D2-AFDD-4A4E-B309-05260F87C6AF@bewilderbeest.net> <87ha0vdvt1.fsf@gmail.com> <9A81EF32-CA2F-464F-AF1E-1CD5C7C39DD4@bewilderbeest.net> Message-ID: <87ppfi9vxz.fsf@gmail.com> Hello, > On Aug 29, 2014, at 12:56 PM, ardumont wrote: > >> >> Hello Zev, >> >> Zev Weiss writes: >> >>> On Aug 29, 2014, at 9:26 AM, ardumont wrote: >>> >>>> Hello, >>>> >>>> Here is the latest patch according to remarks. >>>> >>>> >>>> Below I detail some steps I took. >>>> >>>> Hope everything is alright. >>>> >>>> Thanks for your time. >>>> >>> >>> Hi, >>> >>> Much as I hate to be a wet blanket here >> >> I learned a new expression, thanks. >> >>> (and obviously don't speak from a position of any authority or >>> influence on xmonad), I'd just like to voice my from-the-sidelines >>> preference that this patch *not* be applied. >> >> It would have been good to hear this before I patched it thrice. >> :D >> > > Sorry about that; for a while it was looking like it was just going to > fall through the cracks, so I thought maybe it would be easiest for > everyone to just let that happen rather than potentially inciting a > flamewar over it (which I'm trying to avoid here...). Let me get this straight, I am not into flamewar either. Next time you see a dude(ss) working on something you think problematic, please, do tell him. If she/he is working on it, she might be unaware of your insight. > >>> but rather to the 'pass' tool itself. From the description on its web >>> site (http://www.passwordstore.org/), it seems in my opinion rather >>> poorly designed. The biggest (or at least most immediately obvious) >>> problem is that keeping separate files/directories for each password >>> (which I guess it doesn't strictly require, but is clearly geared >>> toward) is a *massive* and completely unnecessary information leak. >> >> Do not use it online then. >> > > Huh? If the threat model is that the attacker doesn't have access to > the local filesystem, why bother with encryption at all? > Point taken. Like Daniel pointed to, there are means for users to improve security over this. > >>> Further, its dependencies >>> (http://git.zx2c4.com/password-store/tree/README#n15) seem to me >>> rather bulky for something that should/could be a very simple, >>> lightweight thing. >> >> I think it simply aligns with the the Unix' sphilosophy to reuse what's already >> there. Using brick composition to provide higher functionalities. >> >> In that way of seeing thing, this sounds standard to me. >> >>> (Also, the hubris >> >> Yet another new expression, thanks. >> >>> of its author immediately declaring it "standard" is >>> rather off-putting, and actually kind of laughable given how >>> obviously-not-a-standard it is -- >> >> It's all perception. >> For example, I for one, dislike the term `obvious` (even more in my >> native language which sounds pretentious). >> So I become suspicious when people uses it (and you used it twice >> already). >> >> I am sorry but nothing for me is that `apparent` except that you sound pretty much like >> what you described. >> Like I said perception. >> >> In any case, how is it apparent for you that this is not standard? >> >> It's free software, and it's available for multiple GNU/Linux distributions (even some are not >> referenced, NixOS for one), Mac OS X and FreeBSD. >> (from its dependencies, it seems there may be even ways to make it work >> on windows platform, though it's not referenced.) >> >> Yet other qualities that sounds standard to me. >> > > When people say things like "ed is the standard text editor", they're typically (hopefully, if they're using the term correctly) referring to actual, real standards, like SUS. For example, here's the SUS entry for ed: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/ed.html > ok, real standards, POSIX and all. Definitions aligned now. (See, it was apparent but not obvious at all to me ;) > If you (or anyone else) can point to a real standard that specifies > the inclusion and behavior of 'pass', I'll retract my statement -- > though I sincerely doubt such a standard exists. Standard begins somewhere. Sometimes, standard emerges with use. > If you want to try get 'pass' into SUS, you can file a bug at http://www.austingroupbugs.net (I won't be holding my breath). > I am not the one requiring this. Furthermore, I checked requirements to contribute and I do not recall seeing one about this. So, if it's the main issue at hand, please, can someone update the requirements in the xmonad site? > There are also so-called "de facto" standards, which are not > technically, officially standardized, but whose use is sufficiently > widespread that their presence/behavior can to some extent be assumed > -- for example in the Haskell world, I think it'd be fair to say that > GHC is the de facto standard implementation of the language. Perhaps > an even better example would be GCC as the de facto standard in the > world of *nix C compilers -- it's not really officially standardized, > but is so well-established that other C compilers (Clang, and icc as > well I think) are essentially forced to mimic its command-line flags > and language extensions if they want to have a chance of seeing any > significant real-world use. Exactly. `Sometimes, standard emerges with use.` > > Here again I don't think 'pass' has anywhere *near* the adoption or > general familiarity to have any reasonable ground to stand on in > claiming to be even a de facto standard. I for one don't recall > having ever once encountered it "in the wild" on any system I've ever > logged in to. First, I can also make the contrary claim based also on my experience (without sources I mean). Second, (again) where is it written, in the xmonad contribution page, that the xmonad-contrib extension needed to be build upon `standard` software? Granted, it's better but it's not required. Maybe the xmonad team could update the documentation for latter contributions. (This will surely loosen the difficulties to contribute...) When I took upon myself to make this, I read multiple times the XMonad documentation (great by the way) and saw nothing of the sort. I believe I did respected everything asked for. > Availability != adoption, and I'd say widespread > adoption is kind of a prerequisite for de facto standardization. And last, what about xmonad itself? Don't you think the same could be said of xmonad? And still we are using it. Because, whatever other people say about their computer use, we think we know better (from first class use). And the hell with standard/adoption and whatnot! XMonad rocks! Also, I never used dmenu and all those excellent tiny helpers to ease xmonad learning etc... before using XMonad (on StumpWM, from where I came from, there is a basic native shell launcher and I was quite happy with it). At the time, I never asked myself, is this standard? I was more, "if I install this and use it, will I be able to reproduce my machine if it ever dropped dead"? And since the answer is yes, I gave it a shot. > And on the issue of dependencies -- I probably should have been a bit clearer there. GPG seems entirely fine here (certainly preferable to hand-rolled-and-probably-buggy crypto, as pointed out by Daniel elsewhere in the thread); I have no objection to that. Implementation as a shell script also doesn't strike me as inherently unreasonable, though if the author's intent is really to create something "standard", I'd think a standard shell (Bourne) would be a much more sensible choice than bash. The rest, however, seem to me to be an assortment of frivolous, unnecessary, and/or absurd stuff. > > > All that said, it of course does not actively *harm* XMonad to have > this support, so if the maintainers feel it's a good fit, go right > ahead. Cool. > But from my perspective, all the existing instances I can see of > support for external software packages in xmonad{,-contrib} are for > substantially better-designed programs. Do not forget, pass is an implementation detail that can be abstracted away when people feel the need for it. Still, you have good points. Maybe, you can contribute in some ways, to: - pass to remove what's `frivolous, unnecessary, and/or absurd stuff` - propose to SUS to integrate pass as standard when you will feel it is ready - improve this code (or create a new one) to propose an alternate password manager - improve this code to abstract away the password manager and provide both a `standard` password manager and pass as possible implementations You could also, if you are not happy with pass, do not use this. Like Daniel said, even if it's installed the module will do nothing if the user does not install the needed software. > Might pass's contrib/ directory be another (better, in my opinion) > place to consider putting this code? I am sorry I did not understand this sentence. What's pass's contrib/ directory? > > > Zev Cheers, -- @ardumont From fercerpav at gmail.com Sat Aug 30 15:22:33 2014 From: fercerpav at gmail.com (Paul Fertser) Date: Sat, 30 Aug 2014 19:22:33 +0400 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving In-Reply-To: <54012bba.498e420a.0aaf.0312SMTPIN_ADDED_MISSING@mx.google.com> References: <54012bba.498e420a.0aaf.0312SMTPIN_ADDED_MISSING@mx.google.com> Message-ID: <20140830152233.GJ6339@home.lan> 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 at gmail.com From allbery.b at gmail.com Sat Aug 30 16:05:06 2014 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 30 Aug 2014 12:05:06 -0400 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving In-Reply-To: <20140830152233.GJ6339@home.lan> References: <54012bba.498e420a.0aaf.0312SMTPIN_ADDED_MISSING@mx.google.com> <20140830152233.GJ6339@home.lan> Message-ID: 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 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: From anton at enomsg.org Sat Aug 30 23:50:03 2014 From: anton at enomsg.org (Anton Vorontsov) Date: Sat, 30 Aug 2014 16:50:03 -0700 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving In-Reply-To: <20140830152233.GJ6339@home.lan> References: <54012bba.498e420a.0aaf.0312SMTPIN_ADDED_MISSING@mx.google.com> <20140830152233.GJ6339@home.lan> Message-ID: <20140830235003.GA24438@d1stkfactory> On Sat, Aug 30, 2014 at 07:22:33PM +0400, Paul Fertser 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): > > Prelude System.Posix.Env> getEnv "HOSTNAME" > Nothing Ugh. As Brandon Allbery rightfully pointed out, the whole hostname issue is a mess. I also found this post about XAUTHLOCALHOSTNAME: http://lists.x.org/archives/xorg-arch/2005-August/000200.html Personally, in my setup I have all three env variable set: HOST{,NAME} and XAUTHLOCALHOSTNAME. Please see if the patch below helps. It should account for different setups. ... > 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? Yea, maybe as a hook. > On an unrelated note, where do you get opportunities to apply your > Haskell skills? I do some AI/BCI research using Haskell, but it's for my own fun. Commercially I don't apply it anywhere. :) --- diff -rN -u old-XMonadContrib/XMonad/Layout/Stoppable.hs new-XMonadContrib/XMonad/Layout/Stoppable.hs --- old-XMonadContrib/XMonad/Layout/Stoppable.hs 2014-08-30 16:11:44.835184230 -0700 +++ new-XMonadContrib/XMonad/Layout/Stoppable.hs 2014-08-30 16:11:44.838184259 -0700 @@ -74,8 +74,11 @@ signalLocalWindow :: Signal -> Window -> X () signalLocalWindow s w = do - host <- io $ getEnvDefault "HOSTNAME" "" + host <- io $ takeOneMaybe `liftM` (getEnv `mapM` vars) hasProperty (Machine host) w >>= flip when (signalWindow s w) + where + takeOneMaybe = last . (mzero:) . take 1 . catMaybes + vars = ["XAUTHLOCALHOSTNAME","HOST","HOSTNAME"] withAllOn :: (a -> X ()) -> Workspace i l a -> X () withAllOn f wspc = f `mapM_` integrate' (stack wspc) From fercerpav at gmail.com Sun Aug 31 05:35:41 2014 From: fercerpav at gmail.com (Paul Fertser) Date: Sun, 31 Aug 2014 09:35:41 +0400 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving In-Reply-To: <20140830235003.GA24438@d1stkfactory> References: <54012bba.498e420a.0aaf.0312SMTPIN_ADDED_MISSING@mx.google.com> <20140830152233.GJ6339@home.lan> <20140830235003.GA24438@d1stkfactory> Message-ID: <20140831053541.GK6339@home.lan> On Sat, Aug 30, 2014 at 04:50:03PM -0700, Anton Vorontsov wrote: > > On an unrelated note, where do you get opportunities to apply your > > Haskell skills? > > I do some AI/BCI research using Haskell, but it's for my own fun. > Commercially I don't apply it anywhere. :) I thought you were a Moscow embedded developer hacking on old iPAQs and now you appear to be writing perfect English and sophisticated Haskell from a PDT location, what a surprise! I'm glad to hear you're having fun :) > + vars = ["XAUTHLOCALHOSTNAME","HOST","HOSTNAME"] This is from my pretty standard Gentoo install, and the same result on another Debian machine too: Prelude System.Posix.Env> getEnv `mapM` ["XAUTHLOCALHOSTNAME","HOST","HOSTNAME"] [Nothing,Nothing,Nothing] paul at laptop ~ $ env | egrep '(XAUTHLOCALHOSTNAME|HOST|HOSTNAME)' paul at laptop ~ $ -- Be free, use free (http://www.gnu.org/philosophy/free-sw.html) software! mailto:fercerpav at gmail.com From anton at enomsg.org Sun Aug 31 07:46:50 2014 From: anton at enomsg.org (Anton Vorontsov) Date: Sun, 31 Aug 2014 00:46:50 -0700 Subject: [xmonad] darcs patch: Add Stoppable layout for power saving In-Reply-To: <20140831053541.GK6339@home.lan> References: <54012bba.498e420a.0aaf.0312SMTPIN_ADDED_MISSING@mx.google.com> <20140830152233.GJ6339@home.lan> <20140830235003.GA24438@d1stkfactory> <20140831053541.GK6339@home.lan> Message-ID: <20140831074650.GA9236@d1stkfactory> On Sun, Aug 31, 2014 at 09:35:41AM +0400, Paul Fertser wrote: > On Sat, Aug 30, 2014 at 04:50:03PM -0700, Anton Vorontsov wrote: > > > On an unrelated note, where do you get opportunities to apply your > > > Haskell skills? > > > > I do some AI/BCI research using Haskell, but it's for my own fun. > > Commercially I don't apply it anywhere. :) > > I thought you were a Moscow embedded developer hacking on old iPAQs > and now you appear to be writing perfect English and sophisticated > Haskell from a PDT location, what a surprise! I'm glad to hear you're > having fun :) ;-) > > + vars = ["XAUTHLOCALHOSTNAME","HOST","HOSTNAME"] > > This is from my pretty standard Gentoo install, and the same result on > another Debian machine too: > > Prelude System.Posix.Env> getEnv `mapM` ["XAUTHLOCALHOSTNAME","HOST","HOSTNAME"] > [Nothing,Nothing,Nothing] > > paul at laptop ~ $ env | egrep '(XAUTHLOCALHOSTNAME|HOST|HOSTNAME)' > paul at laptop ~ $ Wow. Well, it just means that you have to create one. After poking around, I now see that XMonad/Layout/OnHost.hs talks about the same thing... It also contains a good idea: we can just set it in the config file itself. No doubt that I should document it, though. Similar to XMonad/Layout/OnHost.hs. Thanks! Anton p.s. The proper way to handle remote clients is a little bit more trickier, especially considering that the hostname might be changing. For this, we have to check current hostname and WM_CLIENT_MACHINE at the window creation time. If they are equal, then it is the local window and we have to store some flag for future use (since WM_CLIENT_MACHINE and hostname can diverge later on). But that would require a new dependency either in xmonad, or in a config file (better)...