August 2010 - xmonad - Haskell.org

Re: Issue 4 in xmonad: Separate focus for tiled and floating layers
by codesite-noreply＠google.com 16 Oct '10

16 Oct '10

Comment #16 on issue 4 by scuz.there: Separate focus for tiled and floating layers http://code.google.com/p/xmonad/issues/detail?id=4 It might be more useful to have transients for a window hidden when that window is not focused. Similar to Photoshop on Mac. -- 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 8

Issue 366 in xmonad: XMonad.Layout.NoFrillsDecoration depends on SimpleDecoration
by codesite-noreply＠google.com 29 Sep '10

29 Sep '10

Status: New Owner: ---- New issue 366 by j...(a)kitenet.net: XMonad.Layout.NoFrillsDecoration depends on SimpleDecoration http://code.google.com/p/xmonad/issues/detail?id=366 What steps will reproduce the problem? 1.import XMonad.Layout.NoFrillsDecoration 2.do not import XMonad.Layout.SimpleDecoration 3. What is the expected output? What do you see instead? xmonad.hs:41:10: Not in scope: `defaultTheme' xmonad.hs:42:4: Not in scope: `activeColor' xmonad.hs:43:4: Not in scope: `inactiveColor' xmonad.hs:44:4: Not in scope: `activeBorderColor' xmonad.hs:45:4: Not in scope: `inactiveBorderColor' Etc. This goes away if SimpleDecoration is also imported. What version of the product are you using? On what operating system? 0.9 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Please provide any additional information below. -- 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 400 in xmonad: LayoutHints don't respect windows' hint changes without changing the workspace state
by codesite-noreply＠google.com 26 Sep '10

26 Sep '10

Status: New Owner: ---- New issue 400 by aleks.dimitrov: LayoutHints don't respect windows' hint changes without changing the workspace state http://code.google.com/p/xmonad/issues/detail?id=400 What steps will reproduce the problem? 1. Use a minimal configuration like: main = xmonad $ defaultConfig { layoutHook = layoutHints (XMonad.Tall 1 (1/2) (3/100)) } 2. Open Rhythmbox and press CTRL-D (to collapse the view to 'compact view') 3. Change the workspace state (toggle struts, change focus, launch stuff) What is the expected output? What do you see instead? I'd like XMonad to recognize Rhythmbox' state change without re-evaluation of the workspace state. XMonad however doesn't seem to be notified of Rhythmbox' preferred size, or maybe just doesn't react to it. Here's a couple of screenshots to illustrate the problem: http://imgur.com/THPdml&y5e0U&r6n58 First image shows what happens when RBX changes its appearance and XMonad doesn't react (these huge grey windows are exactly what I'm trying to avoid using hinted layouts.) Second image shows the desktop after a state change. That's what I'd like to see! Third image shows RBX expanding to its extended view again, but the window doesn't get bigger! It stays small and requires a workspace state change to go back to normal. What version of the product are you using? On what operating system? xmonad 0.9.1 (Ubuntu 10.04) Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Minimal reproducing config: > import XMonad > import XMonad.Layout.LayoutHints > main = xmonad $ defaultConfig > { layoutHook = layoutHints (XMonad.Tall 1 (1/2) (3/100)) } xmonad --recompile remains silent :-)

1 5

Issue 398 in xmonad: Make Keyboard Keys Position Dependant not Value Dependant
by codesite-noreply＠google.com 26 Sep '10

26 Sep '10

Status: New Owner: ---- New issue 398 by robertmassaioli: Make Keyboard Keys Position Dependant not Value Dependant http://code.google.com/p/xmonad/issues/detail?id=398 Prenote: This is a wishlist item and not critical. What is the problem? The problem is that anybody that creates an xmonad.hs for qwerty, for example, excludes anybody else using a different keyboard layout. And vice versa. However, when I create my xmonad.hs I find that I often only care about keyboard position and not the actual letter that I am pressing. You should be able to make your keyboard layout by specifying keyboard positions rather than the actual keys themselves. What is the expected result? This would allow better sharing of XMonad config files between everyone. And for those that specify by position, like me, it would be easier and more portable. I don't know how much effort it would really be though, but maybe you could change something small about it to make it work for you. I have a dummy function in my xmonad.hs that I may start using for that sort of portability called 'convertKeys': http://github.com/robertmassaioli/xmonad.hs/blob/master/xmonad.hs

1 4

Issue 404 in xmonad: windowPromptGoto lists NSP windows
by codesite-noreply＠google.com 25 Sep '10

25 Sep '10

Status: New Owner: ---- New issue 404 by rpglover64: windowPromptGoto lists NSP windows http://code.google.com/p/xmonad/issues/detail?id=404 What steps will reproduce the problem? 1. Import and set up NamedScratchpad and windowPromptGoto 2. Open and hide the scratchpad window 3. Use windowPromptGoto What is the expected output? What do you see instead? A list of windows, not including those on the scratch space. A list of windows, including those on the scratch space. What version of the product are you using? On what operating system? xmonad 0.9.1 on debian testing Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". Recompile is clean Please provide any additional information below. This is really more of a feature request than a bug... Attachments: xmonad.hs 6.1 KB

1 1

darcs patch: X.H.ManageDocks: event hook to refresh on new docks
by Tomas Janousek 25 Sep '10

25 Sep '10

