- xmonad - Haskell.org

Issue 371 in xmonad: Program using popup menus can freeze the desktop
by codesite-noreply＠google.com 09 Feb '10

09 Feb '10

Status: New Owner: ---- New issue 371 by facundominguez: Program using popup menus can freeze the desktop http://code.google.com/p/xmonad/issues/detail?id=371 > What steps will reproduce the problem? 1. Compile and run the attached Java program. javac Grab.java java Grab > What is the expected output? What do you see instead? The expected output is that I should be able to use the other desktop applications while this application is running. What I see instead, is that none of the windows reacts to mouse clicks or keyboard events until the running java program is killed. > What version of the product are you using? On what operating system? I'm using xmonad 0.9.1 and java 1.6.0.12 Debian Lenny Linux 2.6.26-2-686 #1 SMP Sat Dec 26 09:01:51 UTC 2009 i686 GNU/Linux > Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". The output of "xmonad --recompile" is empty. Find attached xmonad.hs > Please provide any additional information below. This bug is very annoying when developing java applications that for any accidental bug freeze without closing all its open popup menus. Attachments: Grab.java 1.1 KB xmonad.hs 13.8 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 5

Re: Issue 310 in xmonad: XMonad.Main.handle eats WM_NAME property changes
by codesite-noreply＠google.com 07 Feb '10

07 Feb '10

Updates: Status: Accepted Labels: Type-Defect Component-Core Comment #1 on issue 310 by byorgey: XMonad.Main.handle eats WM_NAME property changes http://code.google.com/p/xmonad/issues/detail?id=310 I can reproduce this. Could a core developer take a look at this? If it is really as easy as amdragon suggests (and the suggested fix wouldn't be undesirable for other reasons), this ticket has no excuse for still being open. =) -- 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 2

darcs patch: Correct warnings with ghc-6.12 (and 1 more)
by Adam Vogt 07 Feb '10

07 Feb '10

Mon Jan 18 11:20:58 EST 2010 Adam Vogt <vogt.adam(a)gmail.com> * Correct warnings with ghc-6.12 Changes include: - compatibility with base-4 or 3 (base-2 untested) by using extensible-exceptions. This adds an additional dependency for users of ghc<6.10) - list all dependencies again when -ftesting (change in Cabal-1.8.0.2) - remove unnecessary imports - suppress -fwarn-unused-do-bind, with appropriate Cabal-1.8 workaround, described here: http://www.haskell.org/pipermail/xmonad/2010-January/009554.html Mon Jan 18 11:22:56 EST 2010 Adam Vogt <vogt.adam(a)gmail.com> * Rename numlockMask to numberlockMask to help users of the template config. Without the change, the errors are like: > [ unrelated error messages ] > No constructor has all these fields: `numlockMask', > `terminal', [every other field set] With the change: > `numlockMask' is not a record selector > [ context where numlockMask is named ]

4 5

xmobar add-ons
by Jose A. Ortega Ruiz 07 Feb '10

07 Feb '10

Hi, I hope i'm not off-topic. I'm posting here because i haven't been able to contact Andrea, xmobar's maintainer, and i thought some of you might be interested in a couple of add-ons to xmobar that i've been hacking on: - two new monitors, MultiCpu and Disk, providing cpu usage for multicores and disk I/O speeds, respectively. - new options to all monitors to set maximum/minimum field widths and padding characters. The code is available in this darcs repo: <http://darcs.hacks-galore.org/jao/xmobar> which you can also browse on-line at <http://darcs.hacks-galore.org/darcsweb/jao?r=xmobar;a=summary> The additions are documented in the README file. Since this is my first Haskell hacking beyond tutorial snippets, i'm sure the code can be improved, so feel free to criticise it as deserved, or to ask for other improvements. Thanks! jao -- Humans think they are smarter than dolphins because we build cars and buildings and start wars etc., and all that dolphins do is swim in the water, eat fish and play around. Dolphins believe that they are smarter for exactly the same reasons. -Douglas Adams

5 7

xmonad under ghc 6.12.1 -- progress
by Brent Yorgey 07 Feb '10

07 Feb '10

Hi all, I've been continuing to work on getting xmonad to build under ghc 6.12.1. We're almost there (I've attached a patch for xmonad-contrib; the core is a different story, read on). The main problem with building under 6.12.1 was that it generated three new sorts of warnings on the xmonad codebase (which was incompatible with our policy of using -Werror while testing, aside from simply being ugly). * Redundant imports. I've fixed all of these, see the attached patch. * Unused do binds. Per a previous discussion, this warning is silly so I've added a clause in the .cabal files to disable it for ghc >= 6.12.1. * Deprecated Prelude. xmonad currently requires base < 4 (because we're using the old exceptions framework) but this now generates a warning under ghc 6.12.1 that base-3 will soon be deprecated. For now, I've disabled this warning (unfortunately, this means all OTHER deprecation warnings are disabled too). Really we ought to update to use the extensible-exceptions package, which supposedly would provide a smooth migration path allowing xmonad to build under both base-3 and base-4. I'll let someone who knows more about exception stuff handle this. A couple problems I ran into along the way: * Cabal doesn't correctly order the flags to GHC in a certain situation (if you want to know details, see the recent thread "infelicitous (incorrect?) ordering of flags passed to GHC" on cabal-devel@haskell [1]). To get around this I had to do some minor silly hacks in the .cabal files, like this: if true ghc-flags: -Wall if impl (ghc >= 6.12.1) ghc-flags: -fno-warn-unused-do-bind and so on; putting the "ghc-flags: -Wall" by itself with no 'if true', which ought to be equivalent, does not work, since the flags get passed to ghc in the other order and the -Wall overrides the earlier -fno-warn... * As soon as I thought I was about to get the xmonad core to compile cleanly with no warnings... I got a GHC panic. Oh joy! I will keep looking into this. Hopefully by the time the platform comes out it will include some ghc 6.12.x where x > 1 and does not exhibit this bug. In the meantime, I have attached a patch which updates xmonad-contrib to compile cleanly under ghc 6.12.1. I also tested under ghc 6.10.4 with this patch applied, so as far as I know it shouldn't change or break anything. -Brent [1] http://www.haskell.org/pipermail/cabal-devel/2010-January/006004.html

