June 2009 - xmonad - Haskell.org

Re: [xmonad] Problem with Emacs and XMonad
by Bruce Stephens 09 Jun '09

09 Jun '09

Deniz Dogan <deniz.a.m.dogan(a)gmail.com> writes: [...] > Even when merging .Xdefaults it doesn't work. Are you by any chance > using emacsclient? Because this only seems to happen with the first > frame opened with normal Emacs. Any additional frames in the same > Emacs instances behave correctly. I am (I think the -daemon flag is one of the nicest improvements). I also noticed I had some face setting in .emacs, but I removed that and ran emacs-snapshot, and the font is indeed liberation mono (and presumably the size I specified---it looks fine). In my .Xdefaults I've got this: Emacs*FontBackend: xft,x emacs-snapshot.font: liberation mono-9 (The executable is called emacs-snapshot. I also use Emacs 22, with the name "emacs", so I want to be able to configure that too. I think it ignores the FontBackend resource.)

1 0

Issue 261 in xmonad: Fullscreen flash movie fails
by codesite-noreply＠google.com 09 Jun '09

09 Jun '09

Comment #8 on issue 261 by alexander.fairley: Fullscreen flash movie fails http://code.google.com/p/xmonad/issues/detail?id=261 Here's how you can work around this: 1) Get into a layout mode where the focus or primary window is fullscreen. 2) Press the fullscreen button. Enjoy the daily show. -- 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

2 1

run a program when switching to a workspace
by Sergey Manucharian 08 Jun '09

08 Jun '09

Hi folks, How can I configure xmonad to run a program when switching to a particular workspace? Example: I want to run a script changing the keyboard layout to "us" unconditionally when I'm on particular workspaces (with ssh, rdesktop etc.). Thanks! Sergey

7 17

Working emacs minibuffer frame
by Jonas Bernoulli 08 Jun '09

08 Jun '09

Hi I have started using Xmonad and learning Haskell two days ago and the first thing I did was to try to get the Emacs minibuffer frame to show up at the bottom of each workspace. And I succeeded - but it's not perfect yet. I have read this [1] thread, which helped to get started. After searching the Emacs C part for quite a while for the right place to implement the minibuffer strut I came across x-change-window-property which lets you do it from Emacs Lisp, like so: ;; Create the minibuffer frame. (setq default-minibuffer-frame (make-frame '((minibuffer . only)))) ;; Make the minibuffer frame a strut at the bottom. ;; See http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html#id2523368 ;; Second argument has the form: ;; (left_width right_width top_height bottom_height ;; left_start_y left_end_y right_start_y right_end_y ;; top_start_x top_end_x bottom_start_x bottom_end_x) (x-change-window-property "_NET_WM_STRUT_PARTIAL" '(0 0 0 34 0 0 0 0 0 0 0 2559) default-minibuffer-frame "CARDINAL" 32 t) ;; Make all other frames use the default minibuffer frame. (modify-all-frames-parameters '((minibuffer . nil))) That does not work however. Xmonad does correctly reserve space for the strut but the minibuffer frame is still tilted. The EWMH spec states [2] that window managers MUST watch for property notify events if the Window Manager uses [the _NET_WM_STRUT_PARTIAL] property to assign special semantics to the window. Xmonad does that partially. The minibuffer window (frame) changes this property after it was created and Xmonad correctly reserves space for the window but fails to move the window to the correct location and resize it accordingly. (It also does not remove the border but this is not required by EWMH.) Their are basically two ways to fix this: 1. Make Xmonad follow the EWMH spec more closely, or 2. Edit Emacs C code to set the property before the window is drawn. I do not know enough about Xmonad and Haskell yet to do (1) just now. And C isn't my strength either but I could probably do it by copying code from dzen and adapting it to the needs of Emacs. But since it would probably take a while for such a patch to get into Emacs, and (1) is the better solution anyway I think that should be preferred. Well I just started learning Haskell so this will take a while, so I would welcome it if someone else did it. Until then here is a workaround: In ~/.xmonad/xmonad.hs import XMonad.Hooks.ManageDocks import XMonad.Actions.DeManage myKeys conf@(XConfig {XMonad.modMask = modMask}) = M.fromList $ [ ((modMask, xK_y ), withFocused demanage) ...] main = do xmonad $ defaultConfig { manageHook = manageDocks <+> manageHook defaultConfig <+> composeAll [ title =? "EmacsMinibuffer" --> doFloat ] ...} In ~/.emacs.d/init.el (setq default-minibuffer-frame (make-frame '((minibuffer . only) ; t might also be in nice ;; If omitted title defaults to " *Minibuf-0*" ;; but Xmonad does not seam to like that. (title . "EmacsMinibuffer") ;; Position the window manually. (left . 0) ; in pixels (top . 1566) ; in pixels (width . 282) ; in characters (height . 2)))) ; in text lines (x-change-window-property "_NET_WM_STRUT_PARTIAL" '(0 0 0 34 0 0 0 0 0 0 0 2559) default-minibuffer-frame "CARDINAL" 32 t) (modify-all-frames-parameters '((minibuffer . nil))) Then you have to select the minibuffer frame and press modKey-y. And of course you would have to change the numbers above to accommodate your setup. (The Emacs lisp code above could be extended to figure it out on it's own, something I might do when I find time.) Even though Xmonad does not everything required to support the strut property being set after some window was created, it is still better to use x-change-window-property to set strut because the alternative of using something like: import XMonad.Layout.Gaps myLayout = gaps [ (D,32) ] $ Grid ||| Full is not so good. When Emacs is closed the space reserved for the minibuffer frame is not made available again. With the strut approach it is. I can live with the current state, but will investigate ways to improve it once I have time. But again, people knowing more about Haskell and Xmonad are very welcome to take it from here. Best regards Jonas Ps. As much as Drew's libraries usually work out-of-the-box, oneonone.el [3] just blew up in my face when used with Xmonad and a dark background (these are unrelated, but oneonone sucks equally at both). Pps. I plan to write a xmonad.el to implement some of OneOnOne idea and then some more optimized for Xmonad. Like automatically determine size and location of the minibuffer frame and a dedicated *Completions* frame and strut sidebar ... . Of course this will be much easier once Xmonad fully supports changes to _NET_WM_STRUT_PARTIAL. Pps. Emacs could even be used wherever dzen, xmobar, dmenu and similar apps are currently are used. Wouldn't that be great! [1] http://www.haskell.org/pipermail/xmonad/2009-May/007854.html [2] http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html#id2523368 [3] http://www.emacswiki.org/emacs/OneOnOneEmacs

