February 2008 - xmonad

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

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

1 0

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

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

1 0

RIP RotView, new wiki page for notable darcs changes
by Brent Yorgey 02 Feb '08

02 Feb '08

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

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

1 0

xmonad 0.6 wrong version info
by Bastian Schnitzler 02 Feb '08

02 Feb '08

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

2 1

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

01 Feb '08

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

1 0

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

1 0

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

01 Feb '08

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

1 0