- xmonad - Haskell.org

X.P.Shell, filter empty string from PATH
by Tim Horton 24 Dec '09

24 Dec '09

Hello, Wed Dec 23 19:32:17 PST 2009 Tim Horton <tmhorton(a)gmail.com> * X.P.Shell, filter empty string from PATH doesDirectoryExist returns True if given an empty string using ghc <= 6.10.4. This causes getDirectoryContents to raise an exception and X.P.Shell does not render. This is only an issue if you have an empty string in your PATH. Using ghc == 6.12.1, doesDirectoryExist returns False given an empty string, so this should not be an issue in the future. Thanks! Tim

1 0

darcs patch: X.L.MouseResizableTile: keep draggers on the bottom of...
by Tomas Janousek 23 Dec '09

23 Dec '09

Hello, skimming through byorgey's bug swipe, I noticed that #207 applies to MouseResizableTile as well. Thu Nov 26 18:34:13 CET 2009 Tomas Janousek <tomi(a)nomi.cz> * X.L.MouseResizableTile: keep draggers on the bottom of the window stack. Regards, -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/

4 4

"minimize" + "boringAuto" in Full-layout: focusUp and focusDown don't change focus
by Ralph Hofmann 23 Dec '09

23 Dec '09

Hi I am new to xmonad. I use version 0.9. I am trying to get "minimize" and "boringAuto" working together, like described here: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Layout-Minimize.html "The module is designed to work together with XMonad.Layout.BoringWindows so that minimized windows will be skipped when switching the focus window with the keyboard. Use the boringAuto function." The layout is: myLayout = boringAuto $ minimize (Full ||| tiled ||| Mirror tiled) where tiled = Tall nmaster delta ratio nmaster = 1 delta = 1/12 ratio = 1/2 Everythings works fine, except the Full-mode. In Full-mode the functions focusUp and focusDown from XMonad.Layout.BoringWindows don't switch to the next or previous window. They do nothing. I would like to be able to cycle in Full-mode through all windows but the minimized windows. Is there anything, I can do? Ralph

3 9

Issue 355 in xmonad: XMonad.Actions.WindowGo (runOrRaise) fails on the specific command "chromium"
by codesite-noreply＠google.com 23 Dec '09

23 Dec '09

Status: New Owner: ---- New issue 355 by vox.cogitatio: XMonad.Actions.WindowGo (runOrRaise) fails on the specific command "chromium" http://code.google.com/p/xmonad/issues/detail?id=355 What steps will reproduce the problem? 1.Use keybinding to spawn chromium. 2.Use keybinding to runOrRaise chromium. What is the expected output? What do you see instead? When chromium is not running, these keybindings should do the same thing (i.e launch chromium). Instead, the spawn keybinding works as intended while the runOrRaise binding does nothing. When chromium is already running, the runOrRaise binding will raise the window as intended. Oddly enough i have only seen this error with chromium specifically, not any other commands. What version of the product are you using? On what operating system? Xmonad 0.9-2, on Arch Linux. Attachments: xmonad.hs 1.6 KB -- 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 10

darcs patch: Actions/Search: added openstreetmap
by intrigeri＠boum.org 22 Dec '09

22 Dec '09

Tue Dec 22 12:45:45 CET 2009 intrigeri(a)boum.org * Actions/Search: added openstreetmap

2 1

gnome-terminal scrolling issue
by Mohamed Bana 22 Dec '09

22 Dec '09

hi All, re-sending because it appears, by looking at the archives, that it didn't like my attachment. here's a link instead http://img51.imageshack.us/img51/8770/screenshotxf.png. Please have a look at the screenshot attached. Whenever I launch a new a window, in this case a Swing one, gnome-terminal scrolls unnecessarily. It's very annoying. Xterm is fine, but I prefer to use gnome-terminal because of tabs. If anyone has come across and/or has fix, I'd appreciate if could forward it. please CC me on reply. —Mohamed

1 0

Re: Issue 312 in xmonad: [improvement] MosaicAlt: change tall/wide
by codesite-noreply＠google.com 21 Dec '09

21 Dec '09

Updates: Status: Accepted Labels: Type-Enhancement Component-Contrib Comment #2 on issue 312 by byorgey: [improvement] MosaicAlt: change tall/wide http://code.google.com/p/xmonad/issues/detail?id=312 (No comment was entered for this change.) -- 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 3

Issue 353 in xmonad: XMonad.Prompt.Window's prefix search isn't always the best option
by codesite-noreply＠google.com 21 Dec '09

