April 2009 - xmonad - Haskell.org

Issue 290 in xmonad: Windows are no longer visible but are still there
by codesite-noreply＠google.com 30 Apr '09

30 Apr '09

Comment #4 on issue 290 by SpencerJanssen: Windows are no longer visible but are still there http://code.google.com/p/xmonad/issues/detail?id=290 > I'm using xmonad (conf attached) with xcompmgr This is most likely an xcompmgr or graphics driver bug. To be sure, reproduce the invisible window issue, then execute 'killall -9 xcompmgr'. If the window reappears, the bug is not in xmonad. -- 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

cannot build XMonadContrib
by Sergey Manucharian 30 Apr '09

30 Apr '09

Hello list, I've switched to xmonad from xfce a couple of months ago and found it perfect WM! Today I've decided to compile both xmonad and XMonadContrib from darcs. Since I don't have experience compiling haskell programs I can't go further after the following error: XMonad/Util/Run.hs:134:8: Not in scope: `uninstallSignalHandlers' Could somebody help me, please? I've tried to google already without success... TIA, Sergey

2 2

Issue 290 in xmonad: Windows are no longer visible but are still there
by codesite-noreply＠google.com 29 Apr '09

29 Apr '09

Comment #3 on issue 290 by vogt.adam: Windows are no longer visible but are still there http://code.google.com/p/xmonad/issues/detail?id=290 A similar result happens when you kill a window when xmonad is recompiling/restarting. Before xmonad was changed to recompile in the background (post-0.8.1) you could have enough time to kill a window while it was recompiling, and xmonad would still leave space for the window because the dead window would be added to the StackSet from the serialized state. Are there borders drawn for the 'invisible' window (if yes, then ignore my suggestion, since none are drawn for elements in the WindowSet that do not refer to an actual 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

Issue 290 in xmonad: Windows are no longer visible but are still there
by codesite-noreply＠google.com 29 Apr '09

29 Apr '09

Comment #2 on issue 290 by allbery.b: Windows are no longer visible but are still there http://code.google.com/p/xmonad/issues/detail?id=290 xmonad itself doesn't change anything at all about window contents (possibly barring the border), so I'd have to go with the FadeInactive extension. Note that tweaking an application's windows that way when it's not expecting it is technically illegal and practically liable to trigger odd window update behavior. Also note that windows that go around the standard X11 mechanisms (this can happen with v4l and hardware OpenGL, among others) may behave really oddly with FadeInactive. -- 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 290 in xmonad: Windows are no longer visible but are still there
by codesite-noreply＠google.com 29 Apr '09

29 Apr '09

Comment #1 on issue 290 by stefano.zacchiroli: Windows are no longer visible but are still there http://code.google.com/p/xmonad/issues/detail?id=290 Here is my configuration file. Attachments: xmonad.hs 1.9 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 290 in xmonad: Windows are no longer visible but are still there
by codesite-noreply＠google.com 29 Apr '09

29 Apr '09

Status: New Owner: nomeata Labels: Type-Defect Usability New issue 290 by nomeata: Windows are no longer visible but are still there http://code.google.com/p/xmonad/issues/detail?id=290 This is a bug that was reported by Stefano Zacchiroli via http://bugs.debian.org/526106: ========================== Package: xmonad Version: 0.8.1-3 Severity: important I've been observing this phenomenon for a while, but unfortunately it is not deterministic. I'm using xmonad (conf attached) with xcompmgr and gnome, xmonad is run from the gnome-session mechanism. From time to time, a single window decide to "disappear" in the sense that it no longer shows its content, showing rather what is below (usually the background). The window, however, is still there and is affected by the usual window actions: resizing, workspace switch, layout change, ... It is just that is completely useless as it is invisible. The only "solution" is close the window and re-open it (if the application permits that). FWIW, I experience a similar (but not quite the same) phenomenon sometimes when switching from one window to the other. The one I switched from disappear, to reappear when it got focused again. That makes me believe that the bug might be related to the FadeInactive extension that I'm using. If this is the case, the bug should possibly be reassigned to libghc6-xmonad-contrib-dev. Still, I do not consider an acceptable behaviour for the main window manager to permit this kind of situations. ========================== The mentioned attached logfile was missing from the mail. I’ll ask Zack to add it here. -- 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

Illegal Signature in SubLayouts module with ghc 6.8
by rupa 28 Apr '09

28 Apr '09

When trying to compile xmonad latest darcs under ghc 6.8.2dfsg1-1ubuntu1 (jaunty default) I got the following error: XMonad/Layout/SubLayouts.hs:309:16: Illegal signature in pattern: LayoutMessages Use -XPatternSignatures to permit it Apparently people using 6.10 do not get this error, which went away when I added PatternSignatures to the LANGUAGE pragmas of the modules as suggested in IRC. Just a heads up, I'm not sure what, if anything, should be done here ...

3 4

[patch] Fix for two typos
by Alexey Khudyakov 28 Apr '09

28 Apr '09

Hello. This patch fixes two typos in comments. It seems that copy-paste is quite respected in this community (-:

4 3

OO.o won't open, Dialogs and GIMP won't float/tile right
by Dayo Adewunmi 28 Apr '09

28 Apr '09

Hi guys. I love Xmonad. Installed it on my Ubuntu 8.10 laptop a couple of days ago for the first time, so I'm still a newbie. I managed to add Xmobar, by following the installation instructions from here: http://code.haskell.org/~arossato/xmobar/#installation and using the config example from here: http://haskell.org/haskellwiki/Xmonad/Config_archive/John_Goerzen's_Configuration#Configuring_xmonad_to_use_xmobar My modifier is Alt, so I press Alt+p to start apps from the grey menu bar that appears at the top of the screen, and so far the only one that won't start is OpenOffice3. Also, I have to start GIMP 2.6 in a dedicated workspace, because it just won't tile correctly with other open apps. Dialog prompts like "SaveAs" and "Open" of various apps don't float right either, leaving the "Save", "Open", "Cancel" buttons hanging out of sight below the visible line of the screen. Also pressing Alt+Enter is said to switch the active frame with the frame in the Master pane, but this stopped working after some editing of xmonad.hs (or .xmobarrc?). Unfortunately, I can't remember what changes I made that caused Alt+Enter to stop working. Here are my specs and configs: ~/.xmonad/xmonad.hs: http://pastebin.com/f5e107f70 ~/.xmobarrc: http://pastebin.com/febe32b4 Ubuntu 8.10 Intrepid Ibex Linux 2.6.27-11-generic #1 SMP Wed Apr 1 20:57:48 UTC 2009 i686 GNU/Linux Regards Dayo

2 3

FR: Workspace cursors
by Russell Adams 28 Apr '09

28 Apr '09

Here's another idea that had been tossed around on IRC, a list of workspace "cursors". This was born from a discussion regarding Enlightenment virtual desktops, and on further inspection it turns out that simulating a cursor was the real feature. When maintaining a large list of workspaces, navigating between them is an issue. Having a list of pointers or cursors that could be accessed quickly (single keypress bound) or linearly (next/prev cursor) would be useful to "jump" between tasks. The idea would be that given an array of cursors, the current cursor is constantly updated with the current workspace. Changing to another cursor jumps to its last known location and it becomes the new current cursor. Here's a quick sketch in perlesque pseudo-code: my @cursors = [ "1", "1", "1", "1", "1", "1", "1", "1", "1", "1", ]; my $currentCursor=0; add post-workspace change hook, or attach the code to the planer keybindings used to change workspaces: $cursors[$currentCursor]=getCurrentWorkspace(); goto-next-cursor: if $currentCursor < 9 then $currentCursor++; setWorkspace($cursors[$currentCursor]); goto-prev-cursor: if $currentCursor > 1 then $currentCursor--; setWorkspace($cursors[$currentCursor]); You could get fancy and change the array boundchecking to use the length of the array, or make it a ring and just loop (nice idea). Comments? ------------------------------------------------------------------ Russell Adams RLAdams(a)AdamsInfoServ.com PGP Key ID: 0x1160DCB3 http://www.adamsinfoserv.com/ Fingerprint: 1723 D8CA 4280 1EC9 557F 66E8 1154 E018 1160 DCB3

3 2