- xmonad - Haskell.org

darcs patch: XMonadContrib.Commands: for workspace and screen comma...
by glasser＠mit.edu 01 Jun '07

01 Jun '07

Fri Jun 1 12:13:51 EDT 2007 glasser(a)mit.edu * XMonadContrib.Commands: for workspace and screen commands, leave out W/S tag

2 1

[dzen] new release 0.3.0
by Robert Manea 01 Jun '07

01 Jun '07

Hello, this release features a redesign and results in less memory usage and dependencies. The use of (multi)threading was abandoned in favour of the more portable, faster and less memory hungry select() function. All of dzen's features and options should work as usual so the redisign is transparent to the user. Get it here: http://gotmor.googlepages.com/dzen2-0.3.0.tar.gz Bye, Rob. P.S.: The changes have been merged into svn trunk.

1 0

Issue 14 in project xmonad
by codesite-noreply＠google.com 01 Jun '07

01 Jun '07

Issue 14: Workspace information to stdout http://code.google.com/p/xmonad/issues/detail?id=14 Comment #3 by dons00: Example code to log state changes to stdout / stderr is in the repo now. It prints the internal state as a haskell structure. you could read it, and hack it, with a simple haskell script, e.g.: {-# OPTIONS -fglasgow-exts #-} import Data.List import StackSet import XMonad unW (W n) = n main = do s <- readIO =<< getLine :: IO ( StackSet W Integer S ) let c = map ( unW . tag ) $ workspace (current s) ws = sort $ map ( unW . tag ) $ map workspace (visible s) ++ hidden s print c print ws Issue attribute updates: Status: Started -- 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

A plan for the floating layer
by dons＠cse.unsw.edu.au 01 Jun '07

01 Jun '07

