- xmonad - Haskell.org

One status bar process, visible on N screens
by Jacek Generowicz 17 Jan '12

17 Jan '12

Hello, When running unity-2d-panel, the panel appears once on each screen, even though a single process is running. (There is a glitch where the width of the narrower screen determines the width of the panel, so it doesn't span the whole screen width on the wider screen.) At the moment I am spawning two xmobar or dzen2 processes, one for each screen. This isn't really satisfactory: Requiring multiple processes merely to display exactly the same information, and hard-wiring 2 bars, is rather grating. Have you any suggestions on how to configure XMonad so that a single status bar is visible on every visible screen that happens to be connected at any time? Thank you.

3 6

Issue 491 in xmonad: Incorrect documentation in XMonad.Actions.WindowGo
by codesite-noreply＠google.com 16 Jan '12

16 Jan '12

Status: New Owner: ---- New issue 491 by cub.ua...(a)gmail.com: Incorrect documentation in XMonad.Actions.WindowGo http://code.google.com/p/xmonad/issues/detail?id=491 Documentation for XMonad.Actions.WindowGo (http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-WindowGo.html) have incorrect link. At the end of raiseMaybe description, instead of : ... to run Mutt! Here's an example (borrowing runInTerm from XMonad.Utils.Run): should be: ... to run Mutt! Here's an example (borrowing runInTerm from XMonad.Util.Run): (both visible text and link to XMonad.Util.Run are affected)

1 1

Avoiding multiple status bar processes after XMonad restart
by Jacek Generowicz 16 Jan '12

16 Jan '12

Hello, Would you have any advice on avoiding multiple xmobar or dzen processes running as a consequence of XMonad restarts? Is there really nothing built in to XMonad that deals with this, or have I simply failed to find it? Thanks.

4 13

(no subject)
by Chris Pick 15 Jan '12

15 Jan '12

I've been playing around with XMonad and came across the helpful PhysicalScreens extension. The extension works well, but I had a small hiccup getting started. As a Haskell and XMonad novice, I was pretty much copying/pasting from the example at http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Actions-PhysicalScreens… that's pulled from the source. The import line contains a typo, it says "PhysicalSCreens" instead of "PhysicalScreens". I grabbed what I believe is the latest source with `darcs get http://code.haskell.org/XMonadContrib` and the typo is still there. I mailed Nelson Elhage, who let me know that this list would be the best place to submit a patch. Gratuitously simple patch attached.

2 1

dmenu on currently focused monitor
by Jacek Generowicz 13 Jan '12

13 Jan '12

Hi, At the moment I'm invoking dmenu with spawn "exe=`dmenu_path | dmenu` && eval \"exec $exe\"" Which results in dmenu always appearing on my primary monitor. What should be done in order to make dmenu appear on the focused monitor? I'm guessing that it might require the use of dmenu's -m option, but it's not clear to me how to get XMonad to report the currently focused monitor, or how to (cleanly) incorporate this information into the spawn command. As a secondary issue, when monitor 1 is focused and I launch something with dmenu, dmenu appears on monitor 0; the launched application sometimes appears on monitor 0, sometimes on monitor 1. I haven't managed to spot a pattern in this behaviour yet. Any hints on how to make this behaviour more stable and more sensible? Thanks.

2 2

Re: [xmonad] [process] Fixed asynchronous exception bugs in readProcess and readProcessWithExitCode
by Brandon Allbery 13 Jan '12

13 Jan '12

On Thu, Jan 12, 2012 at 14:35, Bas van Dijk <v.dijk.bas(a)gmail.com> wrote: > 2) If an asynchronous exception was thrown to the > stdout/stderr-read-thread it did not execute the putMVar anymore > resulting in a dead-lock when takeMVar was executed. > Hah. I knew something like this was in there; xmonad is hanging instead of catching an exception or signal when the far end of a pipe (usually xmobar) goes away. -- brandon s allbery allbery.b(a)gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms

2 1

xmonad in Coq
by Wouter Swierstra 13 Jan '12

13 Jan '12

Hi guys, For a while I've been looking into formalizing parts of xmonad in the Coq proof assistant. After a bit of work, I've written a Coq module that, when you extract Haskell code from it, produces a drop-in replacement for xmonad's StackSet module. The generated Haskell code is clearly not hand-written and triggers plenty of ghc warnings, but passes the QuickCheck testsuite. I've put everything online here: https://bitbucket.org/wouterswierstra/xmonad It require one or two very modest patches to xmonad to build, but nothing controversial. See the readme for more technical details. I've managed to prove a handful of QuickCheck properties in Coq, but I just don't have the time to see this project through. If anyone is interested in contributing, I'd be very happy to advise them on how to proceed. I think it would make quite a nice exercise for anyone interested in learning more about formal verification using Coq -- but it's certainly not for the faint hearted! All the best, Wouter

1 0

Issue 490 in xmonad: Documentation bug in XMonad.Doc.Extending about XMonad.Actions.FloatSnap
by codesite-noreply＠google.com 11 Jan '12

11 Jan '12

Status: New Owner: ---- New issue 490 by cub.ua...(a)gmail.com: Documentation bug in XMonad.Doc.Extending about XMonad.Actions.FloatSnap http://code.google.com/p/xmonad/issues/detail?id=490 Page http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Doc-Extending.html have broken link to XMonad.Layout.FloatSnap - it should be link to XMonad.Actions.FloatSnap instead

1 3

Manage hooks
by Norbert Zeh 09 Jan '12

09 Jan '12

