February 2009 - xmonad

Issue 277 in xmonad: Red border on two windows
by codesite-noreply＠google.com 22 Feb '09

22 Feb '09

Comment #2 on issue 277 by wirtwolff: Red border on two windows http://code.google.com/p/xmonad/issues/detail?id=277 Cannot reproduce here either. lykhab, please attach xmonad.hs being used when you are seeing this happen. Or join irc on #xmonad(a)irc.freenode.net and pastebin xmonad.hs http://hpaste.org/fastcgi/hpaste.fcgi/new (Layout.WindowNavigation extension draws extra colored borders, can be disabled with 'configurableNavigation (noNavigateBorders)', or by using Actions.WindowNavigation instead. Could this be the cause?) -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

Issue 277 in xmonad: Red border on two windows
by codesite-noreply＠google.com 22 Feb '09

22 Feb '09

Comment #1 on issue 277 by dons00: Red border on two windows http://code.google.com/p/xmonad/issues/detail?id=277 I can't reproduce this with xmonad 0.8.1. Anyone else? Is it the terminal you're using? -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

darcs patch: Add TabbedModifier layout modifer
by Adam Vogt 22 Feb '09

22 Feb '09

Sun Feb 22 10:19:35 EST 2009 Adam Vogt <vogt.adam(a)gmail.com> * Add TabbedModifier layout modifer Allows arbitrary windows to be combined into tabs groups. The group focus follows the StackSet focus, and groups can be combined with a simple message. Currently the Merge message's parameters can only be provided by a new WindowNavigation message (Apply).

1 1

Issue 277 in xmonad: Red border on two windows
by codesite-noreply＠google.com 22 Feb '09

22 Feb '09

Status: New Owner: ---- New issue 277 by lykahb: Red border on two windows http://code.google.com/p/xmonad/issues/detail?id=277 What steps will reproduce the problem? 1. Open two windows in standard layout 2. Move focus to the second with mod-j 3. Swap it with the first with mod-shift-k What is the expected output? What do you see instead? Both windows have red border, not only the active What version of the product are you using? On what operating system? XMonad 0.8 on Ubuntu 8.10 By the way, please fix typo in guided tour - there is word "maximisd" in layout modes part. -- You received this message because you are listed in the owner or CC fields of this issue, or because you starred this issue. You may adjust your issue notification preferences at: http://code.google.com/hosting/settings

1 0

darcs patch: X.Layout: haddock workaround in documentation for cons...
by Wirt Wolff 22 Feb '09

22 Feb '09

Sun Feb 15 15:10:29 MST 2009 wirtwolff(a)gmail.com * X.Layout: haddock workaround in documentation for constructor comment fail Copied !Constructor -- ^ comments above into example code to workaround haddock no longer parsing these. Allows xmonad darcs to build and test with haddock 2.4.1 at least.

2 1

darcs patch: L.Cross: clarify documentation
by Wirt Wolff 22 Feb '09

22 Feb '09

Sat Feb 21 21:22:20 MST 2009 wirtwolff(a)gmail.com * L.Cross: clarify documentation Amend-record earlier patch to work with byorgey's fix, this one is just the documentation typo fixes and clarifications.

2 1

darcs patch: U.Run: remove waitForProcess to close Issue 268
by Wirt Wolff 21 Feb '09

21 Feb '09

Fri Feb 20 14:41:53 MST 2009 wirtwolff(a)gmail.com * U.Run: remove waitForProcess to close Issue 268 http://code.google.com/p/xmonad/issues/detail?id=268 Submitting with some trepidation, since I've nearly no understanding of process handling. Should be ok, no warnings by sjanssen when asking about it in hpaste or earlier email, and tested locally by spawning excessive numbers of dzens: did not leave zombies or raise exceptions.

2 1

darcs patch: (ugly) Fix X.L.Cross doc
by Ismael Carnales 21 Feb '09

21 Feb '09

Someone had to do it ;), thanks sereven!

2 1

Extensible programs & defaults: the Gosling Emacs experience
by Gwern Branwen 21 Feb '09

21 Feb '09

