- xmonad - Haskell.org

darcs patch: NamedWindows: removed getClassHint that is the cause o...
by Andrea Rossato 12 Jul '07

12 Jul '07

Hi, this patch soft of fixes the crash issue. It removes the work aroung I proposed for non latin window's names: using the reasourse name provided by getClassHint. This one is causing the problem. So, we need to fix this first. To XMonad core team: I don't know if this patch must be applied: probably it can be used by Tabbed users till when getClassHint is fixed. I don't know... you see! Ciao Andrea who's going to have some breackfast now Thu Jul 12 07:47:52 CEST 2007 Andrea Rossato <andrea.rossato(a)unibz.it> * NamedWindows: removed getClassHint that is the cause of some crashing My work around for non latin string in WindowNames requires getClassHint that is, so far, buggy. For the time being we will not have non latin names in tabs. But at least the Tabbed layout is not going to crash XMonad.

4 5

darcs patch: added support for XChangeWindowAttributes
by Andrea Rossato 11 Jul '07

11 Jul '07

Hi, Since I cannot stand C anymore this is the needed support to rewrite the last Robert's stuff. The rest is comming as soon as possible. Maybe my firt XMonad module... ;-) ciao andrea Wed Jul 11 09:58:44 CEST 2007 Andrea Rossato <andrea.rossato(a)unibz.it> * added support for XChangeWindowAttributes

2 1

darcs patch: restore focus to currently focused window after "float...
by Jason Creighton 11 Jul '07

11 Jul '07

Mon Jul 9 22:26:31 MDT 2007 Jason Creighton <jcreigh(a)gmail.com> * restore focus to currently focused window after "float" (closes #32)

2 1

turn any window into a statusbar or manage/unmage windows 'remotely'
by Robert Manea 11 Jul '07

11 Jul '07

Hi, as the question: 'How can I make xmonad ignore application "foo" and have it appear on every workspace?' is kind of a FAQ in xmonad's IRC channel, i wrote a tiny application just for this purpose. Source is attached below, usage is trivial: - retreive the window ID of the application you want to unmanage/manage with 'xwininfo' - invoke the program below, like: * unmanage <windowid> * manage <windowid> Compilation und usage instructions are in the code.. Have fun, Rob.

2 1

[ot] [xmobar-related] existentials for plugin-ing (?)
by Andrea Rossato 10 Jul '07

10 Jul '07

Hi, I had this crazy idea a couple of nights ago. I didn't dare to ask in the haskell-cafe because I fear it could be too stupid. The xmonad community is smaller (even though the greatest haskeller I know about read and write xmonad code: so posting here could be even worse...;-) so I'm posting here. It is vaguely related to XMonad after all. XMobar, the status bar I'm writing for XMonad, now runs monitors internally. You set monitors and external commands in the configuration file. I'm thinking of writing also command line options, but the possibility of using a readable data type for reading a configuration file can make users' life easier, I think, even though there are no debugging messages and that can be confusing (but you can test the configuration with ghc!). Now, in the configuration there is this commands option, a list of tuples: the data type for commands and an Int, the interval for each successive runs. The data type for the commands was suggested by Spencer. Very simply: data Command = Exec ProgramName Args | Network Interface Args etc., where Network is a constructor to be used for running the network interface monitor. Then there is a class (Exec - not much fantasy, I know) for which a method (run :: e -> IO String) must be defined. So there are all the needed instances for running, showing, etc, etc. Now, I though that writing a plugin should just mean creating a type and making it an instance of Exec. XMobar takes the list of the commands to be run from the configuration "commands" option, so that's easy: just a polymorphic list of commands to be run and I don't need anything else for supporting plugins...;-) Cool I though, it's just a matter of creating the needed polymorphic list. With one more constrain: Config, that has that list inside, must be readable! Ok, this is not an easy task, since existentially qualified types are not derivable, and reading them seemed not even possible.[1] Writing a too complicated parser for a Read instance is not an option. Now, thanks to the help of Claus Reinke I came up with a solution for that too.[2] The code[3] works! You can feed readConfig with a file like this: MD {rec1 = "Ciao", rec2 = "Ciao Ciao", rec3 = [MT (T3a,1),MT (T2b,3),MT (T1b,3),MT (T1a,3)]} and it reads it! Now I would like to ask you if such an approach could be tried or is just insane. I mean, would you run a status bar that, to configure with you favorite plugin (type HelloWorld = HelloWorld [] []), requires you to write in Config.hs something like: hidden = undefined :: (Commands,(HelloWorld,())) I don't know if I would. Let me know your thoughts please, in exchange I'll chase and try to fix as many XMobar bugs as I possibly can ...;-) All the best Andrea [1] According to this thread: http://www.haskell.org/pipermail/haskell-cafe/2004-April/006092.html [2] Look here: http://www.haskell.org/pipermail/haskell-cafe/2007-July/028205.html http://www.haskell.org/pipermail/haskell-cafe/2007-July/028227.html [3] the code {-# OPTIONS -fglasgow-exts #-} module Test where import Control.Monad import Text.Read import Text.ParserCombinators.ReadPrec data MyData = MD { rec1 :: String , rec2 :: String , rec3 :: [MyType] } deriving (Read,Show) data MyType = forall e . (MyClass e,Show e, Read e) => MT (e,Int) instance Show MyType where show (MT a) = "MT " ++ show a class MyClass c where myShow :: c -> String data TipoA = T1a | T2a | T3a deriving(Show,Read,Eq) instance MyClass TipoA where myShow T1a = "t1a" myShow T2a = "t2a" myShow T3a = "t3a" data TipoB = T1b | T2b | T3b deriving(Show,Read,Eq) instance MyClass TipoB where myShow T1b = "t1b" myShow T2b = "t2b" myShow T3b = "t3b" -- tricky part starts here -- the solution comes from Claus Reinke class ReadAsAnyOf ts ex where -- read an existential as any of hidden types ts readAsAnyOf :: ts -> ReadPrec ex instance ReadAsAnyOf () ex where readAsAnyOf ~() = mzero instance (Read t, Show t, MyClass t, ReadAsAnyOf ts MyType) => ReadAsAnyOf (t,ts) MyType where readAsAnyOf ~(t,ts) = r t `mplus` readAsAnyOf ts where r t = do { m <- readPrec; return (MT (m `asTypeOf` (t,0))) } instance Read MyType where readPrec = readMT readMT :: ReadPrec MyType readMT = prec 10 $ do Ident "MT" <- lexP parens $ readAsAnyOf hidden -- r T1a `mplus` r T1b hidden = undefined :: (TipoA,(TipoB,())) readConfig :: FilePath -> IO MyData readConfig f = do s <- readFile f case reads s of [(config,_)] -> return config [] -> error ("Corrupt config file: " ++ f) _ -> error ("Some problem occured. Aborting...")