Hi folks, before I go and code this up myself, let me make sure it doesn't exist yet. I want two features of managehooks: - Display a certain type of window (say emacs) on a certain screen (screen, not workspace) - Toggle manage hooks (e.g., using a key binding). As an example, I normally want no special handling of emacs windows, but for certain tasks I want every emacs window to pop up on my left screen. Since I do not want to reconfigure and restart xmonad every time the context changes, I need to be able to activate/deactivate certain manage hooks. Ah, I actually just found X.H.DynamicHooks, which seems to go at least part of the way for the second bullet above. The first question remains. If the above functionality does not exist yet, I'd provide the first as a patch for X.H.ManageHelpers and the second either as a patch for X.H.DynamicHooks or as a separate module, depending on how incremental the change turns out to be. Does this sound reasonable? Cheers, Norbert -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

4 4

Re: [xmonad] XMonad.Actions.CycleRecentWS rewrite (new modules inside)
by Jochen Keil 09 Jan '12

09 Jan '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello Nathaniel, On 09.01.2012 02:15, Nathaniel Filardo wrote: > Would it be possible to rework this to avoid looping around the X > event stream? Not with this form of generalization. > IMHO it would be nicer if it updated its internal state and then > let the main event loop dispatch events its way. If you do it that way, you cannot cycle over your workspaces. It would be effectively a key for toggling your last viewed workspace, due to the way XMonad updates its internal Workspace list. E.g. workspaces: current: 0, others: [1,2,3,4] view $ head others: current 1, others: [0,2,3,4] view $ head others: current 0, others: [1,2,3,4], etc. If you want to cycle you have to preserve the state of the initial list. > Modules creating their own event loops just doesn't seem right (and > in the case of XMonad.Prompt causes usability problems for me > where I will start filling out a prompt and then want to change > focus before finishing). First of, XMonad takes Events from the X event queue in a single threaded event based loop. Reading from the event queue and processing the events our specific function is interested in should normally cause no harm since we are still within the X state monad without concurrency. Furthermore, events we are not interested in lead to an immediate break of the function and are put back into the event queue (putBackEvent) so nothing is lost. In general, there are currently two ways I see how to accomplish this recent workspace cycling problem. I've tried them both and opted for this method, I'll give you the reasons later. The first method would be to use Extensible State. This allows to store a Show- and Tybeable -able Type in the X Monad, which means that anything that contains layouts (LayoutClass), like Screens, Workspaces or WindowSets is out. You can do this by saving a list of tags (Strings) and use this list for cycling. Pros: * no need to read events from x event queue Cons: * limited to types which are (at least) Show and Typeable, Read would be preferrable * without Read there is no PersistentState, so your Workspace cycling order is lost on restarts * not a general solution, rather a very specific one The other solution is what I did. Keeping a state myself in the function loop, thus unlimited on the type. The state is retrieved from the X state monad *once* and then passed through. So every time we apply a function for altering the state it is done with the initial state. Since this is a functional programming language there is no such thing as a global state, only what you pass either from one function to the other or in the case of XMonad in the outer event loop (which is just function itself. But you cannot declare your own state in a module and have it globally available. Pros: * general solution, unlimited on types, does no harm to the x event loop (afais) cons: own event processing Now this is a rather long read and I apologize for that. However, I hope that I clearly pointed out, that there are only two possibilities to implement this and why I've chosen the current implementation. Best Wishes, Jochen > Thanks. --nwf; > > On Sun, Jan 8, 2012 at 6:07 AM, Jochen Keil <jochen.keil(a)gmail.com> > wrote: Hi, > > my last version of CycleRecentWS.hs had a small logical bug. I > added the current ws to the end of the list but it should go to the > head. This makes also the somewhat strange +/-2 on secondary > modifier keypress superfluous. I also thought about getting rid of > passive grab but the problem is that we stay in the recursive loop > if we don't exit on the keyrelease event by the grabbed modifier. > This shouldn't be a problem normally, because when you press > another modifier + key combination we'll terminate the loop. It can > however lead to unexpected behavior when releasing the modifier and > then pressing it again so that the loop stays active thus cycling > over the (old and possibly not desired) state again. > > Best Regards, > > Jochen > > > On 07.01.2012 23:32, Jochen Keil wrote: >>>> Dear list, >>>> >>>> after struggling for a while the XMonad.Actions.CycleRecentWS >>>> contrib module, mainly because it actively grabs the whole >>>> keyboard (and thus breaks various functionality, e.g. >>>> switching the layout on the fly), I took the time to rewrite >>>> this module. It now does not actively grab the whole >>>> keyboard anymore but relies only on one passive grab. I >>>> imagine this could be done even more generally, but I am >>>> pretty satisfied with how it works now. However, since theres >>>> always room for improvement new ideas are always welcome. :) >>>> >>>> I've included another module which helps to setup up a >>>> passive grab on a certain key. Configuration is a bit >>>> (tr)icky, but I hope not too troublesome. >>>> >>>> Best regards, >>>> >>>> Jochen >>>> >>>> >>>> >>>> _______________________________________________ xmonad >>>> mailing list xmonad(a)haskell.org >>>> http://www.haskell.org/mailman/listinfo/xmonad >> >> _______________________________________________ xmonad mailing >> list xmonad(a)haskell.org >> http://www.haskell.org/mailman/listinfo/xmonad >> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8KxMcACgkQtVwvsA+W4CB1MACeNA0iLHCxdoDoIBxpwez0JyXr ZgsAoJ002iSKjJRsJ1vVMexrVqbxYned =BBmJ -----END PGP SIGNATURE-----

1 0