So, I happened to be reading a PhD thesis on exokernels, when I came across a reference. The context was that an exokernel is a maximally minimalistic operating system kernel; the kernel solely divides up resources among running programs. The programs get all other abstractions and standard OS services by linking in customized libraries, 'libOSes' as the developers put it. The point was that while an exokernel is designed so that any program can customize the operating system as much as possible, the defaults are still profoundly important, and the authors mentioned an Emacs retrospective which covered that. "UNIX Emacs: A Retrospective. Lessons for Flexible System Design" (by Gosling & Borenstein). I managed to get a copy, and I found some of it very instructive reading. Indeed, I find it instructive to look at various xmonad.hses after reading some excerpts: "The one point on which nearly everyone seems to agree is that the best thing about UNIX Emacs is that mlisp exists. No one even suggested that Emacs would be better without the powerful facility for extension and customization, although it is clear that such facilities, if abused, can create an environment that changes so radically from day to day as to be unusable for most people." "The integration of powerful editing facilities with a full-fledged programming language seems unquestionably useful, though it remains a matter of some debate whether this combination is best achieved by an extension language for a text editor or by implementing the text editor as a subroutine library in an existing programming language." "The key principle is that there is *simple syntax for simple operations*. This does not mean that a more complex syntax should not be available for more complex operations, only that the complexity should not be forced on the programmer in a simple context." "It didn't have to be that way. In the development of Emacs, it was far too easy to say that, since the support for the kind of basic interface was entirely customizable, it wasn't important to devote a lot of attention to getting the default interface to be correct. After all, anyone who didn't like the interface could change it. What this attitude ignored, however, was the old rule our mothers used to teach us about the lasting value of first impressions. Many people tried Emacs, couldn't stand the basic interface, and went back to their old standard editors, such as the vi editor on UNIX." "It is worth noting that this happened despite the fact that several people, independently, implemented more or less complete vi emulation packages for Emacs in mlisp. It seems that even if a package existed that was an absolutely perfect simulation of vi, most of the people who prefer vi to Emacs would stick with the clearly less powerful vi. While this is in part due to the smaller size of vi, it is also attributable to the unacceptable difficulty, in the minds of such people, of having to learn how to turn the vi emulation package on in the first place." "The clear lesson to be learned from this is that, while flexibility in such a system is indeed essential, great care must be paid to get the default behaviours to be simple and natural, and to provide very clear and simple ways to use a carefully chosen small set of the most commonly desired customizations. It may be, organizationally, that the people who build the flexible tools are not necessarily the right people to figure out which are the correct defaults and 'standard options'. The process of making such choices probably requires serious observation of users, or even controlled experiments, to compare possible system configurations." ----- I'm not sure how well XMonad works on the above criteria. It seems to me that there are a number of things which could be improved. For example, one of the most common changes is to switch the modifier from Alt to Win, for the simple reason that stealing Alt renders many programs nearly unusable. The arguments I've seen is that we should follow dwm tradition, and that we have no guarantee that Win is mapped to a real key, but is it really impossible for us to, say, autodetect whether Win is usable and only fallback to Alt? Or perhaps on running XMonad the first time with a xmonad.hs, there could be a prompt. Or... there are many ways we could tackle this issue. Another example: some function usages are copied all over the place. How many configurations have a line that looks like: > , keys = \c -> myKeys c `M.union` keys defaultConfig c Yes, it's neat that we can use basic Data.Map functions to union the default and custom keymaps (with the implication we can be flexible and combine them any other way we like), but it strikes me as wrong to have a relatively opaque task repeated time and again. Why don't we have a helper function such that we could write instead: > , keys = overrideDefaultWith myKeys Or if one is setting ManageHooks. Sure, one *could* write > , className =? "Firefox" --> doF (W.shift "web") 2, 3, 4, 6, or however many different entries one has in one's ManageHooks. But wouldn't a helper function be warranted so one could write: > , shiftClassToWS "Firefox" "web" For that matter, am I the only one who wants to be able to unfloat windows in ManageHook? Leaving aside how there is no actual unfloat function, I was eventually able, thanks to #xmonad, to write in my xmonad.hs: > className =? "defcon.bin.x86" --> ask >>= doF . W.sink But heck, do I understand that? Would someone else have any idea what that means? I mean, we're got 4 operators in there, 3 unusual functions (ask isn't even an xmonad function, it's from the State monad. I think. It seems a little much to expect customizers to understand monads, and the State monad, just to do a basic thing like 'unfloat an application when it opens'). ------ In short, perhaps a goal for 0.9 could be to make customizing XMonad easier on the xmonad.hs level. I think a second goal would be to change defaults in the XMonad core, and to perhaps add in some extensions by default - but that's an entirely other discussion. I'm not sure how people would react if I suggested making SmartBorders the default for the fullscreen layout. :) -- gwern Echelon Herald Islamic VHF CTP BATF POCSAG MDA USCG burhop