3 2

Issue 297 in xmonad: gnomeConfig does not fully support the Gnome workspace switcher applet
by codesite-noreply＠google.com 05 Jun '09

05 Jun '09

Updates: Status: Invalid Comment #3 on issue 297 by byorgey: gnomeConfig does not fully support the Gnome workspace switcher applet http://code.google.com/p/xmonad/issues/detail?id=297 gnomeConfig already includes ewmhDesktopsLogHook in the logHook. If you use gnomeConfig but then set the logHook yourself (as in the attached xmonad-base.hs) it will simply override whatever is in the gnomeConfig. Hence ewmhDesktopsLogHook would not be in your logHook anymore unless you explicitly include it (as you have done), or more generally include the gnomeConfig logHook by doing something like , logHook = logHook gnomeConfig >> whatever logHook stuff you want Marking this issue as invalid, although feel free to reopen if I've misunderstood the problem. -- 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 297 in xmonad: gnomeConfig does not fully support the Gnome workspace switcher applet
by codesite-noreply＠google.com 05 Jun '09

05 Jun '09

Comment #2 on issue 297 by john.yates.sheets: gnomeConfig does not fully support the Gnome workspace switcher applet http://code.google.com/p/xmonad/issues/detail?id=297 Indeed. Retrying. Attachments: xmonad-base.hs 2.4 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

Issue 299 in xmonad: Unable to start openoffice presentation
by codesite-noreply＠google.com 05 Jun '09

05 Jun '09

Status: New Owner: ---- New issue 299 by joehealy: Unable to start openoffice presentation http://code.google.com/p/xmonad/issues/detail?id=299 What steps will reproduce the problem? 1. Start xmonad with xinerama 2. Open a oo impress presentation 3. Press f5 or the menu/button to start a presentation What is the expected output? What do you see instead? The expected output is for the presentation to either take over the screen or atleast open a new window with the presentation contents. Instead, nothing happens. The screen remains unchanged. What version of the product are you using? On what operating system? xmonad 0.8.1, on ubuntu 9.04, but this problem also occured with 8.10 openoffice is 3.0 Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". xmonad --recompile has no output. Please provide any additional information below. Attachments: xmonad.hs 1.1 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

colourful xterms
by Anze Slosar 05 Jun '09

05 Jun '09

Hi, A couple of days a made a trivial hack that made me very happy, so I want to share the trick here. The trick is to start rxvt-unicode with -bg \\#`randcolor.py` -fg \\#EEEEEE where randcolor is a simple python script that returns a random hex color with rgb random in range(0..100) (to be dark enough for white font): #!/usr/bin/env python from random import * rs=["%X"%(int(uniform(0,100))) for x in range(3)] s='' for x in rs: while len(x)<2: x="0"+x s+=x print s The outcome is that every term you start has slightly different shade of background. This not only makes your screen much more colourful and nice, but also helps with 0 or 1 pixel borders as terminals now clearly separate into areas on the screen of different colors so it is actually very useful! Best, anže phone: +1 (510) 495 2488, mobile: +1 (510) 289 9395, fax: +1 (510) 486 7149 -- "Speaking as a Jew on Christmas, I would be less shocked if Santa Claus showed up to my house than if Bernie Madoff pulled off this fraud alone." [Ron Geffner]

7 8

Issue 298 in xmonad: ResizableTall layout crashes application when window height set to minimum
by codesite-noreply＠google.com 04 Jun '09

04 Jun '09

Updates: Status: Fixed Comment #4 on issue 298 by byorgey: ResizableTall layout crashes application when window height set to minimum http://code.google.com/p/xmonad/issues/detail?id=298 Okay, I can reproduce this with gnome-terminal. But with xterm and urxvt the window is simply resized to be larger than the screen, so it seems like mostly a bug in gnome-terminal. But as a workaround I've pushed a patch to cap the window resizing at the height of the screen (which doesn't really hurt anything) which seems to fix the problem. -- 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 298 in xmonad: ResizableTall layout crashes application when window height set to minimum
by codesite-noreply＠google.com 04 Jun '09

04 Jun '09

Comment #3 on issue 298 by mysteriousentity: ResizableTall layout crashes application when window height set to minimum http://code.google.com/p/xmonad/issues/detail?id=298 When I try the same thing with xterm the terminals do not crash, instead the xterm being enlarged is resized off the screen, ie window becomes larger than screen and part of it is not visible. -- 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