February 2008 - xmonad

Issue 129 in xmonad: ClassLayout.description type signature is wrong
by codesite-noreply＠google.com 02 Feb '08

02 Feb '08

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

1 0

some cleanup
by Andrea Rossato 02 Feb '08

02 Feb '08

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

5 10

darcs patch: Always float ediff windows
by Alec Berryman 02 Feb '08

02 Feb '08

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 <alec(a)thened.net> * Always float ediff windows

5 5

darcs patch: some core documentation updates
by Brent Yorgey 02 Feb '08

02 Feb '08

Fri Feb 1 14:06:53 EST 2008 Brent Yorgey <byorgey(a)gmail.com> * Core.hs, StackSet.hs: some documentation updates

2 3

Issue 133 in xmonad: xmonad-contrib source code "cleanup" - in search of a user code location
by codesite-noreply＠google.com 02 Feb '08

02 Feb '08

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

1 0

Issue 125 in xmonad: Tabbed layout not working anymore
by codesite-noreply＠google.com 02 Feb '08

02 Feb '08

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

1 0

please revert back
by Andrea Rossato 02 Feb '08

02 Feb '08

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

2 2

Issue 125 in xmonad: Tabbed layout not working anymore
by codesite-noreply＠google.com 01 Feb '08

01 Feb '08

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

3 2

Issue 133 in xmonad: xmonad-contrib source code "cleanup" - in search of a user code location
by codesite-noreply＠google.com 01 Feb '08

01 Feb '08

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

1 0

Re: [xmonad] Moving windows to a workspace based on their title / console applications in terminal emulators
by lobzang＠free.fr 01 Feb '08

01 Feb '08

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 <baschni(a)gmail.com>: > 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(a)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 <baschni(a)gmail.com>: > > > > > 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 > > > > > > > > >

4 4