August 2008 - xmonad - Haskell.org

Issue 209 in xmonad: Re-layouting when switching workspaces
by codesite-noreply＠google.com 31 Aug '08

31 Aug '08

Issue 209: Re-layouting when switching workspaces http://code.google.com/p/xmonad/issues/detail?id=209 Comment #2 by tommi.virtanen: This isn't about old workspace's layout. The bug is that it draws first the *unadjusted* new workspace layout, and then the *adjusted* new workspace layout. Remember the part about alt-l above.. It doesn't take that long but causes annoying flicker. -- 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 209 in xmonad: Re-layouting when switching workspaces
by codesite-noreply＠google.com 30 Aug '08

30 Aug '08

Issue 209: Re-layouting when switching workspaces http://code.google.com/p/xmonad/issues/detail?id=209 Comment #1 by Braden.Shepherdson: What's the time scale here? If this all happens in half a second, I don't think it's a bug. If it's an obvious, drawn out process of: * fully redraw under old workspace's layout * fully redraw under this workspace's layout that's quite visible, then maybe it is a bug. -- 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 209 in xmonad: Re-layouting when switching workspaces
by codesite-noreply＠google.com 30 Aug '08

30 Aug '08

Issue 209: Re-layouting when switching workspaces http://code.google.com/p/xmonad/issues/detail?id=209 New issue report by tommi.virtanen: What steps will reproduce the problem? 1. Open two workspaces (say alt-1, alt-2) with some windows (say Firefox, as the slow redraw makes the bug more apparent) 2. Adjust the layout in both (e.g. alt-l a few times) 3. Toggle between the workspaces (alt-1, alt-2) What is the expected output? What do you see instead? I expected the workspace switch to draw the layout in its adjusted form. Instead, I see a redraw of the unadjusted layout, immediately followed by the adjusted layout (alt-l). I'm using a ResizableTall 1 (6/100) (1/2) [] layout on both workspaces. What version of the product are you using? On what operating system? Ubuntu Hardy with xmonad 0.7-1~hardy1, rebuilt for Xinerama support. 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

Issue 208 in xmonad: Focus on mouse enter seems racy with Xinerama
by codesite-noreply＠google.com 29 Aug '08

29 Aug '08

Issue 208: Focus on mouse enter seems racy with Xinerama http://code.google.com/p/xmonad/issues/detail?id=208 New issue report by tommi.virtanen: I have a fullscreen mplayer playing on a second Xinerama head and miscellaneous windows open on the main screen. Both heads are using a ResizableTall layout. It seems that if I move the pointer quickly from the main screen to the screen with mplayer, focus stays where it was. I need to move the pointer back, and then move it over slower, to get the focus on mplayer. It seems reasonably hard to reproduce reliably, but has happened to me several times within this movie. It might be related to my main screen being 1680x1050, and the mplayer being 1280x800. The mplayer screen is above of the main screen, so there's an area on the right where the mouse can enter no mans land. However, even if I move the pointer there first, the bug is only reproducible with very fast movement. I'm running Ubuntu Hardy's xmonad 0.7-1~hardy1, recompiled to support Xinerama. 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

xmonad-light
by Braden Shepherdson 29 Aug '08

29 Aug '08