3 3

[xmonad-contrib] DarcsWatch Unapplied Patch Review
by Wirt Wolff 20 Feb '09

20 Feb '09

Updated version of Gwern's fine review from a while back: Down to 15 unapplied in XMC DarcsWatch, several of which are new, and none obsolete but possibly[1] and [2]. Hurrah! DW is unfortunately missing at least some patches from the mailing list. Some manually attached patches are listed and some are not; some are listed only on the 'DarcsWatch overview > Listing by user' page, and marked as "unmatched", e.g. the *Master patches. Not sure what causes this, but I did have some problems with a darcs get --partial repo while testing patches, so maybe generating patches against different lazy versions may have something to do with it? = Needing comments,lobbying, committer decision = * 20080710220410: XMonad.Actions.DynamicKeys: utilities to update key bindings at runtime by Marco TM-CM-:lio Gontijo e S <marcot(a)riseup.net> wmw: Depends on core change. Own thread. * 20081007080041: UpdatePointer even to empty workspaces by Joachim Breitner <mail(a)joachim-breitner.de>, 20081008154245: pointWithin has moved to the core by Joachim Breitner <mail(a)joachim-breitner.de> gwern: Maintainer plans to comment this weekend. Tested ok here. Own thread. * 20081019140330: FocusNth improvements fixed by Aleksey Artamonov <aleksey.artamonov(a)gmail.com> wmw: Maintainer still no comment. Tested ok here. Own thread. * 20090117164445: Properly encode destop names before sending them to X server in XMonad.Hooks.EwmhDesktops Khudyakov Alexey <alexey.skladnoy(a)gmail.com> gwern: Blocked on our slow-moving UTF discussion. wmw: Makes UTF-8 non-optional dependency but solves high impact problem for those it affects. Own thread. * 20090128013917: new XMonad.Layout.MessageControl module 20090128004726: NoWrap export patch for use with X.L.MessageControl <quentin.moser(a)unifr.ch> wmw: Comments requested from (yet to volunteeer) LayoutCombinators adopter. Own thread. * 20090209192718: add a regular expression matching manageHook by Justin Bogner <mail(a)justinbogner.com> wmw: Looks good to me; several user requests and many use cases. * 20090213155441: H.DynamicLog Add format strippers for xmobar and dzen <wirtwolff(a)gmail.com> wmw: No comments yet. Own thread. * 20090215212346: L.Cross: clarify documentation and fix for haddock <wirtwolff(a)gmail.com> wmw: (!) Some fix for Cross should be applied; it blocks -ftesting for anyone with Cross in their repo. * 20090219022417: Cleanup X.L.Mosaic, without breaking it by Adam Vogt <vogt.adam(a)gmail.com> wmw: Works well for me. Own thread. [1] 20090220054704: Add TabbedModifier layout modifer by Adam Vogt * 20090220061819: Add TabbedModifier layout modifer by Adam Vogt <vogt.adam(a)gmail.com> wmw: Not sure if only last patch needed; DarcsWatch may have missed an amend-record. Test and comment. Own thread. = Not on XMC DarcsWatch = * 20090212170113: X.L.AddMaster: Master turned into a LayoutModifier wmw: [2] (same as ff. patch but as new module? obsolete?) * 20090213020453: X.L.Master: turn it to a Layout modifier and update the code by Ismael Carnales <icarnales(a)gmail.com> wmw: No comments yet. No opinion till I look more closely, seems like good idea. Own thread. = Needing action by author or new adopter= 20080926205838: dzenStatusBar by seanmce33(a)gmail.com, 20081002131304: layoutLogger, windowLogger, workspaceLogger,maildDir loggers by seanmce33(a)gmail.com gwern: byorgey tried to apply them, but failed. So we're blocked on sean re-sending them. wmw: if no other action next week or so, I'll submit versions against current repo, probably put dzenStatusBar in Util.Dzen instead. = Summary = Obsoletes have been cleaned out. Not much action since last time on controversial patches. Several new patches have been added since last review, including adam's tabbed modifier response to tabbed subpane requests. -- wmw

4 3