- xmonad - Haskell.org

Issue 177 in xmonad: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol
by codesite-noreply＠google.com 14 Apr '08

14 Apr '08

Issue 177: xmonad does not follow ICCCM and ignores WM_TAKE_FOCUS protocol http://code.google.com/p/xmonad/issues/detail?id=177 New issue report by Ivan.Tarasov: What steps will reproduce the problem? 1. run any Java application (use JDK1.6u1 or higher and xmonad with SetWMName extension to overcome the gray rectangle bug). E.g. run Notepad demo from demo/jfc/Stylepad directory in JDK home, like so: java -jar $JDK_LOCATION/demo/jfc/Stylepad/Stylepad.jar 2. After starting the window doesn't get focus (that's a first example of the problem) 3. click inside the window, so it gets focus. If it is a Stylepad application, you'd be able to enter text in the editor window 4. Switch to another window on the same workspace, either using keys, or mouse 5. Switch back 6. Although the frame around the Java app becomes highlighted (meaning xmonad thinks it has the focus), Java app doesn't seem to get the focus (you cannot edit the text or open menus in Stylepad until you click with your mouse into the window) What is the expected output? What do you see instead? Java application should get the focus after switching back to its window from another window. What version of the product are you using? On what operating system? xmonad 0.7 + latest patches from the repository Debian GNU/Linux, 2.6.24-3 Please provide any additional information below. I've done an investigation together with Java AWT engineers and we've found that this is a problem in xmonad, not in Java. The problem is that xmonad ignores the WM_TAKE_FOCUS protocol which is described in the ICCCM (see http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7) Java sets <Globally Active> model for its Frames/Dialogs, and <No Input> model for its Windows. In both of these cases the WM shouldn't call XSetInputFocus by itself. In the former case it should send the WM_TAKE_FOCUS event to the window (when it decides that the toplevel window should get the focus), in the latter case it shouldn't do anything (Java processes all the clicks by itself). See also the attached C file. You can compile it using the following command: gcc -o native -I/usr/X11R6/include -L/usr/X11R6/lib -lX11 native.c When run, this file file prints the FocusIn/FocusOut events and also it prints WM_TAKE_FOCUS events if they are sent. The correct behaviour of this program in the WM is to print the message "event on frame %i: WM_TAKE_FOCUS" (where %i is the number of frame, 0 or 1 in this program) whenever the focus is set to its window using the WM (either using keys, or mouse). Incorrect behaviour is when it prints only pairs of the "FocusIn"/"FocusOut" messages. I tried reproducing the same problem in IceWM and found that it handles the WM_TAKE_FOCUS protocol correctly (both on this test program and on real applications). I attempted to fix the problem myself but for some reason the fix didn't work. See the attached Operations.hs file which contains the fix attempt starting with the line -------- WM_TAKE_FOCUS fix attempt starts here -------- If you have any questions or need any further clarification from the Java AWT engineers, please contact me at Ivan.Tarasov(a)gmail.com. I consider this problem as "quite serious" (on some abstract seriousness scale), because it ruins the xmonad using experience as well as Java application using experience when they are used together. Attachments: native.c 2.5 KB Operations.hs 22.1 KB 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: A better solution for choosing whether the tabbar shou...
by ivan.miljenovic＠gmail.com 13 Apr '08

13 Apr '08

Fri Apr 11 22:58:04 EST 2008 Ivan.Miljenovic(a)gmail.com * A better solution for choosing whether the tabbar should always be visible. Instead of the previous patch I sent, this patch alters the datatypes used so that the layouts in Tabbed take in a Bool parameter that sets whether or not the tabbar should always be shown. simpleTabbed and simpleTabbedBottom remain unchanged. arossato's, droundy's and sjanssen's configs have been updated to reflect these changes.

5 7

Allow xmonad to get input from spawned applications
by Ivan Miljenovic 13 Apr '08

13 Apr '08

I wanted to try and get a pop-up message shown on a key-press showing the current mpd information. Preferably, I'd like to keep everything inside xmonad rather than relying on external scripts. Now, I could have something like "mpc | head -1 | dzen"... but I wanted to use something like notify-send (part of libnotify) to do so, as its less obtrusive and handles non-Latin characters better (i.e. using fontconfig, etc.). However, since notify-send doesn't seem to want to take piped inputs, I'd first have to read and parse the mpc data before I could call notify-send. This would work well... if only xmonad let me read data from the processes it spawns. As such, I think there should be a new operation that lets you obtain the stdout output from the programs that are spawned... something like "spawnOutput :: String -> m String". Is such a thing feasible/possible/good? I _could_ just have a seperate bash script to do this, but I'd like it to have my settings as self-contained as possible. -- Ivan Lazar Miljenovic

2 2

Issue 176 in xmonad: Transient windows pop up with wrong size on second screen
by codesite-noreply＠google.com 12 Apr '08

12 Apr '08