1 0

Issue 34 in xmonad: focusedBorderColor does not follow focus that is requested by application
by codesite-noreply＠google.com 10 Jul '07

10 Jul '07

Issue 34: focusedBorderColor does not follow focus that is requested by application http://code.google.com/p/xmonad/issues/detail?id=34 New issue report by JinXiaoyong: What steps will reproduce the problem? 1. (server-start) in GNU Emacs and leave the mouse pointer in Emacs 2. use emacsclient in an xterm 3. Emacs will acquire the focus, but the border color is still normal What is the expected output? What do you see instead? Of course the border color should have changed to focusedBorderColor, but it didn't, though emacs did obtain the focus. What version of the product are you using? On what operating system? xmonad from darcs repository. Emacs unicode-branch-2 from cvs. Gentoo Linux. Xorg 7.2.0 Please provide any additional information below. Other applications that acquire focus by themselves could possibly have the same issue. In my case, for the Emacs, it's important that the mouse pointer was in the Emacs window while you run the emacsclient in the xterm. 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 32 in xmonad: gnome-panel take focus when autohide
by codesite-noreply＠google.com 10 Jul '07

10 Jul '07

Issue 32: gnome-panel take focus when autohide http://code.google.com/p/xmonad/issues/detail?id=32 Comment #2 by jcreigh: Hmm. The reason the reason we focusWindow first is so that we can shift it to the right workspace. (Currently, "shift" can only move the focused window.) Not quite sure how we should fix this yet. Issue attribute updates: Status: Accepted -- 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

mod-{w,e,r} don't work when OpenOffice.org has focus
by Kai Grossjohann 10 Jul '07

10 Jul '07

I have two heads, the left one shows workspace 1 which is in full layout and contains OpenOffice, Firefox and Adobe Reader. The right head shows different workspaces as time goes by, usually in tiled layout. Now it turns out that OpenOffice somehow grabs focus so that mod-e does not work to switch to the second head. I can still do mod-j to switch to a different client on the left head, and then mod-e works. But when OpenOffice has focus and after I click into it, then mod-e will not work to set the focus to the right hand head. Has anyone else observed the same? Is there a fix? What can I do to help debug it? (I don't grok Haskell, though I'm trying.) Kai

2 3

darcs patch: LayoutScreens.hs: correct module header. (and 1 more)
by joachim.fasting＠gmail.com 09 Jul '07

09 Jul '07

Sun Jul 1 23:57:12 CEST 2007 joachim.fasting(a)gmail.com * LayoutScreens.hs: correct module header. Sat Jul 7 23:28:36 CEST 2007 joachim.fasting(a)gmail.com * Spiral.hs: correct module header.

2 1

darcs patch: add FlexibleResize to MetaModule
by l.mai＠web.de 09 Jul '07

09 Jul '07

Sun Jul 8 15:02:29 CEST 2007 l.mai(a)web.de * add FlexibleResize to MetaModule

2 1