- xmonad - Haskell.org

Recompiling on reinstallation
by Gwern Branwen 01 May '09

01 May '09

Don today in #xmonad linked http://braindump.dk/tech/2009/05/01/xmonad-upgrade/ The problem seems to be that the custom xmonad binary was not being recompiled even when XMonad was upgraded/reinstalled. Fortunately, I had seen a Yi technique which asked Cabal for the installed binary's patch; then it could get the last-modified times of the installed binary & the custom binary, and force a recompile if the former was newer than the latter. I coded this up for xmonad-core, but whenever I try it out, I get link errors. This is not the first time I've seen such errors, so I do not know whether my patch is flawed or my setup. If anyone wants to try it themselves and perhaps fix it, I'm attaching it. The changes: hunk ./XMonad/Core.hs 55 +import System.FilePath.Posix ((</>)) hunk ./XMonad/Core.hs 60 +import Paths_xmonad (getBinDir) + hunk ./XMonad/Core.hs 399 +-- * the installed xmonad executable is more recent than the custom xmonad +-- hunk ./XMonad/Core.hs 408 --- hunk ./XMonad/Core.hs 411 + cabalBinDir <- getBinDir + let cabalBin = cabalBinDir </> "xmonad" + cabalBinT <- getModTime cabalBin hunk ./XMonad/Core.hs 421 - if (force || srcT > binT) + if (force || srcT > binT || cabalBinT > binT) hunk ./XMonad/Main.hsc 43 + + hunk ./XMonad/Main.hsc 124 - + -- have recompile check for a stale custom binary + recompile False hunk ./xmonad.cabal 44 - build-depends: base < 4 && >=3, containers, directory, process + build-depends: base < 4 && >=3, containers, directory, process, filepath -- gwern

1 0

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 30 Apr '09

30 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 29 Apr '09

29 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 29 Apr '09

29 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