3 3

Issue 369 in xmonad: Html5 video fullscreen window doesn't stay in fullscreen mode
by codesite-noreply＠google.com 06 Feb '10

06 Feb '10

Status: New Owner: ---- New issue 369 by mceier: Html5 video fullscreen window doesn't stay in fullscreen mode http://code.google.com/p/xmonad/issues/detail?id=369 What steps will reproduce the problem? 1. open http://diveintohtml5.org/video.html#movie in firefox 3.6 ( browser that supports html5 <video> tag ) 2. Do right mouse click on the movie and select fullscreen mode 3. What is the expected output? What do you see instead? Fullscreen window should stay in fullscreen mode and play video, but instead it is automatically closed after it is opened What version of the product are you using? On what operating system? xmonad 0.9.1 on gentoo Are you using an xmonad.hs? Please attach it and the output of "xmonad --recompile". yes "xmonad --recompile" outputs nothing. Please provide any additional information below. When myManageHook ( from default xmonad.hs ) is defined as follows: myManageHook = doFullFloat video works as expected ( it does not close automatically ), but every window is "full float" when myManageHook is: myManageHook = isFullscreen --> doFullFloat this fullscreen window closes automatically also tried : myManageHook = composeAll [ className =? "Toplevel" --> doFullFloat, isFullscreen --> doFullFloat ] it also didn't help. Attached xprop output ( run in awesome ). Flash fullscreen windows work as expected. Attachments: fs_prop.txt 9.8 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 8

Respecting the Window Manager Input Hint
by Bas van Dijk 03 Feb '10

03 Feb '10

Hello, I'm developing a scientific instrument which runs Gentoo Linux and uses Haskell for running the measurements. The device also uses XMonad for window management. Because the device has a touchscreen instead of a physical keyboard, I would like to use the the on-screen-keyboard: onboard [1]. The way onboard is supposed to work is that you move the focus to the window that needs input and then click on one of the onboard keys. Onboard will then generate an X11 event that will be send to the window that has focus. For correct operation, it's crucial that onboard does not get focus itself because then the key events will be send to itself! To prevent getting focus, onboard gives a hint to the window manager to not accept focus. $ xprop # (click on the onboard window) ... WM_HINTS(WM_HINTS): Client accepts input or input focus: False ... Unfortunately xmonad does not respect this hint by focusing the onboard window anyway when my pointer enters it. How can I prevent this? Possible solutions: * Use a manage hook that removes onboard from xmonad management so that it won't get focus anymore: className =? "Onboard" --> doIgnore While this solves my problem this has the disadvantage that the onboard window is not managed anymore. * Use XMonad.Layout.BoringWindows and the code in the recent thread on "focus handling". Unfortunately I didn't get this to work. (Maybe I have to put some more time into this) * Patch xmonad to respect the Window Manager Input Hint by not giving focus to windows that don't want't to get focus. How difficult would this be? regards, Bas [1] https://wiki.ubuntu.com/Accessibility/Projects/onBoard

2 3

Gaps between windows
by Damian 02 Feb '10

02 Feb '10

(or in winter I need some color...) Hello, I want to configure xmonad so that it leaves some amount of space between windows. Here is a mockup: http://yfrog.com/1glayoutiwantp The closest layout I could find is XMonad.Layout.Gaps, but it does not leave space between windows, it introduces a gap with regard to the screen. Any ideas about how to get this behaviour? Thanks in advance, Damian.

2 2

focus handling
by Alessandro Massignan 02 Feb '10

02 Feb '10

Hi all, i've a workspace for pidgin/skype and i wonder if their roster window should avoid focus switching (focusUp and focusDown) letting me to focus only the other windows (chats, options, ...). Is there a way to prevent a window being focused (eg. by classname, role, ...)? thanks to all, ff0000

3 3

make DynamicLog prefix workspace names with number
by Omari Norman 01 Feb '10

01 Feb '10

Hi, Is there any easy way to get DynamicLog to prefix the names of workspaces with numbers? For instance, I have workspaces named "web", "mail" and "local"; I want these to show up in my xmobar as "1:web", "2:mail", and "3:remote". Of course I would just name the workspaces that way, but I also use DynamicWorkspaces, which would make that tricky. Thanks! --Omari

3 4