- xmonad - Haskell.org

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

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