Issue 176: Transient windows pop up with wrong size on second screen http://code.google.com/p/xmonad/issues/detail?id=176 New issue report by lithis7: What steps will reproduce the problem? 1. Have a dual-head setup with screens of different resolution. 2. Run OpenOffice.org on the second screen. 3. Choose Help | About. What is the expected output? What do you see instead? The About dialog box should appear as a floating window of the proper size. Instead, the size is wrong by the ratio of the size of the first screen to the size of the second screen. For example, I have a 1280x1024 screen 0 and a 1280x720 screen 1. The About box appears with the proper width, but it is not tall enough. What version of the product are you using? On what operating system? xmonad darcs on Ubuntu Gutsy. Please provide any additional information below. This issue started after romreim's recent float patch, but I'm not asking for that patch to be reverted: I prefer this issue to the pre-patch behavior. A similar effect occurs when a moving a floating window between screens with the keyboard (floating windows change size when they change screens). That behavior has bothered me for a while. Floats do not change size when moved with the mouse. 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

Adding some more configs to XMonad.Config (XMC)
by Gwern Branwen 12 Apr '08

12 Apr '08

So, anyway. It's been quite a while since any configurations were added into XMonad/Config. We still have only Arossato.hs, Dons.hs, Droundy.hs, & Sjanssen.hs. But since those were really written, a huge number of features and modules've been added to XMC. As I recall, two of the justifications for retaining an XMonad.Config.* in the first place (instead of just moving all of them to the hawiki) were that 1) They served a valuable role testing out the libraries and modules - typechecking, imports, names of functions and types, and so on - when they got compiled. 2) They were examples, offline documentation that would get included in the source distribution, or at the very least made available as part of the library. Not everyone can go to the wiki or even knows about it, after all. I think that by both reasons we need to add some more configs. Per #1, there are large swathes of features not even touched by the compiled configs, and similarly per #2. Another 3 or 4 configs would be a good addition. Now, what configs should we pick? I think we need at least two areas exercised: internalization, and using docks and monitors like dzen2 or xmobar. I'm not really familiar with configs big on those areas. I do have a few suggestions, though. I like: * <http://haskell.org/haskellwiki/Xmonad/Config_archive/oxymor00n's_xmonad.hs> for its length * <http://haskell.org/haskellwiki/Xmonad/Config_archive/andrewsw's_xmonad.hs> for being a relatively simple xmobar example, or <http://haskell.org/haskellwiki/Xmonad/Config_archive/lithis's_xmonad.hs> * <http://haskell.org/haskellwiki/Xmonad/Config_archive/Wfarr's_xmonad.hs> dzen in this case, or <http://haskell.org/haskellwiki/Xmonad/Config_archive/Robert_Manea's_xmonad.hs> * <http://haskell.org/haskellwiki/Xmonad/Config_archive/Brent_Yorgey's_xmonad.hs> This one is interesting for all the programming going on in it, but I'm not sure it's the best example - I suspect he's redoing some of the XMC modules. Thoughts? -- gwern

1 0

Problems with magic Focus
by Nathan Huesken 11 Apr '08

11 Apr '08

