February 2008 - xmonad

Issue 134 in xmonad: Wrong tiled window displayed when switching focus to floating window
by codesite-noreply＠google.com 03 Feb '08

03 Feb '08

Issue 134: Wrong tiled window displayed when switching focus to floating window http://code.google.com/p/xmonad/issues/detail?id=134 Comment #1 by SpencerJanssen: This is an instance of our oldest bug: #4 Issue attribute updates: Status: Duplicate -- 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 135 in xmonad: toggleBorders (XMonad.Action.NoBorders) Causes floating windows to grow in size
by codesite-noreply＠google.com 03 Feb '08

03 Feb '08

Issue 135: toggleBorders (XMonad.Action.NoBorders) Causes floating windows to grow in size http://code.google.com/p/xmonad/issues/detail?id=135 New issue report by heggstad: What steps will reproduce the problem? 1. laod XMonad.Action.NoBorder from XMonadContrib 2. use the function toggleBorder on a window 3. move the window around, or click on it What is the expected output? What do you see instead? Expected: window size to stay the same Actual: window grows in sice every pixel it moves and/or everytime you click on it. Behaviour differes a bit from app to app. Seems like it grows the same number of pixels as the border is set to. What version of the product are you using? On what operating system? xmonad 0.6 | Arch Linux | 2.6.23-ARCH i686 GNU/Linux Please provide any additional information below. Running xmonad as a drop in replacement for metacity xorg-server 1.4.0.90 Gnome 2.20 Tested with gmplayer, Firefox3b2 ~/.xmonad/xmonad.hs attatched If this error is due to a module from XMonadContrib, please tag this issue with 'Component-Contrib' below. Component-Contrib Attachments: xmonad.hs 10.0 KB Issue attributes: Status: New Owner: ---- 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

1 0

Issue 134 in xmonad: Wrong tiled window displayed when switching focus to floating window
by codesite-noreply＠google.com 03 Feb '08

03 Feb '08

Issue 134: Wrong tiled window displayed when switching focus to floating window http://code.google.com/p/xmonad/issues/detail?id=134 New issue report by shachaf: What steps will reproduce the problem? 1. Open windows A, B, C in Tall layout 2. Float window C 3. Switch to Full layout 4. Move focus to window A What is the expected output? What do you see instead? Window C is still floating, but the Full layout now shows window B (should be window A) What version of the product are you using? Latest darcs, but reported with 0.6. Please provide any additional information below. Reported by lionroar in #xmonad. If this error is due to a module from XMonadContrib, please tag this issue with 'Component-Contrib' below. Issue attributes: Status: New Owner: ---- 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

1 0

darcs patch: let enter dismiss compile errors
by daniel＠wagner-home.com 03 Feb '08

03 Feb '08

Sun Feb 3 12:28:52 PST 2008 daniel(a)wagner-home.com * let enter dismiss compile errors

2 1

Issue 132 in xmonad: We should have a convention for layout names
by codesite-noreply＠google.com 02 Feb '08

02 Feb '08

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

5 7

mplayer & borders
by Roman Cheplyaka 02 Feb '08

02 Feb '08

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_… -- Roman I. Cheplyaka (aka Feuerbach @ IRC)

3 6

The future of PerWorkspace
by Brent Yorgey 02 Feb '08

02 Feb '08

Hi all! This may end up being a long e-mail. Executive summary: 1. PerWorkspace is an inelegant hack with several icky problems: - 'description' is not in the X monad so can't figure out the current workspace - the currently focused workspace might not even be the correct one anyway, in the case of xinerama or message handling. 2. Andrea's LayoutCombinator class and core patch to move the result of the description function into the X monad will help with some but not all of the problems. In particular it still won't work with xinerama. 3. It would be nice to have the PerWorkspace functionality supported in the core, and I have a nice, elegant way to do it. This would fix all the problems. ...The only catch is that it would also require going back to requiring existential Layout wrappers everywhere. =( 4. Well, crap. I had recently been thinking about PerWorkspace and ways to improve it, but hadn't yet gotten around to really doing anything about it. Andrea's new emptyLayout function, and then in particular his reimplementation of PerWorkspace using the new LayoutCombinator framework obviously motivated me to get around to it! So I'd like to explain some of the problems with PerWorkspace and possible future directions. First, the basics: although the xmonad core tracks layouts separately for each workspace, it is not possible to *specify* a different starting layout on a per-workspace basis. Only a single layout may be specified in the XConfig record, and this layout is duplicated across all workspaces on xmonad startup. PerWorkspace attempts to get around this limitation by providing a layout which dynamically decides on which of two sub-layouts to use, based on the current workspace tag. All workspaces still have the same layout, but that one layout acts differently depending on the current workspace. You can see from the beginning that this is something of a hack. This approach has two major limitations, each of which leads to one or more problems. * To find out the current workspace obviously requires access to the X monad. For doLayout and handleMessage this is obviously not a problem. The description method, however, is a pure function. I solved this in a very hackish way before by having a call to doLayout return a modified PerWorkspace layout structure with a cached value remembering which of the two layouts should be used. description could then use this cached value to decide on the description to return. Andrea's current reimplementation of PerWorkspace does not do this caching, which is why the description method is currently broken. I can reimplement this, and the new emptyLayout method will help, but it still feels very inelegant. * A more insidious problem is that it is not possible, in general, for doLayout or doMessage to figure out which workspace they belong to, and hence which layout to use. PerWorkspace currently works by retrieving the tag of the currently focused workspace from the xmonad state, but there are several situations in which doLayout or handleMessage are called on a workspace which is not the currently focused workspace: - If xinerama is in use, doLayout will be called for all the visible workspaces as well as the focused workspace. - Messages can be broadcast to all workspaces, in which case handleMessage will be called for all workspaces, including non-focused or even hidden workspaces. In either of these situations, PerWorkspace may choose the wrong layout. The message problem can be solved by simply passing along any messages to all layouts, without trying to decide on the correct one: it cannot hurt to pass messages to unintended recipients, especially if the unintended recipient layouts will never be used anyway! The xinerama problem seems insoluble, however. PerWorkspace simply cannot work on xinerama because it cannot get the information it needs to decide which layout to use. So, what is the way forward? It looks like I can get PerWorkspace back to its original level of workingness --- thanks to the LayoutCombinator class it will be a lot shorter, but it still won't work with xinerama, and it will still be an ugly, fragile hack. I had been intending to suggest adding support for per-workspace layouts to the xmonad core. After all, xmonad does track and save/restore layouts on a per-workspace basis, so why shouldn't it allow configuring them on a per-workspace basis too? I intended to keep the current layoutHook (specifying the default layout to be used on all workspaces not otherwise specified) as well as adding a new field to the config which would store a list of (workspace tag, layout) pairs. The core modifications necessary to support this are not too hard and end up being fairly elegant -- in fact, I have made these modifications in a local branch. The catch? Having a bunch of layouts in a list like this requires going back to wrapping everything with Layout existentials in user configs! =( This doesn't sound like much fun either. So, I am at something of a loss. Any thoughts or suggestions for moving forward are appreciated! -Brent

6 22

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 #3 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

Issue 131 in xmonad: We need a mouse interface to the decoration layer
by codesite-noreply＠google.com 02 Feb '08

02 Feb '08

Issue 131: We need a mouse interface to the decoration layer http://code.google.com/p/xmonad/issues/detail?id=131 Comment #2 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

Issue 130 in xmonad: The Decoration modifier should be decoration aware
by codesite-noreply＠google.com 02 Feb '08

02 Feb '08

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

1 0