- xmonad - Haskell.org

Docks and things
by Bruce Stephens 02 Jun '07

02 Jun '07

Is XMonad intended to respect _NET_WM_WINDOW_TYPE_DOCK? I note that when I start applications like kicker, gkrellm, etc., (which xprop says have _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK) they sort of get managed (xmonad gives them a suitable managed window, though often it's blank (because the application's drawn itself elsewhere)). Shouldn't xmonad just ignore such client windows?

3 2

darcs patch: only grab button{1, 2, 3} for click-to-focus (scrollwhee...
by Jason Creighton 02 Jun '07

02 Jun '07

Fri Jun 1 23:26:05 MDT 2007 Jason Creighton <jcreigh(a)gmail.com> * only grab button{1,2,3} for click-to-focus (scrollwheel shouldn't focus)

1 0

Issue 20 in project xmonad
by codesite-noreply＠google.com 02 Jun '07

02 Jun '07

Issue 20: xrandr to make the resolution lesser does not update the geometry http://code.google.com/p/xmonad/issues/detail?id=20 New issue report by tim.thelion: What steps will reproduce the problem? 1. when the screen resolution is 1400x1050 do xrandr -s 1280x1024 2. then start firefox, 3. you will see that the right hand side is cut off What is the expected output? What do you see instead? That the geometry for firefox would be set correctly What version of the product are you using? On what operating system? 0.2 on Debian/GNU/Linux Please provide any additional information 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: make mouse bindings configurable
by Jason Creighton 02 Jun '07

02 Jun '07

Fri Jun 1 22:06:47 MDT 2007 Jason Creighton <jcreigh(a)gmail.com> * make mouse bindings configurable

1 0

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

01 Jun '07

Issue 19: Investigate a way to allow contrib extensions to use compositing. http://code.google.com/p/xmonad/issues/detail?id=19 New issue report by dons00: Hooks, or basic, compositing support. Unsure how hard this is, or how useful. It seems though, with a little work, a tiling, compositing wm would probably take a big chunk of the tiling wm market. Drop shadows alone would be very nice. The potential does need investigating. 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

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

01 Jun '07

Issue 18: Support other task bar / dock properties? http://code.google.com/p/xmonad/issues/detail?id=18 New issue report by dons00: Investigate the _NET_WM_WINDOW_TYPE_DOCK property. Which is set by gkrellm, kicker et al. _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_DOCK. Might be a way to get the gap for docs. 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: 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