Hi, I am trying to make the magic focus extension work. This is from my xmonaf.hs: myLayout = magicFocus tiled ||| layoutHints mtiled ||| Full where mtiled = Mirror tiled -- default tiling algorithm partitions the screen into two panes tiled = Tall nmaster delta ratio -- The default number of windows in the master pane nmaster = 1 -- Default proportion of screen occupied by master pane ratio = 1/2 -- Percent of screen to increment by when resizing panes delta = 3/100 This gives me the following error on startup: xmonad.hs:205:11: Not in scope: `magicFocus' I am using xmonad 0.6 on gentoo. Any advice? Thanks! nathan

2 1

FlexibleResize not flexible enough
by Joachim Breitner 11 Apr '08

11 Apr '08

Hi, I was trying to use FlexibleResize so that I divide the window in 3×3 parts, where the middle part only moves, the edge parts only resize in that direction and the corner parts resize both directions. At first I thought I could hack that up if I modify the functions from (Double -> Double) to (Pnt -> Pnt), where Pnt=(Double,Double) as used in the module, and I was in the middle of preparing the patch when I noticed that this does not work either, as I can not specify "ignore this direction" (as needed for the edge cases). I can try to experiment with a function of type ((Double, Double) -> (Maybe Double, Maybe Double)) to enable the user to specify this and everything supported before, but it looks a bit too complicated for what this user-exposed API was meant for. Comments? Greetings, Joachim -- Joachim Breitner e-Mail: mail(a)joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nomeata(a)joachim-breitner.de

1 0

darcs patch: Fix window order in EWMH
by Joachim Breitner 11 Apr '08

11 Apr '08

Hi, this patch is an improvement, but I’d like to know if there is an even better way to get a list of all windows, so that for the windows on the current screen, they are in bottom-to-top stacking order. Thanks, Joachim Fri Apr 11 15:44:11 CEST 2008 Joachim Breitner <mail(a)joachim-breitner.de> * Fix window order in EWMH For pagers to draw the stacking order correctly, the focused window has to be the last in the list. Thus put an appropriate implementation of allWindows into the Module. This does not work perfectly with floating windows.

2 1

ANNOUNCE: xmonad 0.7 released
by Don Stewart 11 Apr '08

11 Apr '08

http://xmonad.org The xmonad dev team is pleased to announce xmonad 0.7! The headlines: The 0.7 release of xmonad provides several improvements over 0.6, including improved integration with GNOME, more flexible "rules", various stability fixes, and of course, many new and interesting features in the extension library (general support for window decorations, utf8 support, scratch pad terminals, pointer control) and more! New GNOME support: Active, automated support for GNOME utilities. We know our users often like to use GNOME menus, tools and status bars, and we'd like to announce that xmonad actively supports GNOME! Extensions for communicating with and utilising gnome utilities come in the library suite, as well as extensive documentation and support. For more information see the GNOME/xmonad integration page on the wiki. A period of active development: In the past year, the xmonad development team received contributions from over 60 developers, making xmonad one of the largest window manager development teams around, and dwarfing other tiling window manager projects. Yet, at the same time, the core code base remains at around 1000 lines of code, with another 7000 lines in the extension library -- a significant achievment! Change logs: http://haskell.org/haskellwiki/Xmonad/Notable_changes_since_0.6 http://xmonad.org/changelog-0.7.txt http://xmonad.org/changelog-xmc-0.7.txt About: xmonad is a tiling window manager for X. Windows are arranged automatically to tile the screen without gaps or overlap, maximising screen use. Window manager features are accessible from the keyboard: a mouse is optional. xmonad is extensible in Haskell, allowing for powerful customisation. Custom layout algorithms, key bindings and other extensions may be written by the user in config files. Layouts are applied dynamically, and different layouts may be used on each workspace. Xinerama is fully supported, allowing windows to be tiled on several physical screens. Features: * Very stable, fast, small and simple. * Automatic window tiling and management * First class keyboard support: a mouse is unnecessary * Full support for tiling windows on multi-head displays * Full support for floating, tabbing and decorated windows * Full support for Gnome and KDE utilities * XRandR support to rotate, add or remove monitors * Per-workspace layout algorithms * Per-screens custom status bars * Compositing support * Powerful, stable customisation and reconfiguration * Large extension library * Excellent, extensive documentation * Large, active development team, support and community Get it! Information, screenshots, documentation, tutorials and community resources are available from the xmonad home page: http://xmonad.org The 0.7 release, and its dependencies, are available from hackage.haskell.org: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad xmonad packages are available in the package systems of at least: Debian, Gentoo, Arch, Ubuntu, OpenBSD, NetBSD, FreeBSD, Gobo, NixOS, Source Mage, Slackware and 0.7 packages will appear in coming days (some are already available). On the fly updating to xmonad 0.7 is supported. You should be able to upgrade to xmonad 0.7 from 0.6 and earlier, transparently, without losing your session. Load the new code with mod-q and enjoy. Extensions: xmonad comes with a huge library of extensions (now more than 7 times the size of xmonad itself), contributed by viewers like you. Extensions enable pretty much arbitrary window manager behaviour to be implemented by users, in Haskell, in the config files. For more information on using and writing extensions see the webpage. The library of extensions is available from hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/xmonad-contrib Full documentation for using and writing your own extensions: http://xmonad.org/contrib.html This release brought to you by the xmonad dev team: Spencer Janssen Don Stewart Jason Creighton David Roundy Brent Yorgey Devin Mullins Braden Shepherdson Roman Cheplyaka Lucas Mai Featuring code contributions from over 60 developers: Aaron Denney Adam Vogt Alec Berryman Alex Tarkovsky Alexandre Buisse Andrea Rossato Austin Seipp Bas van Dijk Ben Voui Brandon Allbery Chris Mears Christian Thiemann Clemens Fruhwirth Daniel Neri Daniel Wagner Dave Harrison David Glasser David Lazar Dmitry Kurochkin Dominik Bruhn Dougal Stanton Eric Mertens Ferenc Wagner Gwern Branwen Hans Philipp Annen Ivan Tarasov Jamie Webb Jeremy Apthorp Joachim Breitner Joachim Fasting Joe Thornber Joel Suovaniemi Juraj Hercek Justin Bogner Kai Grossjohann Karsten Schoelzel Klaus Weidner Mathias Stearn Mats Jansborg Matsuyama Tomohiro Michael Fellinger Michael Sloan Miikka Koskinen Neil Mitchell Nelson Elhage Nick Burlett Nicolas Pouillard Nils Anders Danielsson Peter De Wachter Robert Marlow Sam Hughes Shachaf Ben-Kiki Shae Erisson Simon Peyton Jones Stefan O'Rear Tom Rauchenwald Valery V. Vorotyntsev Will Farrington Yaakov Nemoy timthelion As well as the support of many others on the #xmonad and #haskell IRC channels, and the wider Haskell and window manager communities. Thanks to everyone for their support!

4 7

Added WM_WINDOW_ROLE support in WindowProperties
by Roman Cheplyaka 11 Apr '08

11 Apr '08

With help of sphynx I've added WM_WINDOW_ROLE support in WindowProperties. This means that IM layout can now handle even more instant messengers, including skype, pidgin (ex-gaim) and gajim. Enjoy! -- Roman I. Cheplyaka (aka Feuerbach @ IRC)

2 1