From sjanssen at cse.unl.edu Fri Feb 1 01:08:24 2008 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Fri Feb 1 01:08:30 2008 Subject: [xmonad] ClientMessage events in 0.7? In-Reply-To: <20080131192053.GP4849@laptop.nowhere.net> References: <1201768408.3815.5.camel@otto.ehbuehl.net> <20080131084243.GF4849@laptop.nowhere.net> <1201769235.3815.7.camel@otto.ehbuehl.net> <20080131091049.GG4849@laptop.nowhere.net> <20080131190949.GA6492@presario> <20080131192053.GP4849@laptop.nowhere.net> Message-ID: <20080201060823.GA5288@presario> On Thu, Jan 31, 2008 at 08:20:53PM +0100, Andrea Rossato wrote: > On Thu, Jan 31, 2008 at 01:09:49PM -0600, Spencer Janssen wrote: > > Think about what will happen when there are multiple visible workspaces -- ie. > > Xinerama. > > actually we were discussing just that a couple of threads above with > Brent, and we came up with a couple of class methods that could just > solve this problem, by passing to the layout the Workspace it is > going to be run on. > > Brent rejected that, because it would bloat the LayoutClass. And he > may have a point, as long as extending a class is bad. > > as you know I don't get xinerama quite well, but as far as I get it in > a xinerama setup a workspace cannot be in two screens at the same > time. > > Am I right? > > cheers, > > Andrea The problem is that these EWMH events should be processed by the window manager only once, globally -- so we have a problem if two workspaces with the EWMH layout modifier are visible at the same time (this will always happen if the user defines it as part of their layout hook and there are two or more monitors). From sjanssen at cse.unl.edu Fri Feb 1 01:22:32 2008 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Fri Feb 1 01:22:36 2008 Subject: [xmonad] The future of PerWorkspace In-Reply-To: <20080131202130.GQ4849@laptop.nowhere.net> References: <22fcbd520801301629t4ed0497fyec06fad5075e590e@mail.gmail.com> <20080131194232.GB6492@presario> <20080131202130.GQ4849@laptop.nowhere.net> Message-ID: <20080201062231.GB5288@presario> On Thu, Jan 31, 2008 at 09:21:30PM +0100, Andrea Rossato wrote: > On Thu, Jan 31, 2008 at 01:42:32PM -0600, Spencer Janssen wrote: > > On Wed, Jan 30, 2008 at 07:29:58PM -0500, Brent Yorgey wrote: > > > 1. PerWorkspace is an inelegant hack with several icky problems: > > > > Agreed. It is approaching the limits of xmonad's layout design. (here, I'm specifically speaking to the issue of PerWorkspace and multi-head) > actually I don't think this is true. I believe that the LayoutClass > can be far more expressive that it is now just by adding a couple of > trivial methods. I've sent a patch two messages ago. That kind of > approach seems to me to be cleaner that yours (which, as far as I get > it requires messages going around to know where you are). As far as I know, there has only been one other proposal that solves the Xinerama issues with PerWorkspace -- adding a WorkspaceId argument to doLayout. I think we've all agreed that isn't so nice. My message proposal is actually very similar -- except that only layouts that care about workspace location need to handle these messages, whereas an extra argument to doLayout must be mentioned in every single layout instance. Have you proposed another implementation that solves the Xinerama issue, and I missed it? Cheers, Spencer Janssen From mailing_list at istitutocolli.org Fri Feb 1 01:48:57 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 01:48:49 2008 Subject: [xmonad] The future of PerWorkspace In-Reply-To: <20080201062231.GB5288@presario> References: <22fcbd520801301629t4ed0497fyec06fad5075e590e@mail.gmail.com> <20080131194232.GB6492@presario> <20080131202130.GQ4849@laptop.nowhere.net> <20080201062231.GB5288@presario> Message-ID: <20080201064857.GS4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 12:22:32AM -0600, Spencer Janssen wrote: > As far as I know, there has only been one other proposal that solves the > Xinerama issues with PerWorkspace -- adding a WorkspaceId argument to doLayout. > I think we've all agreed that isn't so nice. My message proposal is actually > very similar -- except that only layouts that care about workspace location > need to handle these messages, whereas an extra argument to doLayout must be > mentioned in every single layout instance. > > Have you proposed another implementation that solves the Xinerama issue, and I > missed it? Yes you did. You actually did miss quite a lot of the stuff I've been sending recently. You are not the only one, though. As I say I did not propose to change doLayout, but just to change, in runLayout, doLayout with a doLayoutInWorkspace which takes the workspace and calls "doLayout (layout w)". The same for (emptyLayoutInWorkspace w = emptyLayout (layout w) and handleMessage. Did you read this message and the attached patch? http://www.haskell.org/pipermail/xmonad/2008-January/004493.html If a layout may be knowing the workspace it is running on, we could implement a general purpose combinator (my LayoutCombinator class and a general purpose CombinedLayout, implemented on top of the layout class. If we get to class level composition - by changing the description type, we can implement ANY combinator within the layout hook. Combinators, in this case, may be receiving messages and run one, layout, run the other, run both and combine their result, or run none, handle the message, and return a new combinator. This solves xinerama and we can eliminate duplicate code in Choose, NewSelect, ToogleWorskpace, PerWorkspace. As I mention here: http://code.google.com/p/xmonad/issues/detail?id=129 (I answered to your challenge, but you did not to mine!), with my proposal, PerWorkspace implementation would be: instance LayoutCombinator PerWorkspace a where chooser (PerWorkspace wsIds) = do t <- getCurrentTag return $ if t `elem` wsIds then DoFirst else DoSecond Obviously here I'm using class level composition. Can you really claim your implementation would be cleaner? Show me the code, please. I showed mine, which is actually working. That implementation IS ACTUALLY working and has been in xmc repository for a couple of days. Than I had to remove it since I asked for core support and I was told I would not get it. So, I removed it. And I asked you to forget all related patches. Cheers, Andrea From mailing_list at istitutocolli.org Fri Feb 1 01:52:51 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 01:52:08 2008 Subject: [xmonad] ClientMessage events in 0.7? In-Reply-To: <20080201060823.GA5288@presario> References: <1201768408.3815.5.camel@otto.ehbuehl.net> <20080131084243.GF4849@laptop.nowhere.net> <1201769235.3815.7.camel@otto.ehbuehl.net> <20080131091049.GG4849@laptop.nowhere.net> <20080131190949.GA6492@presario> <20080131192053.GP4849@laptop.nowhere.net> <20080201060823.GA5288@presario> Message-ID: <20080201065251.GT4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 12:08:24AM -0600, Spencer Janssen wrote: > The problem is that these EWMH events should be processed by the window manager > only once, globally -- so we have a problem if two workspaces with the EWMH > layout modifier are visible at the same time (this will always happen if the > user defines it as part of their layout hook and there are two or more > monitors). As I said in the previous message, with class level composition I can (I did!) implement an abstract combinator that can just do that: if a give condition is met, the combinator may handle the message even *without* running the layout. I believe that the combinaotr semantics is an unknown object here. I've been investigating it, since I wrote a class to map it. I know how much powerful it can be. But if I'm wrong I'd like you to show me where I get it wrong. Cheers Andrea From codesite-noreply at google.com Fri Feb 1 02:05:57 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 02:05:12 2008 Subject: [xmonad] Issue 126 in xmonad: Restarting xmonad doesn't work Message-ID: <0016e649d3b804451367f8ea96291a6b@google.com> Issue 126: Restarting xmonad doesn't work http://code.google.com/p/xmonad/issues/detail?id=126 Comment #4 by v.dijk.bas: Spencer you're right. I've installed xmonad in my home dir and I only added it to my $PATH inside my ~/.bashrc. I gues that ~/.bashrc is never executed when xmonad starts so when I restart it, it can't find xmonad. I solved it by listing the full path to xmonad in my config: , ((modMask , xK_q ), restart "/home/bas/bin/xmonad" True) This bug, which is not really a bug anymore, can be closed. Thanks very much for your help! -- 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 From mailing_list at istitutocolli.org Fri Feb 1 02:49:32 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 02:49:19 2008 Subject: [xmonad] The future of PerWorkspace In-Reply-To: <20080201064857.GS4849@laptop.nowhere.net> References: <22fcbd520801301629t4ed0497fyec06fad5075e590e@mail.gmail.com> <20080131194232.GB6492@presario> <20080131202130.GQ4849@laptop.nowhere.net> <20080201062231.GB5288@presario> <20080201064857.GS4849@laptop.nowhere.net> Message-ID: <20080201074932.GU4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 07:48:57AM +0100, Andrea Rossato wrote: > That implementation IS ACTUALLY working and has been in xmc repository > for a couple of days. Than I had to remove it since I asked for core > support and I was told I would not get it. > > So, I removed it. And I asked you to forget all related patches. by any chance, did you happen to read this bug report? http://code.google.com/p/xmonad/issues/detail?id=127 cheers, andrea ps: all this stuff has been documented by me here: http://www.haskell.org/pipermail/xmonad/2008-January/004378.html http://www.haskell.org/pipermail/xmonad/2008-January/004398.html http://www.haskell.org/pipermail/xmonad/2008-January/004400.html http://www.haskell.org/pipermail/xmonad/2008-January/004401.html http://www.haskell.org/pipermail/xmonad/2008-January/004417.html http://www.haskell.org/pipermail/xmonad/2008-January/004424.html http://www.haskell.org/pipermail/xmonad/2008-January/004440.html http://www.haskell.org/pipermail/xmonad/2008-January/004441.html http://www.haskell.org/pipermail/xmonad/2008-January/004442.html http://www.haskell.org/pipermail/xmonad/2008-January/004443.html yesterday's messages omitted. there are some other messages, sent before, documenting the progress of the changes and giving testing example. pps: i'm reading the IRC logs and I see someone is complaining because I would be experimenting with his/her window manager, and that I should keep my stuff in a private repository. from http://code.haskell.org/~dons/irc/xmonad/2008-01-29.txt: 09:26:29 still no comments/feedback on the new code I proposed... ... 19:40:10 sjanssen dons: did you have a look at my code? 19:41:25 arossato: a little bit. Feel free to push it to the mainline any time 19:42:02 yeah, seriously, if you've considered it well, and it only affects config stuff, and you know its not going to break things, go ahead. 19:42:07 sjanssen: I've just sent the LayoutCombinator class, with PerWorkspace ported to it. 19:42:42 dons: it is going to make everything A LOT safer 19:43:38 arossato: I think the way forward is to push it into the mainline -- we can start collecting bug reports (if any exist) 19:43:49 and it will prod me a bit more to take a closer look :) 19:43:58 its a good time to push too. 19:44:07 do it now, and we'll have 4-6 weeks to sort it all out. 19:45:15 I'm going to push within a hour (after dinner) ... 20:00:51 droundy: the LayoutCombinator class is quite an interesting beast... I was able to implement PerWorkspace in a few lines... to be explored, definitely! ... 20:04:41 pushed! have a nice day! From lobzang at free.fr Fri Feb 1 03:29:08 2008 From: lobzang at free.fr (lobzang@free.fr) Date: Fri Feb 1 03:28:25 2008 Subject: [xmonad] Moving windows to a workspace based on their title / console applications in terminal emulators In-Reply-To: <20080131155001.GA27619@localhost> References: <1201766787.47a181833713c@imp.free.fr> <20080131155001.GA27619@localhost> Message-ID: <1201854548.47a2d854c691e@imp.free.fr> Hey ! Indeed there is a bug. I did a simple test : 1)with urxvt urxvt -name icq --> xprop says WM_CLASS(STRING) = "icq", "URxvt" --> xmonad puts the window matching URxvt pattern , not icq 2)with xterm xterm -class icq --> xprop says WM_CLASS(STRING) = "xterm", "icq" --> the window is placed in my icq workspace. Again xmonad seems to take only the second class string to match So for now you can probably use xterm... Lobzang. Quoting Bastian Schnitzler : > Hi! > I did: > > [ className =? "Icq" --> doF (W.shift "2") ], > [ className =? "irssiterm" --> doF (W.shift "2") ], > [ className =? "muttterm" --> doF (W.shift "2") ], > > and still urxvt -name Icq -title Icq stays on the same workspace, same for > other classnames. > Does it work for you? > > Bastian > > On 09:06 Thu 31 Jan , lobzang@free.fr wrote: > > Hi, > > > > urxvt -name icq -e centerim > > urxvt -name mail -e mutt > > > > should do the trick ( assuming you update your xmonad window rules : > > , className =? "icq" --> doF (W.shift "icq" ) > > , className =? "mail" --> doF (W.shift "mail" ) > > > > Lobzang > > > > Quoting Bastian Schnitzler : > > > > > Hi all! > > > For many purposes I am using console applications, like centerim, > > > irssi or mutt. Now when I start xmonad, I'd like to open a bunch of > > > applications (Can I do this via .xinitrc), like firefox, mutt, etc. > > > These should then be moved to a workspace, based on the application > > > running. So when I start an rxvt-Terminal with mutt, I want this to be > > > moved to workspace 3, how can I do this? On top of that I can't figure > > > out how to move gimp to a special workspace. I have setten it to > > > float, but I tried the class names, gimp, Gimp, gimp-2.2 etc. but it > > > won't go to the workspace I want, when I start it. Anyway what is this > > > class name to identify a window? Is it the process name? > > > Thanks in advance, > > > Bastian Schnitzler > > > > > > > > > From sjanssen at cse.unl.edu Fri Feb 1 03:51:33 2008 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Fri Feb 1 03:51:37 2008 Subject: [xmonad] some cleanup In-Reply-To: <20080131103538.GL4849@laptop.nowhere.net> References: <20080131103538.GL4849@laptop.nowhere.net> Message-ID: <20080201085132.GA5320@presario> On Thu, Jan 31, 2008 at 11:35:38AM +0100, Andrea Rossato wrote: > Hi, > > I'm now trying to clean up a bit after this long and stressful class > ride (I even started dreaming about type classes, such is the > addictive power of this stuff). > > Now I'm going to take a break and enter in a maintainer mode: just > debugging and docs. > > Spencer: I'm still waiting your decisions about tabbed. Should it > return all windows and thus use the decoration framework, of should it > be e separated layout (the previous one) returning just the focused > window? Please, take a decision, because at the present time tabbed is > plainly broken (my fault since I gave you wrong information... but I > was a bit confused when you asked). > > Anyway you can just: 1. push a simple patch to make it use Simplest, > or 2. get a version of the old tabbed and copy it over the new one: it > should be working out of the box (maybe users will have to import it > qualified). > > The reason why it should not return all windows is still a bit > mysterious to me... what you said, I don't remember exactly, seemed to > me more a bug in the X server then a feature. But I came to be a bit > confused on the distinction between the two, lately...;) > > Bugs may come to me! > > Andrea The tabbed layout should only return the focused window -- there are performance implications (much fewer expose events and repaints generated), it gives better information to layout modifiers that count the number of returned windows (like smartBorders), and it's just the right thing to do (non-visible windows should be in the unmapped state is standard WM convention). However, I don't think there's any reason we can't use Decorations. Of course, we'll need to generalize Decorations a bit. There are a few options: - Run 'decorate' even on windows that aren't returned by doLayout (perhaps use Maybe Rectangle as an argument, where Nothing signifies the window isn't visible) - Allow 'decorate' to return a list of decorations, rather than a single decoration. I haven't been able to divine the logic behind the code to make either modification myself, but I might be able to with a bit of documentation tossed in there :) I'm inclined to leave the base layout as Full, even though that is slightly broken at the moment. Thus are the perils of running software-in-development. Cheers, Spencer Janssen From sjanssen at cse.unl.edu Fri Feb 1 03:58:57 2008 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Fri Feb 1 03:59:01 2008 Subject: [xmonad] Moving windows to a workspace based on their title / console applications in terminal emulators In-Reply-To: <1201854548.47a2d854c691e@imp.free.fr> References: <1201766787.47a181833713c@imp.free.fr> <20080131155001.GA27619@localhost> <1201854548.47a2d854c691e@imp.free.fr> Message-ID: <20080201085857.GA6789@presario> On Fri, Feb 01, 2008 at 09:29:08AM +0100, lobzang@free.fr wrote: > Hey ! > > Indeed there is a bug. > I did a simple test : > > 1)with urxvt > urxvt -name icq > --> xprop says WM_CLASS(STRING) = "icq", "URxvt" > --> xmonad puts the window matching URxvt pattern , not icq > > 2)with xterm > xterm -class icq > --> xprop says WM_CLASS(STRING) = "xterm", "icq" > --> the window is placed in my icq workspace. Again xmonad seems to take only > the second class string to match > > So for now you can probably use xterm... > > Lobzang. You're observing the difference between class name and resource name. Apparently 'xterm -class' sets the class name (called className in ManageHook), but 'urxvt -name' sets resource name (called resource in ManageHook). From mailing_list at istitutocolli.org Fri Feb 1 05:00:58 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 05:00:45 2008 Subject: [xmonad] some cleanup In-Reply-To: <20080201085132.GA5320@presario> References: <20080131103538.GL4849@laptop.nowhere.net> <20080201085132.GA5320@presario> Message-ID: <20080201100058.GV4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 02:51:33AM -0600, Spencer Janssen wrote: > I haven't been able to divine the logic behind the code to make either > modification myself, but I might be able to with a bit of documentation tossed > in there :) > > I'm inclined to leave the base layout as Full, even though that is slightly > broken at the moment. Thus are the perils of running software-in-development. this could be a clean solution, but I didn't test it. Basically it is a layout modifier that will take the first decoration and the first window, and then would just select decorations. That is, if placed on top of tabbed, it should be removing all unfocused windows, without touching decorations. -- | Removes windows for the tabbed layout windowRemove :: l a -> ModifiedLayout WindowRemover l a windowRemove = ModifiedLayout WindowRemover data WindowRemover a = WindowRemover deriving (Show, Read) instance LayoutModifier WindowRemover Window where redoLayout _ _ _ wrs = do nws <- end return (start ++ nws, Nothing) where start = take 2 wrs end = filterM (isNotDeco) (drop 2 wrs) isNotDeco (w,_) = do b <- isDecoration w return (not b) This way tabbed will be using Simplest, but xmonad would receive just the first window and all the correctly placed decorations. I'll test it and will let you know.[1] Docs: actually I though it could be fun to have the help of someone else to design the class, and improve its expressiveness. I didn't documented it because this was intended as a proposal to being discussed. I'd really beg you to read my previous messages and ask me whatever question you feel like (if I start telling the whole story every time, everything gets just more confused). I'm off the IRC channel also because I don't want to make the same mistake I did with you last time. This is quite difficult stuff for me, and I need to think a bit before answering (I'm also a bit tired... that has been one of the most rapid learning experiences I've had the last few years). I'd really appreciate any available help. Cheers, Andrea [1] At the present time, when I was trying to test it, I started experiencing strange problems with the linker: /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o): In function `s1e0s_info': ghc3557_0.hc:(.text+0x3ada): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_info' /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o):(.rodata+0xa8): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_closure' collect2: ld returned 1 exit status I've never touched neither WindowNavigator nor Combo... strange. I'll clean and retry. From kai at emptydomain.de Fri Feb 1 05:05:47 2008 From: kai at emptydomain.de (Kai Grossjohann) Date: Fri Feb 1 05:05:03 2008 Subject: [xmonad] Trying to code jump-or-execute In-Reply-To: References: Message-ID: <47A2EEFB.6030704@emptydomain.de> The extension XMonad.Prompt.Window allows you to enter a window name (with completion), then teleports you to that window. So this extension already does what you need: get a list of windows, find the right one. Kai Joseph Garvin wrote: > I'm a former sawfish user, and I used to have this really awesome > keyboard shortcut called "jump-or-exec". I would press for example > Super+F, and if Firefox was not running, it would be executed, and if > it was already running, then it would be given focus. I had similar > shortcuts for emacs, terminals, etc. > > I'm a bit of a haskell newb -- I can tell that I can simply use > 'spawn' to launch a process, and if I had a list of current windows I > would know how to iterate through them and find out whether one > currently exists, but I don't know how to get such a list. Ideally I'd > like to be able to match against window title or class. Is there a way > to do this with xmonad? > ------------------------------------------------------------------------ > > _______________________________________________ > xmonad mailing list > xmonad@haskell.org > http://www.haskell.org/mailman/listinfo/xmonad > From mailing_list at istitutocolli.org Fri Feb 1 06:02:31 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 06:01:52 2008 Subject: [xmonad] some cleanup In-Reply-To: <20080201100058.GV4849@laptop.nowhere.net> References: <20080131103538.GL4849@laptop.nowhere.net> <20080201085132.GA5320@presario> <20080201100058.GV4849@laptop.nowhere.net> Message-ID: <20080201110231.GW4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 11:00:58AM +0100, Andrea Rossato wrote: > [1] At the present time, when I was trying to test it, I started > experiencing strange problems with the linker: > > /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o): In function `s1e0s_info': > ghc3557_0.hc:(.text+0x3ada): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_info' > /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o):(.rodata+0xa8): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_closure' > collect2: ld returned 1 exit status > It seems like I found a bug in ghc-6.6.1 and I need to upgrade to 6.8.2. Now that is going to be a bit of a pain... Anyhow, the code I'm sending in a separate patch seems to work fine with ghc-6.8.2. Cheers, Andrea From mailing_list at istitutocolli.org Fri Feb 1 06:02:04 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 06:01:53 2008 Subject: [xmonad] darcs patch: Add windowRemover for make tabbed return just the focu... Message-ID: <200802011102.m11B24oj006771@laptop.nowhere.net> Hi, this is a follow up of the discussion with Spencer about tabbed. This patch implements WindowRemover. If placed over tabbed it should be removing unfocused windows, without touching the windows decoration. WARNING: while this patch passes all tests both with ghc-6.6.1 and ghc-6.8.2, when I build this test file: import XMonad import XMonad.Config.Arossato main = xmonad =<< arossatoConfig ghc-6.6.1 fails with this linker error: [12:00:33][wolf@laptop:~/.xmonad]$ ghc --make xmonad.hs Linking xmonad ... /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o): In function `s1e0s_info': ghc3557_0.hc:(.text+0x3ada): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_info' /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o):(.rodata+0xa8): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_closure' collect2: ld returned 1 exit status The same code compiles, and works perfectly (unless bugs introduced by its author, me) on ghc-6.8.2. This is why I'd like someone to test it (I'll include it also in the bug tracker). Cheers, Andrea Fri Feb 1 11:55:05 CET 2008 Andrea Rossato * Add windowRemover for make tabbed return just the focused window -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/x-darcs-patch Size: 23697 bytes Desc: A darcs patch for your repository! Url : http://www.haskell.org/pipermail/xmonad/attachments/20080201/8692984d/attachment-0001.bin From codesite-noreply at google.com Fri Feb 1 06:08:18 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 06:07:32 2008 Subject: [xmonad] Issue 125 in xmonad: Tabbed layout not working anymore Message-ID: <000e0cd229d8044516caa6861f14a1c6@google.com> Issue 125: Tabbed layout not working anymore http://code.google.com/p/xmonad/issues/detail?id=125 Comment #13 by andrea.rossato: attached you'll find a patch that should fix tabbed in a way Spencer may judge correct (that is to say by returning only the focused window). To be used in the layout hook as: windowRemove (tabbed shrinkText defaultTheme) Unfortunately this patch seems to hit a ghc-6.6.1 bug. When I apply it, while the contrib libary will build just fine, the linker will fail when compiling ~/.xmonad/xmonad.hs with this error message: /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o): In function `s1e0s_info': ghc3557_0.hc:(.text+0x3ada): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_info' /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o):(.rodata+0xa8): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_closure' collect2: ld returned 1 exit status Unfortunately I cannot understand what the problem is, neither how to address it. Please give me some direction. Attachments: tabbedFix.dpatch 23.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 From codesite-noreply at google.com Fri Feb 1 06:21:19 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 06:20:34 2008 Subject: [xmonad] Issue 125 in xmonad: Tabbed layout not working anymore Message-ID: <001636e0a7b8044516f934491614afb6@google.com> Issue 125: Tabbed layout not working anymore http://code.google.com/p/xmonad/issues/detail?id=125 Comment #14 by andrea.rossato: please note that this patch would make it possible also to have a simple tabbed layout that returns all windows. This second version can be used with the WindowArranger to create a mixed tabbed/floating layout: windows are full screen with tabs, but you can resize them and move them around. that linker issue bugs me quite a lot, though. -- 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 From sehnsucht.nach.unendlichkeit at quantentunnel.de Fri Feb 1 04:16:31 2008 From: sehnsucht.nach.unendlichkeit at quantentunnel.de (Tom Rauchenwald) Date: Fri Feb 1 06:44:22 2008 Subject: [xmonad] Re: some cleanup References: <20080131103538.GL4849@laptop.nowhere.net> <20080201085132.GA5320@presario> Message-ID: <87k5lprq8g.fsf@sec.modprobe.de> Spencer Janssen writes: > The tabbed layout should only return the focused window -- there are > performance implications (much fewer expose events and repaints generated), it > gives better information to layout modifiers that count the number of returned > windows (like smartBorders), and it's just the right thing to do (non-visible > windows should be in the unmapped state is standard WM convention). What about when running a composite manager? I run xcompmgr (at least occasionally) and noticed that now the inactive tabs can be seen in a translucent term, previously only the desktop background would shine through. > Cheers, > Spencer Janssen Tom From mailing_list at istitutocolli.org Fri Feb 1 07:04:01 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 07:03:51 2008 Subject: [xmonad] Re: some cleanup In-Reply-To: <87k5lprq8g.fsf@sec.modprobe.de> References: <20080131103538.GL4849@laptop.nowhere.net> <20080201085132.GA5320@presario> <87k5lprq8g.fsf@sec.modprobe.de> Message-ID: <20080201120401.GX4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 10:16:31AM +0100, Tom Rauchenwald wrote: > What about when running a composite manager? I run xcompmgr (at least > occasionally) and noticed that now the inactive tabs can be seen in a > translucent term, previously only the desktop background would shine > through. Sorry if I ask, but I don't use this stuff (I don't have to hardware for): do you think that the effects you are noticing are an improvement, or a bug? Thanks, Andrea From codesite-noreply at google.com Fri Feb 1 07:13:24 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 07:12:38 2008 Subject: [xmonad] Issue 130 in xmonad: The Decoration modifier should be decoration aware Message-ID: <000e0cd229d8044517b372370f14e86b@google.com> Issue 130: The Decoration modifier should be decoration aware http://code.google.com/p/xmonad/issues/detail?id=130 New issue report by andrea.rossato: At the present time, placing a Decoration modifier over another Decoration modifier would (probably) produce a big mess, because the top modifier will try to decorate decoration too. The implementation is trivial, still we can do it in two way: 1. in the DecorationStyle class: a. a method? decorateDecoration :: Bool b. within decoration? 2. in the Decoration modifier instance, in resync, before calling decorate. Any idea? (I'm marking this as an enhancement, since I originally conceived the decoration modifier as a non composable modifier. Maybe this design decision is the real bug...;) Issue attributes: Status: Accepted Owner: andrea.rossato Labels: Type-Enhancement Priority-Medium -- 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 From codesite-noreply at google.com Fri Feb 1 07:17:24 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 07:16:39 2008 Subject: [xmonad] Issue 125 in xmonad: Tabbed layout not working anymore Message-ID: <000e0cd32c24044517c1c6c4dd14e790@google.com> Issue 125: Tabbed layout not working anymore http://code.google.com/p/xmonad/issues/detail?id=125 Comment #15 by v.dijk.bas: I applied your patch and rebuild XMonadContrib without problems in GHC 6.8.2. I updated my layouthook so that 'windowRemove' is applied to the tabbed layout. This works perfectly. The only thing that remains, from a user point of view, is the ability to click on the tabs (decorations) to switch to the window. One question: shouldn't 'windowRemove' be used inside 'tabbed' in 'XMonad.Layout.Tabbed'. So that users don't have to remember to apply it to 'tabbed'? -- 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 From tim at we-are-teh-b.org Fri Feb 1 07:20:46 2008 From: tim at we-are-teh-b.org (Tim Schumacher) Date: Fri Feb 1 07:20:30 2008 Subject: [xmonad] Re: some cleanup In-Reply-To: <20080201120401.GX4849@laptop.nowhere.net> References: <20080131103538.GL4849@laptop.nowhere.net> <20080201085132.GA5320@presario> <87k5lprq8g.fsf@sec.modprobe.de> <20080201120401.GX4849@laptop.nowhere.net> Message-ID: <87zlukvpep.wl%tim@we-are-teh-b.org> At Fri, 1 Feb 2008 13:04:01 +0100, Andrea Rossato wrote: > > On Fri, Feb 01, 2008 at 10:16:31AM +0100, Tom Rauchenwald wrote: > > What about when running a composite manager? I run xcompmgr (at least > > occasionally) and noticed that now the inactive tabs can be seen in a > > translucent term, previously only the desktop background would shine > > through. > > Sorry if I ask, but I don't use this stuff (I don't have to hardware > for): do you think that the effects you are noticing are an > improvement, or a bug? IMHO this would be a bug. Since the other windows are on their tabs and not in the background. greetings Tim -- The opposite of a correct statement is a false statement. But the opposite of a profound truth may well be another profound truth. -- Nils Bohr From sehnsucht.nach.unendlichkeit at quantentunnel.de Fri Feb 1 07:21:57 2008 From: sehnsucht.nach.unendlichkeit at quantentunnel.de (Tom Rauchenwald) Date: Fri Feb 1 07:29:22 2008 Subject: [xmonad] Re: some cleanup References: <20080131103538.GL4849@laptop.nowhere.net> <20080201085132.GA5320@presario> <87k5lprq8g.fsf@sec.modprobe.de> <20080201120401.GX4849@laptop.nowhere.net> Message-ID: <877ihosw7u.fsf@sec.modprobe.de> Andrea Rossato writes: > On Fri, Feb 01, 2008 at 10:16:31AM +0100, Tom Rauchenwald wrote: >> What about when running a composite manager? I run xcompmgr (at least >> occasionally) and noticed that now the inactive tabs can be seen in a >> translucent term, previously only the desktop background would shine >> through. > > Sorry if I ask, but I don't use this stuff (I don't have to hardware > for): do you think that the effects you are noticing are an > improvement, or a bug? Well it depends.. If you have the mental picture that an inactive tab is "behind" the active one, it is an improvement. At least it seems more logical to me. I don't really care much about this to be honest, it was just something i noticed. > Thanks, > Andrea Tom -- Then I drew in a breath, and my renewed will with it, lifted the rod in my right hand, murmured a phrase in a language I didn't know, and blew the tires off his fucking truck. -- Harry Dresden From mailing_list at istitutocolli.org Fri Feb 1 07:33:55 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 07:33:32 2008 Subject: [xmonad] Re: some cleanup In-Reply-To: <87zlukvpep.wl%tim@we-are-teh-b.org> References: <20080131103538.GL4849@laptop.nowhere.net> <20080201085132.GA5320@presario> <87k5lprq8g.fsf@sec.modprobe.de> <20080201120401.GX4849@laptop.nowhere.net> <87zlukvpep.wl%tim@we-are-teh-b.org> Message-ID: <20080201123355.GY4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 12:20:46PM +0000, Tim Schumacher wrote: > At Fri, 1 Feb 2008 13:04:01 +0100, > Andrea Rossato wrote: > > Sorry if I ask, but I don't use this stuff (I don't have to hardware > > for): do you think that the effects you are noticing are an > > improvement, or a bug? > > IMHO this would be a bug. Since the other windows are on their tabs > and not in the background. just a terminology clarification: a tab, for you, is just the representation of a window ("windows are on their tabs"), and so you think they should not be visible through the transparent, focused, window, right? if that is right, I think that the last patch I've sent here: http://code.google.com/p/xmonad/issues/detail?id=125 should fix your problem. I'm writing that, because, in my vision, a tabbed layout is just a stack of full screen windows *plus* their tabs. I would expect that, if I resize the window at the top, I should be able to see the second window, and if I resize this second, I can see the third. This way I can user the WindowArranger with tabbed too. The patch that I sent, though, should make the both of us happy, since we can have both a tabbed layout with just the focused window, and a tabbed layout as I conceive it. As you may understand what I did was just implementing *my* idea of a tabbed layout. Cheers, Andrea From byorgey at gmail.com Fri Feb 1 07:39:20 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri Feb 1 07:38:36 2008 Subject: [xmonad] The future of PerWorkspace In-Reply-To: <20080131180755.GO4849@laptop.nowhere.net> References: <22fcbd520801301629t4ed0497fyec06fad5075e590e@mail.gmail.com> <20080131130208.GM4849@laptop.nowhere.net> <22fcbd520801310929k375f33b1r2f4534f4389c7a9a@mail.gmail.com> <20080131180755.GO4849@laptop.nowhere.net> Message-ID: <22fcbd520802010439s10dfd282k4c9a9f96e3ac1dd3@mail.gmail.com> On Thu, Jan 31, 2008 at 1:07 PM, Andrea Rossato < mailing_list@istitutocolli.org> wrote: > On Thu, Jan 31, 2008 at 12:29:55PM -0500, Brent Yorgey wrote: > > But it's not just about messages; we'd also need doLayoutInWorkspace and > > emptyLayoutInWorkspace. In particular xinerama support would not work > > without those. Since PerWorkspace is the only layout that could > possibly > > use this information, adding three new methods to the LayoutClass just > for > > this is almost certainly not the way to go. > > Ok, so, if I get it right, you are proposing to go back to existential > and everything just because you think it is wrong to extend a class, > which, I was told, is just something you can extend without breaking > what is built upon it. > I do not think it is wrong to extend a class *in general*. What I do think is not very elegant is to add *three new methods* to the LayoutClass (also requiring changes to the xmonad core so that it calls these new methods instead of the old ones), just to support a *single* layout. And no, these methods would not make the LayoutClass more general; this is the only layout I can conceivably think of that would need to know the tag of the workspace in which it is being called. Note I am also not proposing to go back to existential wrappers everywhere, I'm pretty sure I put a sad face next to that in my e-mail. =) > > All this because you suppose PerWorspace is the only one that *may* be > using a non pure combinator. > It has nothing to do with purity/non-purity. I assume you are referring to the thing with the 'description' method not having a result in the X monad? This is an orthogonal issue; I don't have a strong feeling about it one way or another. It is true that the only layout I have seen that could possibly need this, again, is PerWorkspace. But in any case the *main* point is to get PerWorkspace working with xinerama, which has nothing to do with the type of 'description', but about the need for somehow getting this extra information about what workspace a layout resides in. Regards, -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/xmonad/attachments/20080201/a90d548a/attachment-0001.htm From codesite-noreply at google.com Fri Feb 1 07:44:04 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 07:43:19 2008 Subject: [xmonad] Issue 125 in xmonad: Tabbed layout not working anymore Message-ID: <000e0cd14664044518211f5c1f186835@google.com> Issue 125: Tabbed layout not working anymore http://code.google.com/p/xmonad/issues/detail?id=125 Comment #16 by andrea.rossato: > The only thing that remains, from a user point of view, is the > ability to click on the tabs (decorations) to switch to the window. this requires a change in the way we handle messages. Basically, a layout modifier is not allowed to call "focus w" (the function to place a window in focus), because that modifies the stack the layout modifier is operating with. As I wrote here: http://www.haskell.org/pipermail/xmonad/2008-January/004398.html I do not really grasp the hows and whys, but I'm sure it's true. I think this issue is the same of issue #111. (but I remember there should be a similar issue, but I cannot find it presently). > One question: shouldn't 'windowRemove' be used inside 'tabbed' in > 'XMonad.Layout.Tabbed'. So that users don't have to remember to apply it to 'tabbed'? yes, you are right. But I didn't because of that linker issue. I thought that first we must test the patch, and possibly understand if it breaks ghc-6.6.1 compatibility, that would be quite an issue. Cheers, Andrea I'm accepting this bug. See: http://www.haskell.org/pipermail/xmonad/2008-February/004533.html Issue attribute updates: Status: Accepted Owner: andrea.rossato -- 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 From byorgey at gmail.com Fri Feb 1 07:46:31 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri Feb 1 07:45:47 2008 Subject: [xmonad] The future of PerWorkspace In-Reply-To: <20080131194232.GB6492@presario> References: <22fcbd520801301629t4ed0497fyec06fad5075e590e@mail.gmail.com> <20080131194232.GB6492@presario> Message-ID: <22fcbd520802010446vb97037fs31c202ba9a6fbaab@mail.gmail.com> On Thu, Jan 31, 2008 at 2:42 PM, Spencer Janssen wrote: > On Wed, Jan 30, 2008 at 07:29:58PM -0500, Brent Yorgey wrote: > > 1. PerWorkspace is an inelegant hack with several icky problems: > > Agreed. It is approaching the limits of xmonad's layout design. However, > I > think we can accomplish PerWorkspace behavior without changing too much. > > \begin{code} > data PerWS = PerWS { selected :: Maybe Layout > , choices :: Map WorkspaceId Layout > , default :: Layout } > \end{code} > > 'selected' is Nothing until we either figure out which workspace the > layout is > on, or we're forced to render before we figure it out. 'choices' maps > workspaceids to desired layouts. 'default' is used when the WorkspaceId > isn't > in our 'choices' map, or we're forced to render before we know which > workspace we're on. > This is similar to what I had before, except I very much like the idea of storing a "Maybe Layout" instead of just a "Maybe Bool". Much less of a headache. =) > Now, the million dollar question: how do we figure out which workspace a > layout > is on? > > \begin{code} > data YouAreHere = YAH WorkspaceId deriving Typeable > instance Message YouAreHere > \end{code} > Ah, excellent! I hadn't thought of the idea of a special message. > > Now we just need to arrange for this message to be sent. I see two > options: > > - add a 'startupHook :: X ()' that is executed when xmonad starts. This > might > be useful for other applications too. A minor issue is that the user > will > have to edit startupHook and layoutHook to use PerWorkspace > successfully. > This option makes more sense to me. In fact, the other day someone was asking about the possibility of just such a hook; I played around with it for a bit but wasn't sure of the best place to add a call to it in the core. Would it really be possible to implement a function to correctly send all the YouAreHere messages, with no other support from the core than just calling the startupHook? I'll have to look into it. If so this seems the way to go. > > - have the core send YouAreHere messages to each visible workspace during > each > refresh. This is easier for the user, but it requires adding more to > the > core. > This sounds sort of ugly to me. Again, it's the principle of making a bunch of very specific changes to the core which have not much purpose other than to support a single extension. -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/xmonad/attachments/20080201/32283634/attachment.htm From codesite-noreply at google.com Fri Feb 1 07:48:04 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 07:47:18 2008 Subject: [xmonad] Issue 131 in xmonad: We need a mouse interface to the decoration layer Message-ID: <000e0cd22ee60445182f79613f18713d@google.com> Issue 131: We need a mouse interface to the decoration layer http://code.google.com/p/xmonad/issues/detail?id=131 New issue report by andrea.rossato: At the present time the decoration layer doesn't implement any mouse interface. This is partially due to the fact that modifiers are not allowed to call "focus window"): see the discussion in issue #111 But there is another problem: the interaction with the underlying WindowArranger. Since the window arranger, which takes track of modified geometries, is implemented purely, a possibility could be a message interface system between the decoration modifier and the arranger modifier. I need to collect some ideas on you to deal cleanly with this problem. My starting idea, anyway, is to implement that interface in the DecorationStyle class, with safe default methods, but the possibility of users/developers to provide their own implementation. Issue attributes: Status: Accepted Owner: andrea.rossato Labels: Type-Defect Priority-Medium -- 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 From byorgey at gmail.com Fri Feb 1 07:59:54 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri Feb 1 07:59:08 2008 Subject: [xmonad] The future of PerWorkspace In-Reply-To: <20080201064857.GS4849@laptop.nowhere.net> References: <22fcbd520801301629t4ed0497fyec06fad5075e590e@mail.gmail.com> <20080131194232.GB6492@presario> <20080131202130.GQ4849@laptop.nowhere.net> <20080201062231.GB5288@presario> <20080201064857.GS4849@laptop.nowhere.net> Message-ID: <22fcbd520802010459me93e8cdlce9cb8a578da860d@mail.gmail.com> On Fri, Feb 1, 2008 at 1:48 AM, Andrea Rossato < mailing_list@istitutocolli.org> wrote: > On Fri, Feb 01, 2008 at 12:22:32AM -0600, Spencer Janssen wrote: > > As far as I know, there has only been one other proposal that solves the > > Xinerama issues with PerWorkspace -- adding a WorkspaceId argument to > doLayout. > > I think we've all agreed that isn't so nice. My message proposal is > actually > > very similar -- except that only layouts that care about workspace > location > > need to handle these messages, whereas an extra argument to doLayout > must be > > mentioned in every single layout instance. > > > > Have you proposed another implementation that solves the Xinerama issue, > and I > > missed it? > > Yes you did. You actually did miss quite a lot of the stuff I've been > sending recently. You are not the only one, though. > Hey, there's no need for that. You have been sending rather a lot of stuff lately, you know, you can't blame people for not quite being able to keep up. =) > > As I say I did not propose to change doLayout, but just to change, in > runLayout, doLayout with a doLayoutInWorkspace which takes the > workspace and calls "doLayout (layout w)". The same for > (emptyLayoutInWorkspace w = emptyLayout (layout w) and handleMessage. > > Did you read this message and the attached patch? > http://www.haskell.org/pipermail/xmonad/2008-January/004493.html > > If a layout may be knowing the workspace it is running on, we could > implement a general purpose combinator (my LayoutCombinator class and > a general purpose CombinedLayout, implemented on top of the layout > class. > Andrea, I would like to point out that having methods like doLayoutInWorkspace and so on have nothing to do with the viability of your LayoutCombinator class. These methods have only to do with implementing PerWorkspace in particular. In fact, I rather liked your LayoutCombinator class and would like a chance to try implementing PerWorkspace using it together with sjanssen's approach of special messages sent by a startup hook. I would like to ask if you can just re-push your LayoutCombinator class and CombinedLayout combinator, without making any changes to PerWorkspace? That way it will not break anything and we can play around with implementing things in terms of it. > > As I mention here: > http://code.google.com/p/xmonad/issues/detail?id=129 > (I answered to your challenge, but you did not to mine!), with my > proposal, PerWorkspace implementation would be: > > instance LayoutCombinator PerWorkspace a where > chooser (PerWorkspace wsIds) = do > t <- getCurrentTag > return $ if t `elem` wsIds then DoFirst else DoSecond > Again, you seem to be confusing the issue of the type of 'description' with the problem of getting PerWorkspace to work with xinerama. The above code still would not work with xinerama, which is my main goal. It also still does not work with messages that may be sent to a non-focused workspace. That implementation IS ACTUALLY working and has been in xmc repository > for a couple of days. Than I had to remove it since I asked for core > support and I was told I would not get it. > No, it wasn't; there is still the issue of messages sent to non-focused workspaces, which probably wouldn't cause any problems most of the time (so it appeared to work) but could cause subtle bugs. I sent an explanation of this to the list earlier. Cheers, -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/xmonad/attachments/20080201/3187de54/attachment.htm From mailing_list at istitutocolli.org Fri Feb 1 08:24:29 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 08:24:19 2008 Subject: [xmonad] The future of PerWorkspace In-Reply-To: <22fcbd520802010459me93e8cdlce9cb8a578da860d@mail.gmail.com> References: <22fcbd520801301629t4ed0497fyec06fad5075e590e@mail.gmail.com> <20080131194232.GB6492@presario> <20080131202130.GQ4849@laptop.nowhere.net> <20080201062231.GB5288@presario> <20080201064857.GS4849@laptop.nowhere.net> <22fcbd520802010459me93e8cdlce9cb8a578da860d@mail.gmail.com> Message-ID: <20080201132429.GZ4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 07:59:54AM -0500, Brent Yorgey wrote: > On Fri, Feb 1, 2008 at 1:48 AM, Andrea Rossato < > mailing_list@istitutocolli.org> wrote: > > Yes you did. You actually did miss quite a lot of the stuff I've been > > sending recently. You are not the only one, though. > > > > Hey, there's no need for that. You have been sending rather a lot of stuff > lately, you know, you can't blame people for not quite being able to keep > up. =) I did not intend to blame anyone for that, and if I gave that impression I really beg your pardon. I'm really tired and maybe I'm loosing the ability to calibrate my words, but I just wanted to say that, yes, I had sent a proposal for a xinerama safe implementation of PerWorkspace (not the details but the general ideas... the code is straight). > Andrea, I would like to point out that having methods like > doLayoutInWorkspace and so on have nothing to do with the viability of your > LayoutCombinator class. These methods have only to do with implementing > PerWorkspace in particular. In fact, I rather liked your LayoutCombinator > class and would like a chance to try implementing PerWorkspace using it > together with sjanssen's approach of special messages sent by a startup > hook. I would like to ask if you can just re-push your LayoutCombinator > class and CombinedLayout combinator, without making any changes to > PerWorkspace? That way it will not break anything and we can play around > with implementing things in terms of it. I didn't revert as a retaliation measure...;) It's a couple of days that I keep repeating that a LayoutCombinator class is broken due to the type signature of description, and I do not think is right to push in a public repository of an important collaborative project like ours code that I know is broken. Since I see this problem very clearly, I thought it should be evident to others too. It is not. So I decided to revert, and discuss we you, guys, about the issue: http://code.google.com/p/xmonad/issues/detail?id=129 When we reach an agreement on how to write that class correctly, we will push back. I was a bit harsh, I must confess that, because when I said that type signature was wrong I got answers as if I were a newbie who doesn't get the beauty of pureness. I was just talking about the beauty of pureness at a higher level of abstraction, in xmonad class system...;) > Again, you seem to be confusing the issue of the type of 'description' with > the problem of getting PerWorkspace to work with xinerama. The above code > still would not work with xinerama, which is my main goal. It also still > does not work with messages that may be sent to a non-focused workspace. No I do not. 1. xinerama issue -> doLayoutInWorkspace, emptyLayoutInWorkspace, handleMessageInWorkspace 2. LayoutCombinator class -> description type If I solve 2 and I get 1 the PerWorkspace implementation is 3 lines long. If I get 1 but I don't get 2 the implementation of PerWorkspace is longer but can be done. But in this case the LayoutCombinator class is bugged: either you confine it to pure combinators only (Choose, NewSelect and ToggleLayouts could be implemented, if I remember right), but PerWorkspace cannot be implememented. > No, it wasn't; there is still the issue of messages sent to non-focused > workspaces, which probably wouldn't cause any problems most of the time (so > it appeared to work) but could cause subtle bugs. I sent an explanation of > this to the list earlier. I hope what I said above clarifies my point. but you are right, in some of my messages I did some confusion on the two points (but believe me, the problem is quite clear to me). Hope this helps. Andrea From baschni at gmail.com Fri Feb 1 10:31:48 2008 From: baschni at gmail.com (Bastian Schnitzler) Date: Fri Feb 1 09:31:16 2008 Subject: [xmonad] xmonad 0.6 wrong version info Message-ID: <20080201153148.GA7631@localhost> Hi all! I just installed xmonad 0.6 and ran xmonad --version, which echoed 'xmonad 0.5'. I think this is wrong :D. surgeon@localhost ~/Desktop/xmonad-0.6 $ runhaskell Setup.lhs install --user Installing: /home/surgeon/lib/xmonad-0.6/ghc-6.8.2 Installing: /home/surgeon/bin Registering xmonad-0.6... Reading package info from "dist/installed-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. surgeon@localhost ~/Desktop/xmonad-0.6 $ ~/bin/xmonad --version xmonad 0.5 Yours, Bastian From mailing_list at istitutocolli.org Fri Feb 1 10:04:46 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 10:04:35 2008 Subject: [xmonad] The future of PerWorkspace In-Reply-To: <22fcbd520802010459me93e8cdlce9cb8a578da860d@mail.gmail.com> References: <22fcbd520801301629t4ed0497fyec06fad5075e590e@mail.gmail.com> <20080131194232.GB6492@presario> <20080131202130.GQ4849@laptop.nowhere.net> <20080201062231.GB5288@presario> <20080201064857.GS4849@laptop.nowhere.net> <22fcbd520802010459me93e8cdlce9cb8a578da860d@mail.gmail.com> Message-ID: <20080201150446.GA4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 07:59:54AM -0500, Brent Yorgey wrote: > On Fri, Feb 1, 2008 at 1:48 AM, Andrea Rossato < > mailing_list@istitutocolli.org> wrote: > That implementation IS ACTUALLY working and has been in xmc repository > No, it wasn't; there is still the issue of messages sent to non-focused > workspaces, which probably wouldn't cause any problems most of the time (so > it appeared to work) but could cause subtle bugs. I sent an explanation of > this to the list earlier. I think you may understand that by "working" I mean conceptually sounded and actually implementable. That specific implementation was not working in the way it should because, I've been arguing, it exposed the lack of composability and the lack of expressiveness of the LayoutClass, due to the methods' types that were chosen. I would like to stress the relationship between a method's type and the expressiveness of a class. As I pointed out in my "adventures in types", David provided us with a great tool when he hacked the modifier class. Still that class was not expressive enough to implement AvoidStruts (from ManageDocks), because modifyLayout was not provided. And so, at that time, you should implement AvoidStruct as a layout combinator. I believe my implementation is cleaner, because now you can *change* the layout class and all you need to do it's just to port the modifier class. The very same applies the Named. And did you see how many locs there are in Named now? Why do I care about PerWorkspace so much that I'm buzzing everyone about it? Because when I saw it I thought - and still think - that it was a great hack, that showed my how much you can do with the type system. Do you remember when David told you to just push the list in the type? I'm just applying that principle on a regular basis, now. Thanks to you and David... shouldn't we agree? ;) Cheers, Andrea From allbery at ece.cmu.edu Fri Feb 1 10:15:02 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Feb 1 10:14:17 2008 Subject: [xmonad] xmonad 0.6 wrong version info In-Reply-To: <20080201153148.GA7631@localhost> References: <20080201153148.GA7631@localhost> Message-ID: <656B3ED8-BB6C-4DDD-A995-309EF2D01CA7@ece.cmu.edu> On Feb 1, 2008, at 10:31 , Bastian Schnitzler wrote: > I just installed xmonad 0.6 and ran xmonad --version, which echoed > 'xmonad 0.5'. I think this is wrong :D. Yep, known problem, the release process has been changed so that it won't happen in the future but changing the released version is considered a Bad Thing (distribution packagers hate it when people do that) so the problem remains in the 0.5 release. -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From codesite-noreply at google.com Fri Feb 1 13:14:38 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 13:13:54 2008 Subject: [xmonad] Issue 129 in xmonad: ClassLayout.description type signature is wrong Message-ID: <001636e0a7b804451cbf59cda8173089@google.com> Issue 129: ClassLayout.description type signature is wrong http://code.google.com/p/xmonad/issues/detail?id=129 Comment #3 by andrea.rossato: while waiting for Spencer's proof, in either directions (time is on my side... ;), I'm attaching the class and the instance as I'm designing them. the file does not even compile (see comments). Just to have something we can discuss. Attachments: combinatorClass.hs 4.5 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 From byorgey at gmail.com Fri Feb 1 14:30:58 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri Feb 1 14:30:11 2008 Subject: [xmonad] darcs patch: some core documentation updates Message-ID: <22fcbd520802011130p24e2b9abvc6e497b5f342ea1d@mail.gmail.com> Fri Feb 1 14:06:53 EST 2008 Brent Yorgey * Core.hs, StackSet.hs: some documentation updates -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/xmonad/attachments/20080201/50d26084/attachment.htm From byorgey at gmail.com Fri Feb 1 14:37:05 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri Feb 1 14:36:20 2008 Subject: [xmonad] RIP RotView, new wiki page for notable darcs changes Message-ID: <22fcbd520802011137g775faeft5b1728123a89b808@mail.gmail.com> Hi all, I have two things to say, so instead of sending two emails I just did a merge. =) 1. RotView is dead, long live RotView! The functionality of RotView has now been subsumed into a new and improved CycleWS. In particular if you used to use 'rotView True' you can now say 'moveTo Next NonEmptyWS'. Of course, you can also say 'moveTo Prev EmptyWS', and other such things; see the new CycleWS docs for more info. Note that this removes the old RotView restriction regarding having your workspace tags in lexicographical order; you can specify an arbitrary sort order for your workspace tags when cycling, and in particular the default is to cycle in config order rather than lexicographical order. 2. To help out those creating release notes when 0.7 rolls around, I've created a new page on the wiki: http://haskell.org/haskellwiki/Xmonad/Notable_changes_since_0.6 If you push any patches to the core or contrib repos that are "notable" (i.e. an average user upgrading from 0.6 to 0.7 would like to know about them), consider adding a short note to this page. Happy xmonading! -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/xmonad/attachments/20080201/0b20236a/attachment.htm From baschni at gmail.com Fri Feb 1 15:37:56 2008 From: baschni at gmail.com (Bastian Schnitzler) Date: Fri Feb 1 14:37:22 2008 Subject: [xmonad] Moving windows to a workspace based on their title / console applications in terminal emulators In-Reply-To: <20080201085857.GA6789@presario> References: <1201766787.47a181833713c@imp.free.fr> <20080131155001.GA27619@localhost> <1201854548.47a2d854c691e@imp.free.fr> <20080201085857.GA6789@presario> Message-ID: <20080201203756.GA8773@localhost> Hi! > You're observing the difference between class name and resource name. > Apparently 'xterm -class' sets the class name (called className in ManageHook), > but 'urxvt -name' sets resource name (called resource in ManageHook). This doesn't help, for me neither xterm -class icq or urxvt -name icq works with my config, here an excerpt: [ className =? "xterm" --> doF (W.shift "2") ], [ className =? "XTerm" --> doF (W.shift "2") ], [ className =? "icq" --> doF (W.shift "2") ], [ resource =? "icq" --> doF (W.shift "2") ], [ className =? "muttterm" --> doF (W.shift "2") ], [ className =? "Googleearth-bin" --> doF (W.shift "5") ], [ className =? "maple" --> doF (W.shift "5") ], [className =? "xmaple" --> doF (W.shift "5") ], [ className =? "Gimp" --> doF (W.shift "5") ], [ className =? "gimp" --> doF (W.shift "5") ], [ className =? "amarokapp" --> doF (W.shift "6") ], [ className =? "mplayer" --> doF (W.shift "7") ], [ className =? "Kpdf" --> doF (W.shift "8") ], [ className =? "Firefox-bin" --> doF (W.shift "9") ] ] where myFloats = ["Gimp", "gimp-2.2"] Funny that neither xterm, nor urxvt nor urxvt -name icq nor xterm -class icq is moved to Workspace 2? The same thing goes for me with Gimp, maple, mplayer, and google earth; the only things that actually are moved, are Kpdf, Firefox-bin and amarokapp, what am I doing wrong? Bastian From dominik at dbruhn.de Fri Feb 1 14:43:13 2008 From: dominik at dbruhn.de (Dominik Bruhn) Date: Fri Feb 1 14:42:26 2008 Subject: [xmonad] Moving windows to a workspace based on their title / console applications in terminal emulators In-Reply-To: <20080201203756.GA8773@localhost> References: <1201766787.47a181833713c@imp.free.fr> <20080131155001.GA27619@localhost> <1201854548.47a2d854c691e@imp.free.fr> <20080201085857.GA6789@presario> <20080201203756.GA8773@localhost> Message-ID: <20080201194313.GA13711@dbruhn.de> Hy, try to check the className using "xprop". Dominik On Fri, Feb 01, 2008 at 09:37:56PM +0100, Bastian Schnitzler wrote: > Hi! > > > You're observing the difference between class name and resource name. > > Apparently 'xterm -class' sets the class name (called className in ManageHook), > > but 'urxvt -name' sets resource name (called resource in ManageHook). > > This doesn't help, for me neither xterm -class icq or urxvt -name icq > works with my config, here an excerpt: > > [ className =? "xterm" --> doF (W.shift "2") ], > > [ className =? "XTerm" --> doF (W.shift "2") ], > > [ className =? "icq" --> doF (W.shift "2") ], > > [ resource =? "icq" --> doF (W.shift "2") ], > > [ className =? "muttterm" --> doF (W.shift "2") ], > > [ className =? "Googleearth-bin" --> doF (W.shift "5") ], > > [ className =? "maple" --> doF (W.shift "5") ], [className =? "xmaple" --> doF (W.shift "5") ], > > [ className =? "Gimp" --> doF (W.shift "5") ], [ className =? "gimp" --> doF (W.shift "5") ], > > [ className =? "amarokapp" --> doF (W.shift "6") ], > > [ className =? "mplayer" --> doF (W.shift "7") ], > > [ className =? "Kpdf" --> doF (W.shift "8") ], > > [ className =? "Firefox-bin" --> doF (W.shift "9") ] ] > > where myFloats = ["Gimp", "gimp-2.2"] > > Funny that neither xterm, nor urxvt nor urxvt -name icq nor xterm -class icq is moved to Workspace 2? > The same thing goes for me with Gimp, maple, mplayer, and google earth; the only things that actually are moved, are Kpdf, Firefox-bin and amarokapp, what am I doing wrong? > > Bastian > > _______________________________________________ > xmonad mailing list > xmonad@haskell.org > http://www.haskell.org/mailman/listinfo/xmonad > -- Dominik Bruhn mailto: dominik@dbruhn.de -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/xmonad/attachments/20080201/b63eb702/attachment.bin From codesite-noreply at google.com Fri Feb 1 14:53:47 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 14:53:00 2008 Subject: [xmonad] Issue 125 in xmonad: Tabbed layout not working anymore Message-ID: <000e0cd20da004451e21edff265fa79@google.com> Issue 125: Tabbed layout not working anymore http://code.google.com/p/xmonad/issues/detail?id=125 Comment #17 by andrea.rossato: I came to the conclusion that WindowRemover should be mover to XMonad.Layout.Tabbed, and not exported. It should just be used for that kind of special type of layou tabbed it. This way we have an implementation of both that specific idea of a tabbed layout where tabs represent not visible windows, and the one where a tabbed layout is a stack of windows with visible lables. The user will chose one, and will know that, while the second is composable, the first may be not (which means it also can: for instance, I believe that verticalReflect should work with both) cheers ps did you ever try applying Reflect to tabbed? reflectHorizontal is just messy, but vertical will place tabs at the bottom. If you use the WindowArranger, keep in mind that vertical actions must be reversed. -- 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 From baschni at gmail.com Fri Feb 1 16:03:29 2008 From: baschni at gmail.com (Bastian Schnitzler) Date: Fri Feb 1 15:02:53 2008 Subject: [xmonad] Moving windows to a workspace based on their title / console applications in terminal emulators In-Reply-To: <20080201194313.GA13711@dbruhn.de> References: <1201766787.47a181833713c@imp.free.fr> <20080131155001.GA27619@localhost> <1201854548.47a2d854c691e@imp.free.fr> <20080201085857.GA6789@presario> <20080201203756.GA8773@localhost> <20080201194313.GA13711@dbruhn.de> Message-ID: <20080201210329.GA9078@localhost> On 20:43 Fri 01 Feb , Dominik Bruhn wrote: > Hy, > try to check the className using "xprop". > WM_CLASS(STRING) = "icq", "XTerm" WM_COMMAND(STRING) = { "xterm", "-name", "icq" } WM_CLASS(STRING) = "xterm", "XTerm" WM_COMMAND(STRING) = { "xterm" } WM_CLASS(STRING) = "icq", "URxvt" WM_COMMAND(STRING) = { "urxvt", "-name", "icq" } WM_CLASS(STRING) = "urxvt", "URxvt" WM_COMMAND(STRING) = { "urxvt" } Still doesn't work here Yours, Bastian From codesite-noreply at google.com Fri Feb 1 15:07:48 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 15:07:02 2008 Subject: [xmonad] Issue 132 in xmonad: We should have a convention for layout names Message-ID: <000e0cd32cca04451e54172b67135e5c@google.com> Issue 132: We should have a convention for layout names http://code.google.com/p/xmonad/issues/detail?id=132 New issue report by andrea.rossato: I would suggest to set some conventional rules on out to export layouts to our users. I think we should export a simple one, without any configuration option, and one, with a "'", for a more complex one where some configuration parameters are available, and so on of higher levels of configurability. For instance: tabbed tabbed' shrinker theme tabbedResizable tabbedResizable' shrinker theme and so on. I'm just opening this issue as a way to gather ideas and then choose what seems the best. Issue attributes: Status: New Owner: ---- Labels: Type-Enhancement Priority-Medium -- 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 From codesite-noreply at google.com Fri Feb 1 15:34:55 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 15:34:08 2008 Subject: [xmonad] Issue 131 in xmonad: We need a mouse interface to the decoration layer Message-ID: <000e0cd1393204451eb505751d1bd4a6@google.com> Issue 131: We need a mouse interface to the decoration layer http://code.google.com/p/xmonad/issues/detail?id=131 Comment #1 by andrea.rossato: I'm starting to think, and I would like some feed back on that, that the separation between arranger/decoration is a bad design choice, since a messaging system is probably impossible. I must confess I had/have the (probably unjustified) hope that by solving #111 we would have a safe messaging system where a modifier can send a message to another modifier (or the underlying layout) and have this one return Just (with a Operations.windows call), without entering a recursive non terminating loop: like a safe "focus w" call. A second dream was this: have the first modifier send a message, have the second respond with a send message to the first while returning Nothing. - Decoration to arranger: send me the arranger state. - Arranger to decoration: here's my state >> return Nothing and then decoration set rectangles and attributes. But I think this is not working too. The idea of the separation came from the thrill of an arranger implemented with pure code and the arrow interface ;). But if the arranger cannot modify itself without returning just, mine are just dreams, and the design is broken. The fact that the design is broken can be proved this way: if you put the arranger over the decoration and you start moving, you'll see that the decoration is one step behind. Joining them would probably make the code ugly: Decoration *cannot* be pure. I hope someone can come up with a better strategy and give me some direction. -- 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 From codesite-noreply at google.com Fri Feb 1 16:00:05 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 15:59:19 2008 Subject: [xmonad] Issue 133 in xmonad: xmonad-contrib source code "cleanup" - in search of a user code location Message-ID: <000e0cd1466404451f0f0f83ae1beb7b@google.com> Issue 133: xmonad-contrib source code "cleanup" - in search of a user code location http://code.google.com/p/xmonad/issues/detail?id=133 New issue report by andrea.rossato: I think we should find a better way to separate modules for user interfaces, and modules for developers APIs. For instance, in the IRC channel there were complains about the fact the XMonad.Layout.Decoration did not have user documentation and a user could not figure how to turn decorations on. The fact is that Decoration is just an API, and you can find user code in Tabbed. SimpleDecoration and DwmStyle are combinators, and I do not really judge the user code, but APIs. Since it seems we can get to a quite expressive level of layers composition, I suggest to elaborate a strategy for placing user code in a single place. On a longer period of time, I hope that the class system and the related instances (even Decoration - with (this is necessary :( the needed XUtils and Font libraries) will be proven safe enough to be included in the core, that would just export an abstract layer that can provide the full functionality of a highly programmable WM *without* any sensitive Xlib call. This hope guided my last hacking efforts. Issue attributes: Status: Accepted Owner: andrea.rossato Labels: Type-Defect Priority-Medium -- 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 From sjanssen at cse.unl.edu Fri Feb 1 16:00:47 2008 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Fri Feb 1 16:00:49 2008 Subject: [xmonad] darcs patch: Add windowRemover for make tabbed return just the focu... In-Reply-To: <200802011102.m11B24oj006771@laptop.nowhere.net> References: <200802011102.m11B24oj006771@laptop.nowhere.net> Message-ID: <20080201210046.GA5366@presario> On Fri, Feb 01, 2008 at 12:02:04PM +0100, Andrea Rossato wrote: > Hi, > > this is a follow up of the discussion with Spencer about tabbed. > > This patch implements WindowRemover. If placed over tabbed it should > be removing unfocused windows, without touching the windows > decoration. > > WARNING: while this patch passes all tests both with ghc-6.6.1 and > ghc-6.8.2, when I build this test file: > import XMonad > import XMonad.Config.Arossato > main = xmonad =<< arossatoConfig > > ghc-6.6.1 fails with this linker error: > [12:00:33][wolf@laptop:~/.xmonad]$ ghc --make xmonad.hs > Linking xmonad ... > /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o): In function `s1e0s_info': > ghc3557_0.hc:(.text+0x3ada): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_info' > /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o):(.rodata+0xa8): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_closure' > collect2: ld returned 1 exit status > > The same code compiles, and works perfectly (unless bugs introduced by > its author, me) on ghc-6.8.2. > > This is why I'd like someone to test it (I'll include it also in the > bug tracker). > > Cheers, > Andrea > > Fri Feb 1 11:55:05 CET 2008 Andrea Rossato > * Add windowRemover for make tabbed return just the focused window I think this solution is *really* ugly. Also, I don't think we can necessarily rely on the property that decorations windows are the only override-redirect windows in the windowset. Cheers, Spencer Janssen From codesite-noreply at google.com Fri Feb 1 16:04:07 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 16:03:20 2008 Subject: [xmonad] Issue 133 in xmonad: xmonad-contrib source code "cleanup" - in search of a user code location Message-ID: <000e0cd151de04451f1d79dc441c007a@google.com> Issue 133: xmonad-contrib source code "cleanup" - in search of a user code location http://code.google.com/p/xmonad/issues/detail?id=133 Comment #1 by andrea.rossato: this stupid defaults..;) I did not accept this patch. Also because it needs review. changed to new. Issue attribute updates: Status: New Owner: --- -- 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 From mailing_list at istitutocolli.org Fri Feb 1 16:21:19 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 16:21:11 2008 Subject: [xmonad] darcs patch: Add windowRemover for make tabbed return just the focu... In-Reply-To: <20080201210046.GA5366@presario> References: <200802011102.m11B24oj006771@laptop.nowhere.net> <20080201210046.GA5366@presario> Message-ID: <20080201212119.GB4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 03:00:47PM -0600, Spencer Janssen wrote: > I think this solution is *really* ugly. Also, I don't think we can necessarily > rely on the property that decorations windows are the only override-redirect > windows in the windowset. Sorry Spencer, but I deduce, from your words, that all my job has been base on completely false assumptions, and probably we must have some serious code review. I'm not kidding, and I'm not ironic. I do really take into consideration of just being plainly wrong on everything. You know I have high respect for your knowledge. 1) handle (MapRequestEvent {ev_window = w}) = withDisplay $ \dpy -> do wa <- io $ getWindowAttributes dpy w -- ignore override windows -- need to ignore mapping requests by managed windows not on the current workspace managed <- isClient w when (not (wa_override_redirect wa) && not managed) $ do manage w 2) a window with override_redirect *must* always pass true. 3) no modifier is allowed to change the stack set! they can *only* manipulate the (window,rectangle) list to be returned in Operations.windows. Modifier *DO NOT* manipulate the stack. Once "restackWindows d vs" has being called, track of layouts/modifiers' activity can be found only in the layout field of the workspace type. If any of these three assumptions is false, we should probably consider to revert immediately. I'm serious, and I understand that we must provide a certain level of code correctness. Cheers, Andrea From sjanssen at cse.unl.edu Fri Feb 1 16:29:58 2008 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Fri Feb 1 16:30:00 2008 Subject: [xmonad] Issue 125 in xmonad: Tabbed layout not working anymore In-Reply-To: <000e0cd14664044518211f5c1f186835@google.com> References: <000e0cd14664044518211f5c1f186835@google.com> Message-ID: <20080201212958.GA5188@presario> On Fri, Feb 01, 2008 at 04:44:04AM -0800, codesite-noreply@google.com wrote: > Issue 125: Tabbed layout not working anymore > http://code.google.com/p/xmonad/issues/detail?id=125 > > Comment #16 by andrea.rossato: >> The only thing that remains, from a user point of view, is the >> ability to click on the tabs (decorations) to switch to the window. > > this requires a change in the way we handle messages. Basically, a layout > modifier is > not allowed to call "focus w" (the function to place a window in focus), > because that > modifies the stack the layout modifier is operating with. As I wrote here: > http://www.haskell.org/pipermail/xmonad/2008-January/004398.html > I do not really grasp the hows and whys, but I'm sure it's true. Layouts can call 'focus w' in their message handlers -- in fact this is how the old tabbed layout worked. > I think this issue is the same of issue #111. (but I remember there should > be a > similar issue, but I cannot find it presently). Issue #111 only comes into play when a message handler changes the set of visible workspaces. The old tabbed hit this issue when the user clicks a tab on an inactive workspace. Cheers, Spencer Janssen From byorgey at gmail.com Fri Feb 1 16:53:20 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri Feb 1 16:52:35 2008 Subject: [xmonad] The future of PerWorkspace In-Reply-To: <20080131194232.GB6492@presario> References: <22fcbd520801301629t4ed0497fyec06fad5075e590e@mail.gmail.com> <20080131194232.GB6492@presario> Message-ID: <22fcbd520802011353h6bff1d8bje4d25f3754edbbc8@mail.gmail.com> On Thu, Jan 31, 2008 at 2:42 PM, Spencer Janssen wrote: > On Wed, Jan 30, 2008 at 07:29:58PM -0500, Brent Yorgey wrote: > > 1. PerWorkspace is an inelegant hack with several icky problems: > > Agreed. It is approaching the limits of xmonad's layout design. However, > I > think we can accomplish PerWorkspace behavior without changing too much. > > \begin{code} > data PerWS = PerWS { selected :: Maybe Layout > , choices :: Map WorkspaceId Layout > , default :: Layout } > \end{code} > So, I took a crack at implementing (something like) this today. The problem I ran into is that (Layout a) is not an instance of Read, so PerWorkspace cannot derive Read either. Is there any way around this? Or do I have to go back to caching a (Maybe Bool) and using that to decide on which of two layouts to use, instead of directly caching a (Maybe (Layout a))? Ideas? -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/xmonad/attachments/20080201/49863208/attachment-0001.htm From roma at ro-che.info Fri Feb 1 17:01:00 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri Feb 1 17:00:36 2008 Subject: [xmonad] mplayer & borders Message-ID: <20080201220100.GA6789@home.ro-che.info> It seems to be one of the most frequently asked questions on the IRC, so I've just added it to FAQ[1]. As I wrote there, I don't see any way to automate this task with manageHook. Keeping an extra bit for each window (whether to draw borders) looks like overkill for, I guess, single program which needs it. Does anyone have ideas how to automate NoBorders in a simple way? 1. http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#I_don.27t_like_borders_around_mplayer -- Roman I. Cheplyaka (aka Feuerbach @ IRC) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/xmonad/attachments/20080202/6298de9b/attachment.bin From nicolas.pouillard at gmail.com Fri Feb 1 17:04:14 2008 From: nicolas.pouillard at gmail.com (Nicolas Pouillard) Date: Fri Feb 1 17:04:37 2008 Subject: [xmonad] The future of PerWorkspace In-Reply-To: <22fcbd520802011353h6bff1d8bje4d25f3754edbbc8@mail.gmail.com> References: <22fcbd520801301629t4ed0497fyec06fad5075e590e@mail.gmail.com> <20080131194232.GB6492@presario> <22fcbd520802011353h6bff1d8bje4d25f3754edbbc8@mail.gmail.com> Message-ID: <1201903424-sup-964@ausone.local> Excerpts from Brent Yorgey's message of Fri Feb 01 22:53:20 +0100 2008: > On Thu, Jan 31, 2008 at 2:42 PM, Spencer Janssen > wrote: > > > On Wed, Jan 30, 2008 at 07:29:58PM -0500, Brent Yorgey wrote: > > > 1. PerWorkspace is an inelegant hack with several icky problems: > > > > Agreed. It is approaching the limits of xmonad's layout design. However, > > I > > think we can accomplish PerWorkspace behavior without changing too much. > > > > \begin{code} > > data PerWS = PerWS { selected :: Maybe Layout > > , choices :: Map WorkspaceId Layout > > , default :: Layout } > > \end{code} > > > > So, I took a crack at implementing (something like) this today. The problem > I ran into is that (Layout a) is not an instance of Read, so PerWorkspace > cannot derive Read either. Is there any way around this? Or do I have to > go back to caching a (Maybe Bool) and using that to decide on which of two > layouts to use, instead of directly caching a (Maybe (Layout a))? > > Ideas? What about "instance Read a => Read (Layout a)"? -- Nicolas Pouillard aka Ertai -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 186 bytes Desc: not available Url : http://www.haskell.org/pipermail/xmonad/attachments/20080201/98a7f734/signature.bin From byorgey at gmail.com Fri Feb 1 17:08:30 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri Feb 1 17:07:43 2008 Subject: [xmonad] The future of PerWorkspace In-Reply-To: <1201903424-sup-964@ausone.local> References: <22fcbd520801301629t4ed0497fyec06fad5075e590e@mail.gmail.com> <20080131194232.GB6492@presario> <22fcbd520802011353h6bff1d8bje4d25f3754edbbc8@mail.gmail.com> <1201903424-sup-964@ausone.local> Message-ID: <22fcbd520802011408q6ea5886akcd1ba327130d6c3@mail.gmail.com> On Fri, Feb 1, 2008 at 5:04 PM, Nicolas Pouillard < nicolas.pouillard@gmail.com> wrote: > Excerpts from Brent Yorgey's message of Fri Feb 01 22:53:20 +0100 2008: > > On Thu, Jan 31, 2008 at 2:42 PM, Spencer Janssen > > wrote: > > > > > On Wed, Jan 30, 2008 at 07:29:58PM -0500, Brent Yorgey wrote: > > > > 1. PerWorkspace is an inelegant hack with several icky problems: > > > > > > Agreed. It is approaching the limits of xmonad's layout design. > However, > > > I > > > think we can accomplish PerWorkspace behavior without changing too > much. > > > > > > \begin{code} > > > data PerWS = PerWS { selected :: Maybe Layout > > > , choices :: Map WorkspaceId Layout > > > , default :: Layout } > > > \end{code} > > > > > > > So, I took a crack at implementing (something like) this today. The > problem > > I ran into is that (Layout a) is not an instance of Read, so > PerWorkspace > > cannot derive Read either. Is there any way around this? Or do I have > to > > go back to caching a (Maybe Bool) and using that to decide on which of > two > > layouts to use, instead of directly caching a (Maybe (Layout a))? > > > > Ideas? > > What about "instance Read a => Read (Layout a)"? > Well, since Layout is an existential wrapper, that's not possible -- it hides the type of the wrapped layout. I know that lots of work has already gone into the xmonad core getting around this issue. =) Hmm, just thinking out loud here... note that I don't actually care about being able to read the (Layout a) value back in, since after serialization/restart the startupHook will get run again anyway, and the correct workspace will get re-cached. So perhaps I can just write my own explicit Read instance for PerWorkspace that somehow ignores that element and just initializes the read value to Nothing. Sounds scary. =) -Brent -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/xmonad/attachments/20080201/03b0a860/attachment.htm From byorgey at gmail.com Fri Feb 1 17:09:27 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri Feb 1 17:08:40 2008 Subject: [xmonad] The future of PerWorkspace In-Reply-To: <22fcbd520802011408q6ea5886akcd1ba327130d6c3@mail.gmail.com> References: <22fcbd520801301629t4ed0497fyec06fad5075e590e@mail.gmail.com> <20080131194232.GB6492@presario> <22fcbd520802011353h6bff1d8bje4d25f3754edbbc8@mail.gmail.com> <1201903424-sup-964@ausone.local> <22fcbd520802011408q6ea5886akcd1ba327130d6c3@mail.gmail.com> Message-ID: <22fcbd520802011409j138ff9afqcefe82a1c92d3d2b@mail.gmail.com> > serialization/restart the startupHook will get run again anyway, and the > correct workspace will get re-cached. So perhaps I can just write > arg, of course I meant 'the correct *layout will get re-cached'... -------------- next part -------------- An HTML attachment was scrubbed... URL: http://www.haskell.org/pipermail/xmonad/attachments/20080201/44eb026e/attachment.htm From mailing_list at istitutocolli.org Fri Feb 1 17:09:40 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 17:09:27 2008 Subject: [xmonad] please revert back Message-ID: <20080201220940.GC4849@laptop.nowhere.net> Hi, I'm feeling in a quite difficult situation. I have pushed a huge set of patches with the assumption they were being approved by the main developers and now, instead of a supportive environment I feel like my code is being rejected . it seems to work, but its just a big ugly hack. I'm really far from arguing that this is false. As I said I'm a legal scholar doing legal, economic and philosophical research. I do not really have the competence for having a contest with the main developer, Spencer. Moreover in the silence of some the other developers and a mixed approach but Brent, each one far more expert then me on the subject. Which leads me to think that it is me who's being wrong, and, since I have no (scientific) interest in avoiding admitting my faults - my reputation here is far from being at stake - I have no problem to acknowledged I did a mistake by abusing the trust that has been given to me, by granting me write access to the contributory repository. While I can assure you that I did all that with plenty of good faith, truly (even if only subjectively) thinking to improve xmonad, you may also understand that I'm now not in a position to joyfully maintain my code, if I have to argue. Because I'm not in the position of feeling I'm i the right position. I hope you understand that there is no harsh in my words, but just the acknowledgment that a computer scientist has more knowledge than me, and that for me it would just be wasted pretending that's not true. So please revert. We are at the very beginning and people are distracted by the release, so the change would go almost unnoticed. At a latter time, after deeper code analysis, you may consider to slowly introduce some of the changes I proposed, if you find them not too hackish. I really really hope you'll appreciate the constructive intent of this message, and the fact the its intention is supportive of this community. Cheers, Andrea From daveroundy at gmail.com Fri Feb 1 17:20:28 2008 From: daveroundy at gmail.com (David Roundy) Date: Fri Feb 1 17:19:41 2008 Subject: [xmonad] Issue 125 in xmonad: Tabbed layout not working anymore In-Reply-To: <20080201212958.GA5188@presario> References: <000e0cd14664044518211f5c1f186835@google.com> <20080201212958.GA5188@presario> Message-ID: <117f2cc80802011420m3286daa2ub61199310fbb0570@mail.gmail.com> On Feb 1, 2008 4:29 PM, Spencer Janssen wrote: > Layouts can call 'focus w' in their message handlers -- in fact this is how the > old tabbed layout worked. No, they can only call 'focus w' in response to messages sent by sentMessage, not to messages sent by broadcastMessage. Which is why even the old tabbed is currently broken. David From xj2106 at columbia.edu Fri Feb 1 17:25:13 2008 From: xj2106 at columbia.edu (Xiao-Yong Jin) Date: Fri Feb 1 17:25:49 2008 Subject: [xmonad] mplayer & borders In-Reply-To: <20080201220100.GA6789@home.ro-che.info> (Roman Cheplyaka's message of "Sat, 2 Feb 2008 00:01:00 +0200") References: <20080201220100.GA6789@home.ro-che.info> Message-ID: <87ir18e2ly.fsf@columbia.edu> Roman Cheplyaka writes: > It seems to be one of the most frequently asked questions on the IRC, so > I've just added it to FAQ[1]. As I wrote there, I don't see any way to > automate this task with manageHook. Keeping an extra bit for each window > (whether to draw borders) looks like overkill for, I guess, single > program which needs it. Does anyone have ideas how to automate > NoBorders in a simple way? > > 1. http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#I_don.27t_like_borders_around_mplayer I don't understand why xmonad cannot do the same thing as how dwm treats mplayer. -- c/* __o/* <\ * (__ */\ < From roma at ro-che.info Fri Feb 1 17:36:59 2008 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri Feb 1 17:36:35 2008 Subject: [xmonad] mplayer & borders In-Reply-To: <87ir18e2ly.fsf@columbia.edu> References: <20080201220100.GA6789@home.ro-che.info> <87ir18e2ly.fsf@columbia.edu> Message-ID: <20080201223659.GA7173@home.ro-che.info> * Xiao-Yong Jin [2008-02-01 17:25:13-0500] > Roman Cheplyaka writes: > > > It seems to be one of the most frequently asked questions on the IRC, so > > I've just added it to FAQ[1]. As I wrote there, I don't see any way to > > automate this task with manageHook. Keeping an extra bit for each window > > (whether to draw borders) looks like overkill for, I guess, single > > program which needs it. Does anyone have ideas how to automate > > NoBorders in a simple way? > > > > 1. http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#I_don.27t_like_borders_around_mplayer > > I don't understand why xmonad cannot do the same thing as > how dwm treats mplayer. Would you tell us? I don't see dwm treats mplayer separately. Just one rule to make it floating in config.def.h. -- Roman I. Cheplyaka (aka Feuerbach @ IRC) -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 307 bytes Desc: Digital signature Url : http://www.haskell.org/pipermail/xmonad/attachments/20080202/7e2bf123/attachment-0001.bin From dons at galois.com Fri Feb 1 17:37:31 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 1 17:36:47 2008 Subject: [xmonad] please revert back In-Reply-To: <20080201220940.GC4849@laptop.nowhere.net> References: <20080201220940.GC4849@laptop.nowhere.net> Message-ID: <20080201223731.GG4029@scytale.galois.com> mailing_list: > Hi, > > I'm feeling in a quite difficult situation. I have pushed a huge set > of patches with the assumption they were being approved by the main > developers and now, instead of a supportive environment I feel like my > code is being rejected . it seems to work, but its just a big ugly > hack. We're coders, so can you just simply state what you want done? -- Don From xj2106 at columbia.edu Fri Feb 1 18:20:55 2008 From: xj2106 at columbia.edu (Xiao-Yong Jin) Date: Fri Feb 1 18:21:31 2008 Subject: [xmonad] mplayer & borders In-Reply-To: <20080201223659.GA7173@home.ro-che.info> (Roman Cheplyaka's message of "Sat, 2 Feb 2008 00:36:59 +0200") References: <20080201220100.GA6789@home.ro-che.info> <87ir18e2ly.fsf@columbia.edu> <20080201223659.GA7173@home.ro-che.info> Message-ID: <87ejbwe014.fsf@columbia.edu> Roman Cheplyaka writes: > * Xiao-Yong Jin [2008-02-01 17:25:13-0500] >> Roman Cheplyaka writes: >> >> > It seems to be one of the most frequently asked questions on the IRC, so >> > I've just added it to FAQ[1]. As I wrote there, I don't see any way to >> > automate this task with manageHook. Keeping an extra bit for each window >> > (whether to draw borders) looks like overkill for, I guess, single >> > program which needs it. Does anyone have ideas how to automate >> > NoBorders in a simple way? >> > >> > 1. http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#I_don.27t_like_borders_around_mplayer >> >> I don't understand why xmonad cannot do the same thing as >> how dwm treats mplayer. > > Would you tell us? > > I don't see dwm treats mplayer separately. > Just one rule to make it floating in config.def.h. Have you tried it? It is not a separate treatment. The issue is that, in dwm, when the rule is applied, full screened mplayer, got by pressing `f', is _correctly_ positioned on the screen, borders _outside_ of the screen. On the contrary, what you can get from a floating full screened mplayer in xmonad is top and left borders on the edge of the screen and you need to move the mplayer window up and left 1 pixel manually to achieve what dwm does automatically. I'm no expert on window manager. Hope the above description is informative enough. -- c/* __o/* <\ * (__ */\ < From mailing_list at istitutocolli.org Fri Feb 1 19:08:46 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 19:08:34 2008 Subject: [xmonad] please revert back In-Reply-To: <20080201223731.GG4029@scytale.galois.com> References: <20080201220940.GC4849@laptop.nowhere.net> <20080201223731.GG4029@scytale.galois.com> Message-ID: <20080202000844.GD4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 02:37:31PM -0800, Don Stewart wrote: > mailing_list: > We're coders, so can you just simply state what you want done? I've sent many mail describing what I was doing. If those mail did not get read I cannot be of any help. If the way they were written cannot be understood (I would expect that in a friendly environment one would write back to ask "what the hell are you saying!"), if all that doesn't work I'm really asking how much time do you think I will be willing to dedicate, if, all I did was useless? we are coder? read the code. if you like it keep it, otherwise, please revert. and we just have this ugly discussion closed. As I said I feel deeply embarrassed by this situation. Can you understand that? Andrea From codesite-noreply at google.com Fri Feb 1 19:17:05 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 19:16:18 2008 Subject: [xmonad] Issue 125 in xmonad: Tabbed layout not working anymore Message-ID: <00163646d136044521cf95dfd1319e7f@google.com> Issue 125: Tabbed layout not working anymore http://code.google.com/p/xmonad/issues/detail?id=125 Comment #18 by andrea.rossato: since I read, from the main developer and xmonad author: "I think this solution is *really* ugly. Also, I don't think we can necessarily rely on the property that decorations windows are the only override-redirect windows in the windowset." I just replay that I have no replay but to ask to revert to the previous system, since my patch is the logic consequence of the design chosen, which probably requires such *really* ugly stuff. I'm sorry for the inconvenience. Also because I have no other ideas on how to solve this issue, if not by reverting to the back version. ps: the link error where just my stupidity. Since windowremover came after windownavigator, in the cabal file I accidentally renamed the first. Thanks, Spencer, for pointing that out. Issue attribute updates: Owner: SpencerJanssen -- 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 From codesite-noreply at google.com Fri Feb 1 20:37:15 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 20:36:27 2008 Subject: [xmonad] Issue 133 in xmonad: xmonad-contrib source code "cleanup" - in search of a user code location Message-ID: <0016363b7b08044522ee466414326d69@google.com> Issue 133: xmonad-contrib source code "cleanup" - in search of a user code location http://code.google.com/p/xmonad/issues/detail?id=133 Comment #2 by dons00: How about interfaces get some docs describing their purpose, and point to where to find specific instances? Can you make these tickets more focused? I'm finding them vague and rambling, so they're difficult to address or close. -- 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 From dons at galois.com Fri Feb 1 20:40:26 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 1 20:39:39 2008 Subject: [xmonad] mplayer & borders In-Reply-To: <87ejbwe014.fsf@columbia.edu> References: <20080201220100.GA6789@home.ro-che.info> <87ir18e2ly.fsf@columbia.edu> <20080201223659.GA7173@home.ro-che.info> <87ejbwe014.fsf@columbia.edu> Message-ID: <20080202014026.GC13847@scytale.galois.com> xj2106: > Roman Cheplyaka writes: > > > * Xiao-Yong Jin [2008-02-01 17:25:13-0500] > >> Roman Cheplyaka writes: > >> > >> > It seems to be one of the most frequently asked questions on the IRC, so > >> > I've just added it to FAQ[1]. As I wrote there, I don't see any way to > >> > automate this task with manageHook. Keeping an extra bit for each window > >> > (whether to draw borders) looks like overkill for, I guess, single > >> > program which needs it. Does anyone have ideas how to automate > >> > NoBorders in a simple way? > >> > > >> > 1. http://haskell.org/haskellwiki/Xmonad/Frequently_asked_questions#I_don.27t_like_borders_around_mplayer > >> > >> I don't understand why xmonad cannot do the same thing as > >> how dwm treats mplayer. > > > > Would you tell us? > > > > I don't see dwm treats mplayer separately. > > Just one rule to make it floating in config.def.h. > > Have you tried it? It is not a separate treatment. The > issue is that, in dwm, when the rule is applied, full > screened mplayer, got by pressing `f', is _correctly_ > positioned on the screen, borders _outside_ of the screen. > On the contrary, what you can get from a floating full > screened mplayer in xmonad is top and left borders on the > edge of the screen and you need to move the mplayer window > up and left 1 pixel manually to achieve what dwm does > automatically. > > I'm no expert on window manager. Hope the above description > is informative enough. Oh! How about we just have a manageHook that sets the desired geometry? From codesite-noreply at google.com Fri Feb 1 20:41:15 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Fri Feb 1 20:40:27 2008 Subject: [xmonad] Issue 132 in xmonad: We should have a convention for layout names Message-ID: <0016e649d3b8044522fc9838fb325fab@google.com> Issue 132: We should have a convention for layout names http://code.google.com/p/xmonad/issues/detail?id=132 Comment #1 by dons00: ' isn't very useful to non-Haskellers, but more regularity seems desirable. So, add some text to the STYLE guide if you've something concrete to do here -- no need to open a ticket for it. Issue attribute updates: Status: Invalid -- 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 From dons at galois.com Fri Feb 1 20:44:58 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 1 20:44:22 2008 Subject: [xmonad] darcs patch: Add windowRemover for make tabbed return just the focu... In-Reply-To: <20080201210046.GA5366@presario> References: <200802011102.m11B24oj006771@laptop.nowhere.net> <20080201210046.GA5366@presario> Message-ID: <20080202014458.GD13847@scytale.galois.com> sjanssen: > On Fri, Feb 01, 2008 at 12:02:04PM +0100, Andrea Rossato wrote: > > Hi, > > > > this is a follow up of the discussion with Spencer about tabbed. > > > > This patch implements WindowRemover. If placed over tabbed it should > > be removing unfocused windows, without touching the windows > > decoration. > > > > WARNING: while this patch passes all tests both with ghc-6.6.1 and > > ghc-6.8.2, when I build this test file: > > import XMonad > > import XMonad.Config.Arossato > > main = xmonad =<< arossatoConfig > > > > ghc-6.6.1 fails with this linker error: > > [12:00:33][wolf@laptop:~/.xmonad]$ ghc --make xmonad.hs > > Linking xmonad ... > > /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o): In function `s1e0s_info': > > ghc3557_0.hc:(.text+0x3ada): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_info' > > /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o):(.rodata+0xa8): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_closure' > > collect2: ld returned 1 exit status > > > > The same code compiles, and works perfectly (unless bugs introduced by > > its author, me) on ghc-6.8.2. > > > > This is why I'd like someone to test it (I'll include it also in the > > bug tracker). > > > > Cheers, > > Andrea > > > > Fri Feb 1 11:55:05 CET 2008 Andrea Rossato > > * Add windowRemover for make tabbed return just the focused window > > I think this solution is *really* ugly. Also, I don't think we can > necessarily rely on the property that decorations windows are the only > override-redirect windows in the windowset. That sounds fragile. From dons at galois.com Fri Feb 1 20:49:24 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 1 20:48:40 2008 Subject: [xmonad] some cleanup In-Reply-To: <20080201110231.GW4849@laptop.nowhere.net> References: <20080131103538.GL4849@laptop.nowhere.net> <20080201085132.GA5320@presario> <20080201100058.GV4849@laptop.nowhere.net> <20080201110231.GW4849@laptop.nowhere.net> Message-ID: <20080202014924.GE13847@scytale.galois.com> mailing_list: > On Fri, Feb 01, 2008 at 11:00:58AM +0100, Andrea Rossato wrote: > > [1] At the present time, when I was trying to test it, I started > > experiencing strange problems with the linker: > > > > /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o): In function `s1e0s_info': > > ghc3557_0.hc:(.text+0x3ada): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_info' > > /usr/local/lib/xmonad-contrib-0.6/ghc-6.6.1/libHSxmonad-contrib-0.6.a(Combo.o):(.rodata+0xa8): undefined reference to `xmonadzmcontribzm0zi6_XMonadziLayoutziWindowNavigation_zdf3_closure' > > collect2: ld returned 1 exit status > > > > It seems like I found a bug in ghc-6.6.1 and I need to upgrade to > 6.8.2. > > Now that is going to be a bit of a pain... > > Anyhow, the code I'm sending in a separate patch seems to work fine > with ghc-6.8.2. > Missing module in the cabal file? From allbery at ece.cmu.edu Fri Feb 1 20:52:05 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Feb 1 20:51:20 2008 Subject: [xmonad] darcs patch: Add windowRemover for make tabbed return just the focu... In-Reply-To: <20080202014458.GD13847@scytale.galois.com> References: <200802011102.m11B24oj006771@laptop.nowhere.net> <20080201210046.GA5366@presario> <20080202014458.GD13847@scytale.galois.com> Message-ID: On Feb 1, 2008, at 20:44 , Don Stewart wrote: > sjanssen: >> I think this solution is *really* ugly. Also, I don't think we can >> necessarily rely on the property that decorations windows are the >> only >> override-redirect windows in the windowset. > > That sounds fragile. The correct thing to do is to set a property on decoration windows, preferably one that links them to the decorated window (window ids are perfectly acceptable for this) so that xmonad can re-adopt them when restarted without state (or after mod-shift-space? --- and possibly only to destroy them in that case so it can start over with a clean slate). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From dons at galois.com Fri Feb 1 20:53:38 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 1 20:52:54 2008 Subject: [xmonad] darcs patch: some core documentation updates In-Reply-To: <22fcbd520802011130p24e2b9abvc6e497b5f342ea1d@mail.gmail.com> References: <22fcbd520802011130p24e2b9abvc6e497b5f342ea1d@mail.gmail.com> Message-ID: <20080202015338.GF13847@scytale.galois.com> byorgey: > Fri Feb 1 14:06:53 EST 2008 Brent Yorgey <[1]byorgey@gmail.com> > * Core.hs, StackSet.hs: some documentation updates Did this patch not send properly It's body is missing. -- Don From byorgey at gmail.com Fri Feb 1 20:56:10 2008 From: byorgey at gmail.com (Brent Yorgey) Date: Fri Feb 1 20:55:23 2008 Subject: [xmonad] darcs patch: some core documentation updates In-Reply-To: <20080202015338.GF13847@scytale.galois.com> References: <22fcbd520802011130p24e2b9abvc6e497b5f342ea1d@mail.gmail.com> <20080202015338.GF13847@scytale.galois.com> Message-ID: <22fcbd520802011756s3b9c917cwb91444edee967194@mail.gmail.com> Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: core-documentation-updates.dpatch Type: application/octet-stream Size: 8992 bytes Desc: not available Url : http://www.haskell.org/pipermail/xmonad/attachments/20080201/375e58cf/core-documentation-updates.obj From mailing_list at istitutocolli.org Fri Feb 1 20:56:26 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 20:56:12 2008 Subject: [xmonad] Issue 132 in xmonad: We should have a convention for layout names In-Reply-To: <0016e649d3b8044522fc9838fb325fab@google.com> References: <0016e649d3b8044522fc9838fb325fab@google.com> Message-ID: <20080202015626.GE4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 05:41:15PM -0800, codesite-noreply@google.com wrote: > Comment #1 by dons00: > ' isn't very useful to non-Haskellers, but more regularity seems desirable. > > So, add some text to the STYLE guide if you've something concrete to do here > -- no need > to open a ticket for it. I'm sorry, I thought that a track system was for keeping track of the activities that can must be done, and a place where a discussion on how those activities must be done can take place, while a darcs push, which passes over the head of everybody, is just an unnoticed authoritative decision. But I will use it only in response to reports from other, starting from now. Thanks for the information. Andrea From dons at galois.com Fri Feb 1 21:05:27 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 1 21:04:42 2008 Subject: [xmonad] darcs patch: some core documentation updates In-Reply-To: <22fcbd520802011756s3b9c917cwb91444edee967194@mail.gmail.com> References: <22fcbd520802011130p24e2b9abvc6e497b5f342ea1d@mail.gmail.com> <20080202015338.GF13847@scytale.galois.com> <22fcbd520802011756s3b9c917cwb91444edee967194@mail.gmail.com> Message-ID: <20080202020527.GG13847@scytale.galois.com> byorgey: > On Fri, Feb 1, 2008 at 8:53 PM, Don Stewart <[1]dons@galois.com> wrote: > > byorgey: > > Fri Feb 1 14:06:53 EST 2008 Brent Yorgey > <[1]byorgey@[2]gmail.com> > > * Core.hs, StackSet.hs: some documentation updates > > Did this patch not send properly > It's body is missing. > > Heh, yes, let's leave that in the passive voice... =P :) it's applied. :) From dons at galois.com Fri Feb 1 21:07:59 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 1 21:07:25 2008 Subject: [xmonad] darcs patch: Always float ediff windows In-Reply-To: <20080131052721.GA5382@presario> References: <20080131013800.23A0A24F099@ives.vdov.net> <20080131052721.GA5382@presario> Message-ID: <20080202020759.GH13847@scytale.galois.com> sjanssen: > On Wed, Jan 30, 2008 at 08:37:31PM -0500, Alec Berryman wrote: > > ediff is a popular and widely-used interactive diff/merge mode included > > with emacs. It works by opening up a small window that the user keeps > > in focus while using ediff commands like next patch; if the main emacs > > window is in focus, none of the ediff key commands are available. The > > small window generally obscures what the user is interested in and is > > kept as small and out of the way as possible; by default, it opens up > > very tiny in the top right of the screen. > > > > The window is already in way just by existing, but having xmonad try to > > manage it really screws things up. It's in the same class as MPlayer > > and GIMP; there's no use case for managing it, so do the right thing by > > default and always float it. > > > > I used title instead of className because the className is emacs, and > > floating all emacs buffers is definitely not the right thing to do. > > > > Wed Jan 30 18:38:20 EST 2008 Alec Berryman > > * Always float ediff windows > > I tend to agree with Andrea's analysis here -- I don't think we can get into > adding these workarounds for every goofy application. > > You might consider sending a bug report to the emacs people, setting > WM_TRANSIENT_FOR on this window will improve this application's behavior in all > window managers. We could collect a list of wacky stuff in an import Wacky module. Or maybe just collect them on the wiki From allbery at ece.cmu.edu Fri Feb 1 21:11:01 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Feb 1 21:10:16 2008 Subject: miscommunication (was Re: [xmonad] Issue 132 in xmonad) In-Reply-To: <20080202015626.GE4849@laptop.nowhere.net> References: <0016e649d3b8044522fc9838fb325fab@google.com> <20080202015626.GE4849@laptop.nowhere.net> Message-ID: <8AE897FB-A2B0-4A89-91C8-E46174A79224@ece.cmu.edu> Folks, it's clear we have some communication problems going on. Let's all step back and take a deep breath, hm? As seen from my vantage point (which is almost certainly inaccurate because I don't have access to your internal state --- then again, that's kind of the point...): Andrea has been playing with a new layout and decoration framework to address some shortcomings in xmonad. It seemed to me that he was sending patches to the list that he didn't expect to have committed (and at least one of them made me say "wait, I thought he said this was for experimentation, not committing"), and committing it probably left *him* feeling "committed". Since then has been a series of miscommunications because Don and Spencer seem to be looking at it from "Andrea is pushing incompletely-thought-out patches" and Andrea seems to be looking at it as "wait, my experimental patches got committed, now I have no choice but to figure out how to make them work". Can you three sit down (virtually, at least) and make sure you're all on the same page? -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From dons at galois.com Fri Feb 1 21:12:13 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 1 21:11:26 2008 Subject: [xmonad] Issue 132 in xmonad: We should have a convention for layout names In-Reply-To: <20080202015626.GE4849@laptop.nowhere.net> References: <0016e649d3b8044522fc9838fb325fab@google.com> <20080202015626.GE4849@laptop.nowhere.net> Message-ID: <20080202021213.GI13847@scytale.galois.com> mailing_list: > On Fri, Feb 01, 2008 at 05:41:15PM -0800, codesite-noreply@google.com wrote: > > Comment #1 by dons00: > > ' isn't very useful to non-Haskellers, but more regularity seems desirable. > > > > So, add some text to the STYLE guide if you've something concrete to do here > > -- no need > > to open a ticket for it. > > I'm sorry, I thought that a track system was for keeping track of the > activities that can must be done, and a place where a discussion on > how those activities must be done can take place, while a darcs push, > which passes over the head of everybody, is just an unnoticed > authoritative decision. > > But I will use it only in response to reports from other, starting > from now. > Its useful for bugs that need to be fixed. And things we need to remember to do. If its just a style thing, we can put that in the style guide. But its a good idea not to pollute the bug tracker with too many idle things, since we won't be able to manage so many open tickets -- they'll just get closed. From sjanssen at cse.unl.edu Fri Feb 1 21:15:25 2008 From: sjanssen at cse.unl.edu (Spencer Janssen) Date: Fri Feb 1 21:15:28 2008 Subject: [xmonad] darcs patch: Add windowRemover for make tabbed return just the focu... In-Reply-To: <20080201212119.GB4849@laptop.nowhere.net> References: <200802011102.m11B24oj006771@laptop.nowhere.net> <20080201210046.GA5366@presario> <20080201212119.GB4849@laptop.nowhere.net> Message-ID: <20080202021525.GA6868@presario> On Fri, Feb 01, 2008 at 10:21:19PM +0100, Andrea Rossato wrote: > On Fri, Feb 01, 2008 at 03:00:47PM -0600, Spencer Janssen wrote: > > I think this solution is *really* ugly. Also, I don't think we can necessarily > > rely on the property that decorations windows are the only override-redirect > > windows in the windowset. > > Sorry Spencer, > > but I deduce, from your words, that all my job has been base on > completely false assumptions, and probably we must have some serious > code review. > > I'm not kidding, and I'm not ironic. I do really take into > consideration of just being plainly wrong on everything. You know I > have high respect for your knowledge. > > 1) > handle (MapRequestEvent {ev_window = w}) = withDisplay $ \dpy -> do > wa <- io $ getWindowAttributes dpy w -- ignore override windows > -- need to ignore mapping requests by managed windows not on the current workspace > managed <- isClient w > when (not (wa_override_redirect wa) && not managed) $ do manage w > > 2) a window with override_redirect *must* always pass true. > > 3) no modifier is allowed to change the stack set! they can *only* > manipulate the (window,rectangle) list to be returned in > Operations.windows. Modifier *DO NOT* manipulate the stack. Once > "restackWindows d vs" has being called, track of layouts/modifiers' > activity can be found only in the layout field of the workspace type. > > If any of these three assumptions is false, we should probably > consider to revert immediately. > > I'm serious, and I understand that we must provide a certain level of > code correctness. > > Cheers, > Andrea Well, my objections to using override-redirect to identify decorations are more philosophical than practical -- it is probably "good enough" for now. The suggestion to use an window property instead is a good one, I think. But that's neither here nor there. My real objection is that we're removing windows that shouldn't have been in the output in the first place. Doesn't that seem more like we're working around Decorations than working with it? Point 3 is about the other thread we're having with clickable tabs/decorations, right? I'll respond in that thread. Cheers, Spencer Janssen PS -- Calm down! Your work is good, I just think we need to evolve it a bit. From dons at galois.com Fri Feb 1 21:19:09 2008 From: dons at galois.com (Don Stewart) Date: Fri Feb 1 21:18:38 2008 Subject: miscommunication (was Re: [xmonad] Issue 132 in xmonad) In-Reply-To: <8AE897FB-A2B0-4A89-91C8-E46174A79224@ece.cmu.edu> References: <0016e649d3b8044522fc9838fb325fab@google.com> <20080202015626.GE4849@laptop.nowhere.net> <8AE897FB-A2B0-4A89-91C8-E46174A79224@ece.cmu.edu> Message-ID: <20080202021909.GJ13847@scytale.galois.com> allbery: > Folks, it's clear we have some communication problems going on. > Let's all step back and take a deep breath, hm? > > As seen from my vantage point (which is almost certainly inaccurate > because I don't have access to your internal state --- then again, > that's kind of the point...): Andrea has been playing with a new > layout and decoration framework to address some shortcomings in > xmonad. It seemed to me that he was sending patches to the list that > he didn't expect to have committed (and at least one of them made me > say "wait, I thought he said this was for experimentation, not > committing"), and committing it probably left *him* feeling > "committed". Since then has been a series of miscommunications > because Don and Spencer seem to be looking at it from "Andrea is > pushing incompletely-thought-out patches" and Andrea seems to be > looking at it as "wait, my experimental patches got committed, now I > have no choice but to figure out how to make them work". > > Can you three sit down (virtually, at least) and make sure you're all > on the same page? > Thanks for faciliting this Brandon. My concern is: * too much traffic is going to the list * experiments that should just be passed around on IRC are going to the list when they shouldn't * there are unclear expectations of the role Spencer and I play supervising code. One concrete suggestion would be to sit on patches for longer, Andrea. That is, code them up, then experiment for a few days until you're sure everything's ok. Only then send things to the list. That way you avoid overwhelming people with the streams of patches that appear. Consider how many people actually need to know about the problem. Do all xmonad subscribers need to know? A second point: not everyone will be interested in all the things you work on. After all, it is open source, so you do as you please. Just don't expect to always get feedback on your experiments -- and you shouldn't be upset if people aren't interested. -- Don From allbery at ece.cmu.edu Fri Feb 1 21:24:46 2008 From: allbery at ece.cmu.edu (Brandon S. Allbery KF8NH) Date: Fri Feb 1 21:24:01 2008 Subject: miscommunication (was Re: [xmonad] Issue 132 in xmonad) In-Reply-To: <20080202021909.GJ13847@scytale.galois.com> References: <0016e649d3b8044522fc9838fb325fab@google.com> <20080202015626.GE4849@laptop.nowhere.net> <8AE897FB-A2B0-4A89-91C8-E46174A79224@ece.cmu.edu> <20080202021909.GJ13847@scytale.galois.com> Message-ID: <05CCE749-498C-41E0-AD87-B4BC7A88C915@ece.cmu.edu> On Feb 1, 2008, at 21:19 , Don Stewart wrote: > That way you avoid overwhelming people with the streams of patches > that appear. Consider how many people actually need to know > about the problem. Do all xmonad subscribers need to know? Most active projects have separate -users and -devel lists. I have myself thought that xmonad was active enough that keeping them combined was likely to annoy both users (who don't want to see, or care about, most of these patches) and developers (who are likely to regard user-type questions/discussions as unnecessary distractions). -- brandon s. allbery [solaris,freebsd,perl,pugs,haskell] allbery@kf8nh.com system administrator [openafs,heimdal,too many hats] allbery@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH From mailing_list at istitutocolli.org Fri Feb 1 22:00:40 2008 From: mailing_list at istitutocolli.org (Andrea Rossato) Date: Fri Feb 1 22:00:25 2008 Subject: [xmonad] some cleanup In-Reply-To: <20080201085132.GA5320@presario> References: <20080131103538.GL4849@laptop.nowhere.net> <20080201085132.GA5320@presario> Message-ID: <20080202030040.GF4849@laptop.nowhere.net> On Fri, Feb 01, 2008 at 02:51:33AM -0600, Spencer Janssen wrote: > - Run 'decorate' even on windows that aren't returned by doLayout (perhaps use > Maybe Rectangle as an argument, where Nothing signifies the window isn't > visible) why should I decorate those windows and then mark them as non visible? How can I know which window is visible in, say, a decorated circle layout, or in a floating layout? All windows maybe decorated, and it is only by inspecting its geometry (can be done) and comparing it with the geometry of the list of all windows (decorate can do that too), that you can have an idea of what could be visible. Instead, it is decorate that may want or not to want decorate a window, and indeed it returns a Maybe rectangle (the pure version). Think about the DwmStyle... When a layout produces a list of windows, decorations will look the stack and will not decorate that window returning a Nothing. > > - Allow 'decorate' to return a list of decorations, rather than a single > decoration. I don't get this. decorate is run to each member of the (window, rectangle) list produced by a layout (resync in the instance, - resync is not pure to let to let decorate return X (Mayb Rectangle), and operate in the X monad. > I haven't been able to divine the logic behind the code to make either > modification myself, but I might be able to with a bit of documentation tossed > in there :) > > I'm inclined to leave the base layout as Full, even though that is slightly > broken at the moment. Thus are the perils of running software-in-development. > this is the pipe line. Every layout may (should be possible for it to) through;: 1. doLayout is called to some layout and a list [(w,r)] is produced; 2. arranger (pure layout modifier) which keeps track of geometries: data ArrangedWindow a = WR (a, Rectangle) -- original geometries produced by the underlying layout | AWR (a, Rectangle) -- geometry modified by a sendMessage The modifier (instance of LayoutModifier), with only a pure implementation: type ArrangeAll = Bool data WindowArranger a = WA Bool ArrangeAll [ArrangedWindow a] deriving (Read, Show) The Bool to toggle it off and on with a sendmessage. ArrangeAll for the floating layout. 3. Decorator: process the list and according to the DecorationStyle decide if and how decorate each window of the list. Choice is almost pure but in the X for more expressiveness of the types. 3a: decorate, the main method of the DecorationStyle is: decorate :: ds a -> Dimension -- user defaults, may be overwritten (decoration too small) -> Dimension -- user defaults, may be overwritten (decoration too small) -> Rectangle -> W.Stack a -> [(a,Rectangle)] -> (a,Rectangle) -> X (Maybe Rectangle) takes everything and, specifically the window and the rectangle to decorate (and run in resync, which could be pure, but I did it impure for increasing the power of decorate in terms of windows choice - windowAttributes?). The task of resync is to keep synchronized the (w,r) list with the decoration list (and geometry) - its State component. 3b: finally insert_dwr will fold the list of windows and (Maybe) decorations and will place them in front of the window they were created for. 4: then you start applying post decoration modifier, like WindowRemover (if you want remove window). 5. everything gets to restackWindos d list 6. Decoration keeps track of every decoration and will remove them when requested, or by an empty layout. My working proposal, as I reported in the abused tracker, the *really* ugly one, is to return the first window of the list produced by decoration, and then remove all windows that are not decorations, which means I remove the unfocused windows. But leaving the possibility of the other approach too. Obviously, over the windowRemover every modifier may be thinking that the layout was produced by Full, but it will receive the decorations too, but can just skip them when processing the list (what I say decoration awareness of a modifier) Andrea From codesite-noreply at google.com Sat Feb 2 03:28:50 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Sat Feb 2 03:28:02 2008 Subject: [xmonad] Issue 129 in xmonad: ClassLayout.description type signature is wrong Message-ID: <000e0cd20c3e044528ae3a36391ddd19@google.com> Issue 129: ClassLayout.description type signature is wrong http://code.google.com/p/xmonad/issues/detail?id=129 Comment #4 by andrea.rossato: (No comment was entered for this change.) Issue attribute updates: Status: Invalid -- 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 From codesite-noreply at google.com Sat Feb 2 03:32:51 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Sat Feb 2 03:32:01 2008 Subject: [xmonad] Issue 130 in xmonad: The Decoration modifier should be decoration aware Message-ID: <000e0cd29bbc044528bc8d3aee1dd5a9@google.com> Issue 130: The Decoration modifier should be decoration aware http://code.google.com/p/xmonad/issues/detail?id=130 Comment #1 by andrea.rossato: (No comment was entered for this change.) Issue attribute updates: Status: Invalid -- 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 From codesite-noreply at google.com Sat Feb 2 03:36:51 2008 From: codesite-noreply at google.com (codesite-noreply@google.com) Date: Sat Feb 2 03:36:03 2008 Su