July 2009 - xmonad - Haskell.org

Issue 307 in xmonad: pidgin message windows change repeatedly grow on a multi-monitor setup
by codesite-noreply＠google.com 31 Jul '09

31 Jul '09

Comment #1 on issue 307 by daniel.spoonhower: pidgin message windows change repeatedly grow on a multi-monitor setup http://code.google.com/p/xmonad/issues/detail?id=307 This also occurs in my setup, but not just with Pidgin. It also with gnome-volume-control. Both are managed with doFloat. The ratio between the sizes of two instances of a given window is roughly the same as the ratio between my screens. A seemingly-related (but less intrusive behavior) also occurs with gnuplot: windows that appear on the larger screen are first rendered as if they appeared on the smaller screen (meaning that the plot only covers a portion of the window); the plot is then automatically scaled to fill the entire window. -- 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

Fwd: [xmonad] Unmarking modules 'Unstable' in contrib
by Braden Shepherdson 30 Jul '09

30 Jul '09

Resending to the list, sorry Brent for the duplicate. ---------- Forwarded message ---------- From: Braden Shepherdson <braden.shepherdson(a)gmail.com> Date: Thu, Jul 30, 2009 at 5:44 PM Subject: Re: [xmonad] Unmarking modules 'Unstable' in contrib To: Brent Yorgey <byorgey(a)seas.upenn.edu> Even when our modules do change, they almost always change in a backward-compatible way, since we try to avoid breaking configs. This sounds fine to me. Braden Shepherdson shepheb On Thu, Jul 30, 2009 at 5:12 PM, Brent Yorgey <byorgey(a)seas.upenn.edu>wrote: > On Wed, Jul 29, 2009 at 08:10:52PM -0400, Adam Vogt wrote: > > Hello, > > > > Most (152/159) modules are marked as unstable in contrib. A good number > of > > these 'unstable' modules have not been modified since a number of > releases. > > > > Here's a rough total number of modules with a last-modified date (per > year): > > > > > (for x in `find .`; do; (darcs changes $x | tail -n 2 | head -n 1); > done) > lastmod > > > for x in {2007,2008,2009}; do; grep $x lastmod | wc -l; done > > 64 > > 43 > > 17 > > > > I wouldn't trust those numbers, since the total falls short of 159, but > the > > point still stands: many so-called unstable modules have not changed in a > > long time, which could make it difficult for users to avoid modules that > > may actually change. > > > > Does anybody mind if I change the oldest modules (unchanged since 1.5 > > years) to be stable? > > Sounds good to me. I think most of the 'unstable' designations are > because of cargo-culting someone else's module comments. That and the > fact that by definition you would only change the stability > designation when you are not changing anything. No one ever thinks > "gee, it's been 6 months since I even thought about that module, > better go back and change it to 'stable'". =) > > -Brent > _______________________________________________ > xmonad mailing list > xmonad(a)haskell.org > http://www.haskell.org/mailman/listinfo/xmonad >

1 0

Issue 307 in xmonad: pidgin message windows change repeatedly grow on a multi-monitor setup
by codesite-noreply＠google.com 29 Jul '09

29 Jul '09

Status: New Owner: ---- New issue 307 by matt.fowles: pidgin message windows change repeatedly grow on a multi-monitor setup http://code.google.com/p/xmonad/issues/detail?id=307 Initial set up requires two monitors of different resolutions (call them "large" and "small") On "small monitor" 1. bring up the pidgin buddy list 2. double click a contact (this should bring up a message window in the floating layer) 3. give the message window focus and hit escape (this should dismiss the message window) 4. repeat steps 2-3 several times. Each time the message window should be the same size as it was before. Repeat everything on "large monitor". On my machine everything works correctly for the "small" case; however, each time I open the message window in the "large" case the window has grown from the last time it was opened. This leads to ever growing message windows (unless I resize them by hand, which is my current periodic work around). I am using: xmonad 0.8 ubuntu 9.04 Attachments: xmonad.hs 5.3 KB xmonad.recompile 0 bytes -- 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 306 in xmonad: Magnifier: keep magnified status if transient focused
by codesite-noreply＠google.com 27 Jul '09

