- xmonad - Haskell.org

darcs patch: Fix pragmas in XMonadContrib
by Shachaf Ben-Kiki 22 Oct '07

22 Oct '07

* Fix pragmas in XMonadContrib Shachaf

2 1

darcs patch: add XSelection.hs
by Gwern Branwen 21 Oct '07

21 Oct '07

So I said I'd send in Andrea's X selection stuff when 0.3 was finalized and XMonadContrib/ opened up again. Here it is! I hope someone besides myself finds it useful. -- gwern SSCI Coderpunks David tekka CCS NMS CDA Verisign Keyer IRS

2 4

Issue 65 in xmonad: mplayer window fails to be drawn
by codesite-noreply＠google.com 21 Oct '07

21 Oct '07

Issue 65: mplayer window fails to be drawn http://code.google.com/p/xmonad/issues/detail?id=65 New issue report by ni...(a)gmx.net: What steps will reproduce the problem? 1. fire up xterm 2. type mplayer ~/somefile 3. watch...absolutely nothing What is the expected output? What do you see instead? A window of mplayer should appear, showing the video. Instead there's nothing at all, apart from a short flicker of the screen. What version of the product are you using? On what operating system? xmonad 0.4 on Linux 2.6.23 Please provide any additional information below. Doesn't work on an empty workspace as well. If this error is due to a module from XMonadContrib, please tag this issue with 'Component-Contrib' 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

3 2

darcs patch: test_XPrompt.hs: there is no ShellPrompt.rmPath
by Valery V. Vorotyntsev 20 Oct '07

20 Oct '07

Fri Oct 19 23:58:30 EEST 2007 "Valery V. Vorotyntsev" <valery.vv(a)gmail.com> * test_XPrompt.hs: there is no ShellPrompt.rmPath

2 1

issue building xmonad on OS X 10.4
by Vincent Kraeutler 20 Oct '07

20 Oct '07

Dear xmonad list, I would like to report a build problem with xmonad on OS X 10.4 as well as a) a tentative description of the problem; b) a hackish fix which seems to work for me. I. Problem description: The build fails with the following output: vincent$ runhaskell Setup.lhs configure Configuring xmonad-0.4... configure: Dependency base>=2.0: using base-2.0 configure: Dependency X11>=1.2.1: using X11-1.2.2 configure: Dependency X11-extras>=0.4: using X11-extras-0.4 configure: Dependency mtl>=1.0: using mtl-1.0 configure: Dependency unix>=1.0: using unix-1.0 [...] vincent$ runhaskell Setup.lhs build Preprocessing executables for xmonad-0.4... Building xmonad-0.4... [3 of 6] Compiling Config[boot] ( Config.hs-boot, nothing ) [4 of 6] Compiling Operations ( Operations.hs, dist/build/xmonad/xmonad-tmp/Operations.o ) Operations.hs:81:17: Not in scope: `withdrawnState' Operations.hs:190:17: Not in scope: `iconicState' Operations.hs:201:17: Not in scope: `normalState' II. Likely cause: Somehow the above symbols, #define'd in X11R6/include/X11/Xutil.h: /* definitions for initial window state */ #define WithdrawnState 0 /* for windows that are not mapped */ #define NormalState 1 /* most applications want to start this way */ #define IconicState 3 /* application wants to start as an icon */ do not get properly propagated to Operations.hs. I am still sufficiently unfamiliar with the haskell ffi/build chain to figure out where they might get dropped, but at least for me, there seems to be a problem. III. Tentative fix: Replace occurrences of the symbols with the respective hard-coded integer values. About like so: vincent$ darcs diff diff -rN old-xmonad/Operations.hs new-xmonad/Operations.hs 80c80,81 < setWMState w withdrawnState --- > setWMState w 0 > --setWMState w withdrawnState 189c190,191 < setWMState w iconicState --- > --setWMState w iconicState > setWMState w 3 199c201,202 < setWMState w normalState --- > --setWMState w normalState > setWMState w 1 xmonad then builds fine and seems to run happily as well. But obviously, this is not a satisfying solution. I would be grateful for a better one. Kind regards, v.

4 9

Freeze for 0.4
by Spencer Janssen 20 Oct '07

20 Oct '07

We're planning to release 0.4 over this weekend. In preparation for the release xmonad, XMonadContrib and X11-extras are under a feature freeze. Feel free to send bug fix and documentation patches, but please keep new feature patches to yourself until after the release. If there are any important issues that should be addressed before 0.4, now is the time to speak up! Cheers, Spencer Janssen

4 6

dynamic workspaces, session restore
by Valery V. Vorotyntsev 19 Oct '07

19 Oct '07

Hi, There are a couple ideas I would like to discuss. 1) Fixed number of workspaces is too inflexible and somewhat ugly, IMO. What about creating workspaces by demand, instead? The same way `ion' does to workspaces or screen to its "windows". 2) When xmonad quits, it forgets layout settings -- number of windows in master pane, current tiling algorithm, focused window, master/subordinate ratio, etc. Doesn't it? We could save this information to `~/.xmonad' file and read it at next startup. And a question. 3) Can I define a key binding like, say, `Win-k 1'? The pattern is `<modifiers>-<key1> <key2>'. I find such screen/ion/emacs-y keystrokes very handy. :) Thank you. And happy hacking! -- vvv

6 11

Issue 56 in xmonad: Focus is not given to correct window when switching virtual desktops
by codesite-noreply＠google.com 19 Oct '07

19 Oct '07

Issue 56: Focus is not given to correct window when switching virtual desktops http://code.google.com/p/xmonad/issues/detail?id=56 Comment #1 by SpencerJanssen: This is by design. We remember the current focus of each workspace -- the idea is that the user will want to continue working in the same window when returning to a workspace. In common window manager jargon, xmonad uses "sloppy focus" rather than strict "focus follows mouse". Focus is only changed when: - the user presses one of the navigation keys like mod-j - the user crosses the boundaries of a visible window from outside to inside with the mouse pointer - the user clicks the mouse button over an unfocused window Issue attribute updates: Status: WontFix -- 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

4 3

Issue 64 in xmonad: floating windows change size after being moved.
by codesite-noreply＠google.com 19 Oct '07

19 Oct '07

Issue 64: floating windows change size after being moved. http://code.google.com/p/xmonad/issues/detail?id=64 Comment #1 by byorgey: Additionally, when I open The Gimp (which automatically gets put in the floating layer via manageHook), one of the windows opens at a normal size but then immediately changes size continuously until it is extremely tall and skinny (only 1 icon wide). Attempting to resize this window works until I release the mouse button, at which point it jumps back to being tall and skinny. If I set borderWidth=0, this problem does not occur. -- 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 64 in xmonad: floating windows change size after being moved.
by codesite-noreply＠google.com 19 Oct '07

19 Oct '07

Issue 64: floating windows change size after being moved. http://code.google.com/p/xmonad/issues/detail?id=64 New issue report by byorgey: What steps will reproduce the problem? 1. Make sure borderWidth > 0. 2. Open a new window and pull it into the floating layer. 3. Resize or drag the window. What is the expected output? What do you see instead? The window appears to jump up and to the left and also shrink slightly. Experiments with the borderWidth indicate that the amount of movement/shrinking are determined by the borderWidth. What version of the product are you using? On what operating system? Bleeding-edge darcs, on GNU/Linux (Ubuntu feisty). 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