Dear xmonad, for all of you who restart all your xmobars every now and then (for example on xinerama layout change), this makes xmonad behave a bit better: > 1 patch for repository http://code.haskell.org/XMonadContrib: > > Tue Jul 6 20:58:34 CEST 2010 Tomas Janousek <tomi(a)nomi.cz> > * X.H.ManageDocks: event hook to refresh on new docks -- Tomáš Janoušek, a.k.a. Liskni_si, http://work.lisk.in/

3 2

Issue 395 in xmonad: Support for multiple master windows for X.L.Master
by codesite-noreply＠google.com 25 Sep '10

25 Sep '10

Status: New Owner: ---- New issue 395 by quesel: Support for multiple master windows for X.L.Master http://code.google.com/p/xmonad/issues/detail?id=395 Find attached a patch that enables the contrib module X.L.Master to handle multiple master windows. Best Regards, Jan Attachments: master.patch 42.6 KB

1 4

Re: Issue 311 in xmonad: using noBorders on tabbed layout freezes tab bar on workspace change
by codesite-noreply＠google.com 12 Sep '10

12 Sep '10

Updates: Status: Accepted Labels: Type-Defect Component-Contrib Comment #5 on issue 311 by byorgey: using noBorders on tabbed layout freezes tab bar on workspace change http://code.google.com/p/xmonad/issues/detail?id=311 (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 2

Re: [xmonad] Upgrading repo formats
by Gwern Branwen 10 Sep '10

10 Sep '10

On Fri, Apr 23, 2010 at 3:40 PM, adam vogt <vogt.adam(a)gmail.com> wrote: > On Sat, Apr 10, 2010 at 1:16 PM, Gwern Branwen <gwern0(a)gmail.com> wrote: >> While waiting on a slow connection today to darcs get XMC, I had time >> to ponder. The patches are (or would be) in my global cache, so it >> could go much faster. Why doesn't it? Because xmonad-contrib and >> xmonad-core are both still using darcs-1 fomatted repositories. >> >> Is there any particular reason to not upgrade? Even Debian Stable has >> Darcs 2.x (http://packages.debian.org/lenny/darcs) so it's not as if >> there are many people who would be unable to do a darcs get. >> >> -- >> gwern > > I support this. > > Since this isn't something we can easily rollback, (without the messy > situation of keeping the unupgraded repository updated in parallel), it > is important to have some consensus before updating repo formats. What now? Nobody has objected here, and it's been several days, so I would guess not many will object in the future. I would point out that besides the mere 12 pulls using darcs 1.x this month - which could all be due to just 1 user - Xmonad has broken ghc 6.6 support, and I wouldn't be surprised if ghc 6.8 support was now broken. So anyone actually *using* darcs xmonad-core/xmonad-contrib must be using a recent GHC, and there are Darcs 2.xs which support 6.8 and probably 6.6 as well. Which implies that anyone using darcs xmonad is capable of upgrading to Darcs 2. We don't to worry about anyone locked down to Darcs 1.x. The question is whether we have the will to actually upgrade the repos and make people re-'darcs get' the repos. I think we do, and that the long-term benefits of cached patches and fewer conflicts and active Darcs support and whatnot justify the short-term pain. But ultimately, while I could unilaterally upgrade xmonad-contrib, dons and sjanssen are the only ones who can upgrade xmonad-core, and I'd feel pretty silly doing only half the job. -- gwern

5 7

Issue 401 in xmonad: Quick use of mouse in tabbed layout makes xmonad enter a loop switching windows
by codesite-noreply＠google.com 06 Sep '10

06 Sep '10

Status: New Owner: ---- New issue 401 by stenyak: Quick use of mouse in tabbed layout makes xmonad enter a loop switching windows http://code.google.com/p/xmonad/issues/detail?id=401 What steps will reproduce the problem? 1. Switch to tabbed layout. 2. Open at least two windows. 3. Click (click and release left mouse button) on the tab of another window. 4. Before the newly selected window is rendered on screen, move the mouse down to the (still old) window. Time between point 3 and 4 is about 200ms max in my computer (if you use the mouse fast or your computer is slow, the bug can happen very often, which is irritating). What is the expected output? What do you see instead? Xmonad should simply change to the newly selected window. Instead, it starts to switch from the old to the new window in an infinite loop. The window-switching loop can be ended by clicking on one of the tabs (without reproducing the bug again, which means, clicking "slowly"). What version of the product are you using? On what operating system? This is a Linux Mint. $ xmonad --version xmonad 0.8.1 $ uname -a Linux ironstk 2.6.31-19-generic #56-Ubuntu SMP Thu Jan 28 01:26:53 UTC 2010 i686 GNU/Linux $ cat /etc/debian_version squeeze/sid $ cat /etc/apt/sources.list deb http://packages.linuxmint.com/ helena main upstream import deb http://archive.ubuntu.com/ubuntu/ karmic main restricted universe multiverse deb http://archive.ubuntu.com/ubuntu/ karmic-updates main restricted universe multiverse deb http://security.ubuntu.com/ubuntu/ karmic-security main restricted universe multiverse deb http://archive.canonical.com/ubuntu/ karmic partner deb http://packages.medibuntu.org/ karmic free non-free Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". $ xmonad --recompile $ (the command doesn't output anything) Please provide any additional information below. Attachments: xmonad.hs 9.9 KB

1 1