27 Jul '09

Comment #2 on issue 306 by riccardo.murri: Magnifier: keep magnified status if transient focused http://code.google.com/p/xmonad/issues/detail?id=306 The idea of magnification independent from focus is interesting. However, I personally use "Magnifier" mostly for quick interactions with side windows in the tall layout (e.g., typing one command in a term, quick reply to IM) that are not worth bringing to the master area. So this actually requires magnified == focused. -- 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 306 in xmonad: Magnifier: keep magnified status if transient focused
by codesite-noreply＠google.com 27 Jul '09

27 Jul '09

Comment #1 on issue 306 by daniel.wagner: Magnifier: keep magnified status if transient focused http://code.google.com/p/xmonad/issues/detail?id=306 As a usage comment: it may be beneficial to have a separate layout modifier that simply magnifies windows indefinitely. That is, rather than having the magnification follow the focus, have it await a message (ToggleMagnifier or whatever it's called), then add the currently focused window to the list of windows that is magnified. It requires the addition of a bit of state to track which windows are magnified, but it would be closer to what I want, at least. Riccardo: would that match your usage pattern, or do you prefer the magnification to truly follow your focus (except to the floating layer)? -- 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 306 in xmonad: Magnifier: keep magnified status if transient focused
by codesite-noreply＠google.com 27 Jul '09

27 Jul '09

Status: New Owner: ---- New issue 306 by riccardo.murri: Magnifier: keep magnified status if transient focused http://code.google.com/p/xmonad/issues/detail?id=306 Reproduce: 1. work with layout:: magnifier' (Tall ....) 2. A window in the side track is focused and magnified 3. click on a button that makes a transient appear and be focused 4. the main window is un-magnified It would be a better user experience if the main window stays magnified when its transient are focused. Using xmonad 0.8 on Ubuntu 9.04: $ dpkg-query -l "*xmonad*" | grep ^ii ii libghc6-xmonad-contrib-dev 0.8-5ubuntu1 Extensions to xmonad ii libghc6-xmonad-contrib-doc 0.8-5ubuntu1 Extensions to xmonad; documentation ii libghc6-xmonad-dev 0.8-1 A lightweight X11 window manager ii libghc6-xmonad-doc 0.8-1 A lightweight X11 window manager; documentat ii xmonad 0.8-1 A lightweight X11 window manager -- 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

So Long, Farewell
by Kathryn Andersen 27 Jul '09

27 Jul '09

XMonad folks... Just in case anyone wants feedback about why people may or may not choose to use XMonad, I thought I'd give some. I'm moving away from XMonad and back to the window manager I keep coming back to: Fvwm. This isn't because I hate XMonad, XMonad is cool. But I miss my eye-candy, and I miss the ability to move and resize floating windows with just the mouse (rather than mouse+key). I remember seeing a post here saying that there were two models for interacting with a window manager: (1) keyboard alone and (2) mouse and keyboard. But there's also mouse-alone. Sometimes one wishes to have a hand free, to drink a cuppa, eat a sandwich, whatever. Or one is using a laptop where "mouse" (touchpad) use requres two hands, one for the touchpad and the other for the buttons. XMonad doesn't support that. Then I found that it was easier to write a tiling module for Fvwm than to write eye-candy for XMonad. Part of that is because I'm familiar with Perl and I haven't (yet) learned enough about Haskell. Fvwm's modular design plus its Perl bindings enabled me to have somewhere to start, while I didn't know where to start with XMonad. Also, altering the decorations of XMonad seems to be a more daunting, low-level task than adding tiling behaviour to Fvwm. After beavering away for a few weeks, I've got my Fvwm tiling module working well enough, and so I no longer need to use XMonad. So, farewell. It's been fun, and I wish y'all well. Kathryn Andersen -- _--_|\ | Kathryn Andersen <http://www.katspace.org> / \ | \_.--.*/ | GenFicCrit mailing list <http://www.katspace.org/gen_fic_crit/> v | ------------| Melbourne -> Victoria -> Australia -> Southern Hemisphere Maranatha! | -> Earth -> Sol -> Milky Way Galaxy -> Universe