Gretings, everyone. Many people have probably seen my blog post[1] announcing xmonad-light. It discusses the reasoning behind splitting XMonad.Config.PlainConfig into a separate project, and its features both present and future. Don expressed some concern that too few eyes have seen the code, so I submit the darcs repo[2] for your consideration. Comments, criticism and patches are welcome (darcs send to this address). As I say in the blog post, one part I'm not happy about is the large amount of seeming duplication, all the cmd_* functions to build the XConfig, and the corresponding hcmd_* functions that output equivalent Haskell code. The other discussion is how to release xmonad-light. Depending on when 0.8 is to actually be released, should xmonad-light be released at the same time? Could it just be announced as coming soon, and not hold up the main release? I suspect that work on it (remembering that I'm packing this weekend, moving on Monday and starting a new job on Tuesday) can be completed within a week, to bring it to the point (modulo bugs) where it can be released to binary packages. The more eyes on the code between now and then, the better. As Joachim pointed out, most distro binary package maintainers would rather include the far more powerful xmonad-light binary than the unconfigurable xmonad base binary. Since xmonad-light cascades from xmonad.hs to xmonad.conf to default configuration, its behaviour sans config file(s) is precisely the same as the xmonad binary. So please, comments on the code, and discussion of when and how to release xmonad-light are welcome. To submit my own views on it, I don't want to rush xmonad-light. This is especially true in light of how busy I'm likely to be the next week. I think it best, therefore, to announce xmonad-light as a major feature alongside xmonad 0.8, noting that it will be released in September. I would be careful to make clear when announcing xmonad-light that it is not replacing Haskell configuration, but providing a new alternative aimed at new users. Braden Shepherdson shepheb [1] http://braincrater.wordpress.com/2008/08/28/announcing-xmonad-light/ [2] darcs get http://code.haskell.org/~shepheb/xmonad-light

1 0

Issue 207 in xmonad: DragPane bar gets painted over floating windows
by codesite-noreply＠google.com 28 Aug '08

28 Aug '08

Issue 207: DragPane bar gets painted over floating windows http://code.google.com/p/xmonad/issues/detail?id=207 Comment #1 by otto.seherol: this is an issue in XMonad-Contrib -- 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 207 in xmonad: DragPane bar gets painted over floating windows
by codesite-noreply＠google.com 28 Aug '08

28 Aug '08

Issue 207: DragPane bar gets painted over floating windows http://code.google.com/p/xmonad/issues/detail?id=207 New issue report by otto.seherol: What steps will reproduce the problem? 1. Have a workspace managed by the DragPane layout 2. Make a window floating 3. place the window over the bar of the DragPane What is the expected output? What do you see instead? I expect the black bar of the DragPane to be under the window. Instead, it gets painted over it What version of the product are you using? On what operating system? xmonad 0.7 (and xmonad-contrib 0.7) 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

Issue 206 in xmonad: Resizing with mouse, without leaving tiling mode
by codesite-noreply＠google.com 27 Aug '08

27 Aug '08

Issue 206: Resizing with mouse, without leaving tiling mode http://code.google.com/p/xmonad/issues/detail?id=206 New issue report by goo...(a)myref.net: it would be very nice to resize the windows in the tiling mode with the mouse so that it stays in tiling mode. if there are two windows, and i try to resize the left one, the other one should be also resized (left bigger, right smaller and vice versa). Also it should not be possible to resize the height in this scenario. 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

Issue 204 in xmonad: java console shows as entirely grey
by codesite-noreply＠google.com 26 Aug '08

26 Aug '08

Issue 204: java console shows as entirely grey http://code.google.com/p/xmonad/issues/detail?id=204 Comment #2 by brian.brunswick: Gah! Why is java always so broken? Sun seem to deliberately make everything about it duff, every API they make starts off wrong. I've added java console to the FAQ item title, at least. I can't get the WM naming fix to work for the java console, using ubuntu sun-java6-jre 6-06-0ubuntu1, which is supposedly late enough. I wonder how much effort it would be to get xmonad to reparent a window? Does anyone know of an external utility that reparents X windows? Is that even possible with the security model? -- 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 204 in xmonad: java console shows as entirely grey
by codesite-noreply＠google.com 26 Aug '08

26 Aug '08

Issue 204: java console shows as entirely grey http://code.google.com/p/xmonad/issues/detail?id=204 Comment #1 by allbery.b: http://xmonad.org/xmonad-docs/xmonad-contrib/XMonad-Hooks-SetWMName.html in short, Java is broken and has a hardcoded list of window managers for which it hacks around its own bugs; xmonad isn't in the list. -- 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