The current floating layer code handles the interface to the outside world quite nicely, but interacts strangely with fullscreen mode. The problems stem from the fact that windows are lifted into the floating layer by setting a bit flag, basically. They are then rendered separately if this flag is set. This is good, but means that floating windows keep an implicit position in the tiled ordering -- although they don't physically appear to be in the tiled layer. This leads to some oddities: * moving a floating window in fullscreen tiled mode, will shift focus of the tiled layer to the window after the implicit position of the floating mode. * mod-shift-j reorders the implicit position of a floating window in the tiled layer, but this change isn't visible I think the best way to solve this is to move from an 'implicit' floating layer, denoted by flag bits, to an explicit floating layer on each workspace: data Workspace i a = Workspace { tag :: !i , tiled :: Stack a , float :: Stack a } Now we can be sure that the floating layer is fully detached, and can be operated on in isolation, as its own zipper. For one, this will mean fullscreen mode works (since focus isn't lost on the tiled stack). Should be able to reuse the existing code (changing modify a bit). We also get a new set of operatoins on the float layer alone, or on the union of the two layers. Spencer, Jason, suggestions? Everyone else, not tracking the stable branch -- what do you think of the tiling mode as it is? this will likely be the main new (and final!) feature missing before 0.3 (and forward to 1.0). -- Don

3 3

Issue 17 in project xmonad
by codesite-noreply＠google.com 01 Jun '07

01 Jun '07

Issue 17: User-definable X monad state type http://code.google.com/p/xmonad/issues/detail?id=17 Comment #2 by dons00: See [http://www.haskell.org/pipermail/xmonad/2007-June/000476.html this post] for a patch providing arbitrary monad transformers. -- 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 17 in project xmonad
by codesite-noreply＠google.com 01 Jun '07

01 Jun '07

Issue 17: User-definable X monad state type http://code.google.com/p/xmonad/issues/detail?id=17 Comment #1 by dons00: We have two proposed solutions: 1), standard dynamically checked symbol table in XState. Using a Map String Dynamic or similar, see [http://cse.unl.edu/~sjanssen/typekey.hs] Used in Yi, notably, for data type extensions. Upside: we know it works. Downside: runtime checking, urgh. 2) user-specified StateT types. Add a data type parameter to X, defined in Config.hs. Upside: fully statically checked. Downside: combining state from separate plugins would require boilerplate (would it) 3) serious generalisation: arbitrary monad transformers. let the user plug and play whatever semantics they want. upside: ridiculously powerful generalisation. downside: type hell trying to combine separate monads in separate extensions. -- 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

User-specified monad transformers
by dons＠cse.unsw.edu.au 01 Jun '07

01 Jun '07

Extensions will likely need state, or other abilities, not provided currently by the X monad core. One approach to solve this is to add a cheap symbol table to the XState field, allowing extensions to stick their own modifiable global state. A more intriguing, and perhaps, dangerous, idea, is to allow arbitrary monad transformers to be specified by user contributions. The problem of adding state then becomes a matter of defining a StateT transformer. But it also opens up the option of using ReaderT for config values, or even hmm, ContT for check pointing state (!). By default the outer monad would be IdentityT. Downsides are unexplored, the main being: * how do you combine state, or monad state, from multiple extensions? There are cheap solutions, as we see above, but the idea of user customised monad transformers -- redefining the entire application's behaviour -- is very tempting. Here's the patch for user-specified UserT transformers, to ponder. New patches: [User-definable monad transformers: most general state/behaviour extension we can think of Don Stewart <dons(a)cse.unsw.edu.au>**20070601050546] { hunk ./Config.hs 30 +import IdentityT hunk ./Config.hs 146 +------------------------------------------------------------------------ + +-- default monad transformer to run xmonad in: +type UserT = IdentityT + +-- default way to run the monad transformer +runUserT :: Monad m => UserT m a -> m a +runUserT = runIdentityT + +-- Example, user defined state: +-- type UserT = StateT () +-- runUserT m = evalStateT m () + hunk ./Config.hs-boot 2 +import IdentityT hunk ./Config.hs-boot 8 +runUserT :: Monad m => UserT m a -> m a +type UserT = IdentityT addfile ./IdentityT.hs hunk ./IdentityT.hs 1 +----------------------------------------------------------------------------- +-- | +-- Module : Identity.hs +-- Copyright : (c) Spencer Janssen 2007 +-- License : BSD3-style (see LICENSE) +-- +-- Maintainer : dons(a)cse.unsw.edu.au +-- Stability : stable +-- Portability : portable +-- +module IdentityT where + +import Control.Monad.Trans + +-- +-- IdentityT , a parameterisable identity monad, with an inner monad +-- The user's default monad transformer +-- + +newtype IdentityT m a = IdentityT { runIdentityT :: m a } + +instance (Functor m, Monad m) => Functor (IdentityT m) where + fmap f = IdentityT . fmap f . runIdentityT + +instance (Monad m) => Monad (IdentityT m) where + return = IdentityT . return + m >>= k = IdentityT $ runIdentityT . k =<< runIdentityT m + fail msg = IdentityT $ fail msg + +instance (MonadIO m) => MonadIO (IdentityT m) where + liftIO = IdentityT . liftIO hunk ./XMonad.hs 24 +import {-# SOURCE #-} Config (UserT, runUserT) hunk ./XMonad.hs 73 -newtype X a = X (ReaderT XConf (StateT XState IO) a) +newtype X a = X (ReaderT XConf (StateT XState (UserT IO)) a) hunk ./XMonad.hs 79 -runX c st (X a) = runStateT (runReaderT a c) st >> return () +runX c st (X a) = runUserT (runStateT (runReaderT a c) st) >> return () } Context: [ignore numlock/capslock on mouse bindings Jason Creighton <jcreigh(a)gmail.com>**20070601015137] [now we handle transients properly, and restack windows, refresh from focus is ok Don Stewart <dons(a)cse.unsw.edu.au>**20070601022329] [Rename withWorkspace to withWindowSet. glasser(a)mit.edu**20070601001325] [Revert accidental change to border color Spencer Janssen <sjanssen(a)cse.unl.edu>**20070531145509] [comments on why fullscreen tiling doesn't work with `implicit' floating Don Stewart <dons(a)cse.unsw.edu.au>**20070531090537] [clean up mouse code a bit Don Stewart <dons(a)cse.unsw.edu.au>**20070531085308] [first shot at a floating layer Jason Creighton <jcreigh(a)gmail.com>**20070531044733 This is a first attempting at a floating layer: mod-button1: move window mod-button2: swapMaster mod-button3: resize window mod-t: make floating window tiled again Moving or resizing a window automatically makes it floating. Known issues: Hard to manage stacking order. You can promote a window to move it to the top, (which you can do with mod-button2) but it should be easier than that. Moving a window by dragging it to a different Xinerama screen does not move it to that workspace. Code is ugly. ] [remove LOC cap (but still print count after tests) Jason Creighton <jcreigh(a)gmail.com>**20070531043417] [TAG 0.2 Spencer Janssen <sjanssen(a)cse.unl.edu>**20070531010004] Patch bundle hash: 864d7acd95d9f45379cef7d18919783971b243f0

1 0

darcs patch: New contrib module: run internal xmonad commands via d...
by glasser＠mit.edu 01 Jun '07

01 Jun '07

Fri Jun 1 00:38:49 EDT 2007 glasser(a)mit.edu * New contrib module: run internal xmonad commands via dmenu

2 1

darcs patch: Note that my xinerama patch is now in dzen.
by glasser＠mit.edu 01 Jun '07

01 Jun '07

Fri Jun 1 00:11:12 EDT 2007 glasser(a)mit.edu * Note that my xinerama patch is now in dzen.

1 0

Issue 14 in project xmonad
by codesite-noreply＠google.com 01 Jun '07

01 Jun '07

Issue 14: Workspace information to stdout http://code.google.com/p/xmonad/issues/detail?id=14 Comment #2 by dglasser: Idea: whenever windowset (or maybe any field of XState) is changed, write out a representation of it to standard output. Then we can do xmonad | format-output | dzen2 or for that matter pipe it to a program which multiplexes output to multiple dzen2s on different screens. -- 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