June 2007 - xmonad - Haskell.org

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

Issue 17 in project xmonad
by codesite-noreply＠google.com 31 May '07

31 May '07

Issue 17: User-definable X monad state type http://code.google.com/p/xmonad/issues/detail?id=17 New issue report by dons00: Let config users pass arbitrary state around. Extends X with an addition parameter to be stored in a StateT (that's simplest I think). Then users can happily thread their own state. By default, type XUser = (). Issue attributes: Status: Accepted Owner: dons00 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

darcs patch: Add TODO about per-config state.
by glasser＠mit.edu 31 May '07

31 May '07

Thu May 31 23:20:28 EDT 2007 glasser(a)mit.edu * Add TODO about per-config state.

1 0

why no refresh on focus events?
by David Glasser 31 May '07

31 May '07

I'm working on an "accordion" layout in which the layout depends on which window is focused. (Basically: the focused window takes up most of the screen; the windows before it in the list are strips on the top, and the windows after it are strips on the bottom.) It mostly works, but only when you use focus changes that go through the "windows" function; when a window is focused by mouse-over, nothing happens. This is because of the patch quoted below, which doesn't refresh when you call "focus". I'm wondering what the problem caused by that refresh was, and if there's another way to fix it? (Also, the current doLayout signature is pretty restrictive. It would be nice if it was told the workspace ID of the workspace it is laying out; that way it can get the windowset from the X state and, say, find out what the top window of the workspace being laid out is; W.peek just gives you the focused window of the entire StackSet.) --dave Mon May 28 09:31:27 EDT 2007 Don Stewart <dons(a)cse.unsw.edu.au> * don't refresh on focus events leads to a race. this will affect how gaps are redrawn when moving to a new screen with the mouse. diff -rN -u old-xmonad/Operations.hs new-xmonad/Operations.hs --- old-xmonad/Operations.hs 2007-05-31 18:22:36.000000000 -0400 +++ new-xmonad/Operations.hs 2007-05-31 18:22:36.000000000 -0400 @@ -220,7 +220,7 @@ -- the mouse to a new screen). focus :: Window -> X () focus w = withWorkspace $ \s -> do - if W.member w s then modify (\st -> st { windowset = W.focusWindow w s }) >> refresh + if W.member w s then modify (\st -> st { windowset = W.focusWindow w s }) -- >> refresh else whenX (isRoot w) $ setFocusX w -- we could refresh here, moving gap too. -- XXX a focus change could be caused by switching workspaces in xinerama. -- if so, and the gap is in use, the gap should probably follow the -- David Glasser | glasser(a)mit.edu | http://www.davidglasser.net/

2 1

dynamic configuration? (e.g. hsplugins)
by David Roundy 31 May '07

31 May '07

I know others here have far more experience in this arena than I do, but are there any plans to support hsplugins or the ghc api, or just plain running under ghci, so that a recompile-reinstall cycle won't be necesary to update one's configuration? I'd assume this'd be in the works for version 0.7 or so, but thought I might as well ask. -- David Roundy Department of Physics Oregon State University

3 5