January 2012 - xmonad

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 12 Jan '12

12 Jan '12

Status: New Owner: ---- New issue 490 by cub.ua...@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 10 Jan '12

10 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

XMonad.Actions.CycleRecentWS rewrite (new modules inside)
by Jochen Keil 08 Jan '12

08 Jan '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk8IyA0ACgkQtVwvsA+W4CD/oQCfQQgOCq2F1jIemAgfYP14s+as mTQAn3710teJZPyRTei0kmv5sTquxpPO =XT02 -----END PGP SIGNATURE-----

1 1

How to manage three monitors on two graphics cards?
by Wolfram Kahl 08 Jan '12

08 Jan '12

I have a machine with two graphics cards, and three differently-sized monitors (at different orientations) driven by the two cards. As far as I could easily find, my main options appear to be: (1) In xorg.conf ServerFlags: Option "Xinerama" "false" Then I have two screens, :0.0 and :0.1; I follow the gentoo Multihead instructions at http://en.gentoo-wiki.com/wiki/X.Org/Dual_Monitors and start X without session manager, just with startx, and have xmonad on the last line of .xinitrc. (This is xmonad-0.10.) That xmonad then appears to manage only the first screen, :0.0, which happens to have two outputs associated with it. (While I had the second card deactivated, xmonad managed these two outputs separately as it should.) However now, even though xrandr still sees these two outputs associated with the current screen, xmonad manages them as a single unit --- does that qualify as a bug? I can start another xmonad DISPLAY=:0.1 xmonad & taking over the other screen, but that is not sufficient to actually use it; I found no combination of mouse clicking and keyboard action that would get focus into that empty screen and start a terminal. I therefore have to DISPLAY=:0.1 terminal & whenever I end up in an empty workspace on the second screen, otherwise I can do nothing there. Even if both screens are populated, switching focus between them seems to require mouse movement, and still seems to be a brittle affair; most of the time I have to mod4-<left> click (myModMask = mod4Mask) (followed my mod4-t to move the activated window back into tabbing). I can work with this, but it is far from the degree of enjoyment that xmonad gave me with two monitors... (2) In xorg.conf ServerFlags: Option "Xinerama" "true" Now xrandr does not work anymore, and xmonad sees one big area. I can specify the X locations of the three outputs to import XMonad.Layout.LayoutScreens but I have the impression that this works on the wrong level, and did not see how that would allow me to switch my normal 9 workspaces across the now three monitors in the same way as I previously did with two monitors. (I have been a pure xmonad user so far (a very happy one!) and not delved into its API yet.) What is the best way to make xmonad ``just work'' with multiple screens split across multiple graphics cards? Just fixing my main problem with (1), namely getting the first xmonad to handle the two outputs separately again, would be a big improvement... Wolfram

5 9

Re: [xmonad] help
by Jorge Perez 08 Jan '12

08 Jan '12

here is the accompanying config file ... please help if being trying to get this to work for days, and i have gotten to the point where i don't see anything wrong with my config file the line of interest is 87 ________________________________ From: Jorge Perez <japrogramer(a)yahoo.com> To: "xmonad(a)haskell.org" <xmonad(a)haskell.org> Sent: Saturday, January 7, 2012 7:05 PM Subject: help i em having trouble setting up my dzen status bar, it works but once i try to pass it font settings or -fn -bg -fg or -h it crashes the weird thing is i can pass it -p -ta -y -x and it works, also i have a dzenbar being piped conky output and it can take all the arguments without crashing in the command line i get stack smashing detected ***: dzen2 terminated ... <file descriptor: 7>: commitBuffer: resource vanished (Broken pipe) but only the status bar crashes the conky | dzen pipe works fine

1 0

EwmhDesktops vs. ewmhDesktopsEventHook
by Toens Bueker 07 Jan '12

07 Jan '12

Hi *, a new laptop has arrived and I have to migrate my xmonad-config over. I'm basically using the "bla-config" (http://bla.thera.be/article/improving-your-desktop-experience) which makes use of EwmhDesktops. Obviously that is no longer "in scope". As my haskell-skills are near to zero (I'm just using it), I would be very pleased, if somebody could have a look at the config and make use of emwhDesktopsEventHook or ewmh as a hole and make the config usable again. Thx. Kind regards, Töns -- There is no safe distance.

2 5

Ambiguous focus after some commands...
by Allen S. Rout 06 Jan '12

06 Jan '12

I've recently encountered an odd focus behavior, and I'm not certain whether I'm thinking about it incorrectly, or if it's a bug. I do a lot of document editing in Emacs' org-mode. (and I highly recommend it: anyone who groks xmonad will probably find Emacs a pleasant environment). In that universe, you compose in a plain-text format, and then direct an 'export' process. On export, Emacs translates your 'org-mode' document into a LaTeX one, then makes PDF out of it, and optionally displays it. If you're doing this with evince as the display engine, you get the result of the document view updating, but no new window. I frequently have my Evince on a screen adjacent to the Emacs, so each has plenty of space. So: with my focus on the Emacs, I [C-c C-e d] (control-c, control-e, d) and watch the export process go. Evince updates with the view of the new document. ... And my focus is now oddly inconsistent. The Emacs window still has the red border by which xmonad attempts to communicate focus, and if I do things like 'onNextNeighbour W.view' it becomes clear that xmonad thinks my focus is there. But my keystrokes are going to evince. If I had started a new client, which appeared on a currently displayed desktop, I would expect that client to grab focus. But I'm not starting a new client, here; I'm sending a message to an existing one. Or at least I think that's what I'm doing, it's possible I guess that Evince is slaying the old process and starting anew, but I'd then expect it to appear on the same workspace as the Emacs. Does this ring any bells? -Allen S Rout

3 2

Why RationalRects for floating windows?
by Norbert Zeh 06 Jan '12

06 Jan '12

Hi folks, I'm wondering whether anybody can enlighten me why the geometry of a floating window is stored as a RationalRect relative to the screen size. I can see one advantage to this approach: a centered window is centered on every screen. Apart from that, I see only disadvantages to this approach, as it means that windows get resized when workspaces shift between screens of different sizes. If at least the aspect ratios of all screens are the same, this may be acceptable, though not ideal. My newest setup combines two portrait screens (1080x1920) with two landscape screens (1920x1080). A window that has a reasonable geometry on one of the landscape screens now gets long and skinny on the portrait screens. I'd also appreciate any ideas on how to work around this issue, as I think changing the way xmonad stores information about floating windows would just break too many modules and thus isn't an option. Thanks, Norbert -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

3 4