21 Dec '09

Status: New Owner: ---- New issue 353 by novas0x2a: XMonad.Prompt.Window's prefix search isn't always the best option http://code.google.com/p/xmonad/issues/detail?id=353 XMonad.Prompt uses isPrefixOf as the filter predicate for doPrompt. That's not always the best option- for example, I prefer isInfixOf. Here's a patch that makes it an option. It's cut against 0.9.1. This implementation is only one of many possible ways for me to get my way, but I'm not set on this particular method :) Attachments: 0001-Add-a-predicate-option-to-XMonad.Prompt.patch 2.1 KB -- 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 3

Re: [xmonad] "minimize" + "boringAuto" in Full-layout: focusUp and focusDown don't change focus
by Ralph Hofmann 21 Dec '09

21 Dec '09

> I guess so, but I feel focus skipping of minimized windows is an > integral part of X.L.Minimize, so the module might as well do the work > itself of making sure the correct windows are marked as boring. I think so too. In my opinion X.L.Minimize should do its work without AutoBoring. Boring and Minimizing are different things und should be handled as such. But then we have three different focusing functions and maybe will have even more in the future from other moduls. That's probably not good. Instead of defining a complete focusing functions within a module, wouldn't it be better, to define only something like a focusingModifier? Thus we can write something like: myfocusingFunction = focusingModifier coreFocusingFunction in monad.hs. The user can choose his preferred modifier and can even combine them: myfocusingFunction = focusingModifier1 $ focusingModifier2 coreFocusingFunction Ralph Es weihnachtet sehr! Vom leckerem Backrezept bis zum leckeren Schneehasen finden Sie alles im Weihnachtsspecial von Arcor.de: http://www.arcor.de/rd/footer.weihnachten Feliz Navidad, God Yul, Merry X-Mas und ein frohes Fest!

2 1

New DarcsWatch features
by Joachim Breitner 21 Dec '09

21 Dec '09

Hi, if you follow planet.haskell.org you’ll have read that I attended the Darcs hacking sprint in Vienna. Together with the Darcs guys I integrated DarcsWatch better into their patch submission and review process. Let me outline it quickly * Darcs patches are sent to patches(a)darcs.net. * A new ticket (of type patch, not issue) is automatically created in their roundup instance. * The patch, with a reference to the ticket number, is sent by roundup to the darcs-users mailing list. * DarcsWatch is subscribed to that list and notices this mail as usual. * DarcsWatch detects the roundup patch tracker URL in the mail and remembers it. * It also sets a special "darcswatchurl" property of the roundup ticket (via e-Mail), to add a link to DarcsWatch on the roundup ticket view. * When the patch is eventually applied, DarcsWatch sends a mail to the roundup ticket, setting its state to "applied". A message about this is sent to the darcs-user list. This is not directly applicable to xmonad, of course. But due to the re-organization of the DarcsWatch code some new possibilities arise: 1. DarcsWatch could send bundle-applied-mails to the mailing list. Since patch submissions are on the list, this would we useful for people just following development. Also the submitter is likely happy to hear that his patch has been applied, without checking the repository or DarcsWatch. OTOH it would slightly increase the noise level on the list. 2. Users can subscribe to bundle-applied-mails about their own patches. It would be relatively easy to implement that I can give DarcsWatch a list of e-Mail-Adresses that want “Your bundle α was applied to repository β” notifications. This would be independent of xmonad, of course. Is anyone interested? I’d start with manually configuring the list with addresses people tell me about, and maybe later add an automatic subscription feature, if there is demand. 3. DarcsWatch could be integrated closer in the xmonad bug tracker. Of course, code.google.com will not be as easily hackable as a self-hosted roundup instance, but maybe some interaction is possible. Is there an API for that? Some features that are desirable are: * DarcsWatch should somehow be aware of patches submitted via code.google.com that were not sent to the mailing list. * DarcsWatch could be able to amend the ticket with the patch application status. * DarcsWatch could close tickets if a patch bundle is applied – but what if the patch does not work, if there are multiple patches etc.? The Darcs team has clearer semantics there, as patches and issues are tracked separately on roundup (but can refer to each other). Especially item 3 is meant to be a discussion starter :-) Greetings, Joachim -- Joachim "nomeata" Breitner mail: mail(a)joachim-breitner.de | ICQ# 74513189 | GPG-Key: 4743206C JID: nomeata(a)joachim-breitner.de | http://www.joachim-breitner.de/ Debian Developer: nomeata(a)debian.org

4 8