5 5

Issue 19 in xmonad: Investigate a way to allow contrib extensions to use compositing.
by codesite-noreply＠google.com 27 Jul '09

27 Jul '09

Comment #17 on issue 19 by amdragon: Investigate a way to allow contrib extensions to use compositing. http://code.google.com/p/xmonad/issues/detail?id=19 > The advantage of handleEventHook is that you also receive events that > would otherwise > be handled by xmonad. Ah, that makes sense. I suppose it doesn't help much in the compositing case because I don't think those messages are caught by xmonad, but I can see it being useful for other things. > I don't know what you mean by actions not having a way to receive Events I didn't mean to say it was impossible to receive Events from actions, just difficult. From a user's perspective, all you want to do is bind the action to a key and be done with it. But this doesn't work. 1) Instead of implementing your action as an action, you can implement it as a layout modifier (ala XMonad.Hooks.EventHook). Now your action is a layout, which is weird, and the user has to both bind the action to a key and, for some mysterious reason, wrap their layout hook. 2) Using handleEventHook, you can implement your action as an action, plus an event hook. If you're handling events you almost certainly also need state, which means you also need something to create the IORef. Now the user has to "create" the action, bind it to a key, /and/ modify their handleEventHook. 3) You can have your own event loop (ala XMonad.Prompt). Now your action is just an action and the user can just bind it to a key like they wanted, but you don't play well with others. At best, you delay messages, which could be bad if its a damage or timer event aimed at another event handler trying to do compositing or animation. At worst you eat them. Ever noticed what happens to XMonad.Layout.Decoration's that are under an XMonad.Prompt or its completions window? The prompt eats expose events, so the title bars get wiped out and stay wiped out after the prompt closes. Again, imagine if you were eating damage or timer events. Anyways. This is mostly intended as food for thought: things that are going to come up if/when someone starts working on compositing. -- 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

minor doc correction (patch, eom)
by wagnerdm＠seas.upenn.edu 27 Jul '09

27 Jul '09

1 1

xmonad, dzen, pipeline issues
by Matthew 26 Jul '09

26 Jul '09

I am trying to make dzen play nicely with xmonad and have run into a number of unpleasant issues. I tried to set up dzen according to this webpage, http://tombuntu.com/index.php/2009/03/19/adding-a-dzen2-statusbar-to-xmonad/ That more or less works, however I want to run a second dzen process so that I can view a clock and perhaps create a button or two for some other tasks. Initially my xmonad startup shell script (called via xsessions) looked like this: #!/bin/sh xmonad-clock | dzen2 -ta left -fg green -tw 500 -e "button1=exec:xterm" & xmonad | dzen2 -ta center where xmonad-clock writes out the time periodically (every 5 seconds or so). The button was just an attempt to play around with dzen. Unfortunately this doesn't work, the clock never gets displayed. If I run that command from a bash shell, after xmodem has launched, it works fine. I finally ended up putting the clock command piped to dzen (2nd line above) in .xinitrc. This approach does display the clock but the button doesn't work. All of these approaches have the additional annoying problem that when I try to quit xmonad via alt-shift-q, xmonad essentally hangs, or more likely it quits leaving no windows manager and no way to do anything but reboot. I have to make sure that dzen and xmonad-clock have been killed prior to quitting xmonad. I am running xmonad on a 64 bit build of arch-linux. What is causing this behavior, and is there any way I can get dzen or multiple copies of dzen to behave the way I want? I think I need at least two copies since the clock has to be updated periodically, wheras the output piped to dzen from xmonad is only sent during state updates.

4 5