From asjo at koldfront.dk Sat Sep 3 21:44:43 2016 From: asjo at koldfront.dk (Adam =?utf-8?Q?Sj=C3=B8gren?=) Date: Sat, 03 Sep 2016 23:44:43 +0200 Subject: [xmonad] kill -STOP/-CONT hack References: <87io0udym0.fsf@tullinup.koldfront.dk> <87y46adw0c.fsf@tullinup.koldfront.dk> <87fusidstm.fsf@tullinup.koldfront.dk> <87wpltjdqx.fsf@tullinup.koldfront.dk> <877fdrzbe9.fsf@tullinup.koldfront.dk> <87y467xvxe.fsf@tullinup.koldfront.dk> <87h9cvxtud.fsf@tullinup.koldfront.dk> <87d1njxsj9.fsf@tullinup.koldfront.dk> Message-ID: <87twdwvet0.fsf@tullinup.koldfront.dk> Daniel writes: > If you can turn this change into a clean, one-commit pull request against > xmonad/xmonad-contrib, I'll happily merge it. Done now (still learning the whole pull request game): · https://github.com/xmonad/xmonad-contrib/pull/81 Best regards, Adam -- "Where there's a will, there's a won't" Adam Sjøgren asjo at koldfront.dk From asjo at koldfront.dk Sat Sep 10 22:09:17 2016 From: asjo at koldfront.dk (Adam =?utf-8?Q?Sj=C3=B8gren?=) Date: Sun, 11 Sep 2016 00:09:17 +0200 Subject: [xmonad] Catching exceptions from getWindowAttributes References: <8737oifhha.fsf@tullinup.koldfront.dk> Message-ID: <87mvjf5rw2.fsf@koldfront.dk> Daniel writes: > The simplest thing will be to wrap just the call to `getWindowAttributes`, > if that's the one you expect to fail. It is one I observe failing, yes. > It is not conveniently possible to wrap `X` actions; so instead, > something like > > withDisplay $ \d -> do > ws <- gets windowset > ewa <- io $ try (getWindowAttributes d w) > case ewa of > Left e -> io (putStrLn "HELP! do something!") > Right wa -> do > let bw = (fromIntegral . wa_border_width) wa > {- ... etc. -} I can't make this construction compile, when I try to change floatLocation to use it, I get errors about a return value being of type X () instead of X (ScreenId, W.RationalRect). Best regards, Adam -- "Alla för alla, en för en Adam Sjøgren Alla för alla, en för en asjo at koldfront.dk Så börjar vi om igen" From dmwit at dmwit.com Sun Sep 11 23:11:01 2016 From: dmwit at dmwit.com (Daniel Wagner) Date: Sun, 11 Sep 2016 16:11:01 -0700 Subject: [xmonad] Catching exceptions from getWindowAttributes In-Reply-To: <87mvjf5rw2.fsf@koldfront.dk> References: <8737oifhha.fsf@tullinup.koldfront.dk> <87mvjf5rw2.fsf@koldfront.dk> Message-ID: I suppose the question that this error is asking you is: when `getWindowAttributes` throws an error, how should `floatLocation` respond? Perhaps returning some default -- like `(0, RationalRect 0 0 1 1)` or something -- will be sufficient? I don't know how `floatLocation` gets used, so I don't know how dangerous a default that would be. Do we need to change the type of `floatLocation` to admit that it may not know the right answer? ~d On Sat, Sep 10, 2016 at 3:09 PM, Adam Sjøgren wrote: > Daniel writes: > > > The simplest thing will be to wrap just the call to > `getWindowAttributes`, > > if that's the one you expect to fail. > > It is one I observe failing, yes. > > > It is not conveniently possible to wrap `X` actions; so instead, > > something like > > > > withDisplay $ \d -> do > > ws <- gets windowset > > ewa <- io $ try (getWindowAttributes d w) > > case ewa of > > Left e -> io (putStrLn "HELP! do something!") > > Right wa -> do > > let bw = (fromIntegral . wa_border_width) wa > > {- ... etc. -} > > I can't make this construction compile, when I try to change > floatLocation to use it, I get errors about a return value being of type > X () instead of X (ScreenId, W.RationalRect). > > > Best regards, > > Adam > > -- > "Alla för alla, en för en Adam Sjøgren > Alla för alla, en för en asjo at koldfront.dk > Så börjar vi om igen" > > _______________________________________________ > xmonad mailing list > xmonad at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/xmonad > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Mon Sep 12 04:15:25 2016 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 12 Sep 2016 00:15:25 -0400 Subject: [xmonad] Catching exceptions from getWindowAttributes In-Reply-To: References: <8737oifhha.fsf@tullinup.koldfront.dk> <87mvjf5rw2.fsf@koldfront.dk> Message-ID: On Sun, Sep 11, 2016 at 7:11 PM, Daniel Wagner wrote: > I suppose the question that this error is asking you is: when > `getWindowAttributes` throws an error, how should `floatLocation` respond? > I am not sure I understand wjy getWindowAttributes would throw an exception except for "window removed", and for most of those you probably want to be aborting the hook in question. So, make sure it's always under control of userCode; this would include moving the one in X.O.manage into a userCode, but that would probably be smart anyway since I think we crash currently if the new window we want to manage goes away before we can. Or both its uses (one to manage initial windows at startup and one in response to MapRequestEvent). -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From asjo at koldfront.dk Tue Sep 13 05:00:51 2016 From: asjo at koldfront.dk (Adam =?utf-8?Q?Sj=C3=B8gren?=) Date: Tue, 13 Sep 2016 07:00:51 +0200 Subject: [xmonad] Catching exceptions from getWindowAttributes References: <8737oifhha.fsf@tullinup.koldfront.dk> <87mvjf5rw2.fsf@koldfront.dk> Message-ID: <874m5kwfzw.fsf@tullinup.koldfront.dk> Brandon writes: > On Sun, Sep 11, 2016 at 7:11 PM, Daniel Wagner wrote: >> I suppose the question that this error is asking you is: when >> `getWindowAttributes` throws an error, how should `floatLocation` >> respond? Yeah, and I don't really know enough to answer that question either. I guess something is really wrong with the window, and XMonad should give up? > I am not sure I understand wjy getWindowAttributes would throw an > exception except for "window removed", That could very well be it, I usually see the exceptions from getWindowAttributes in floatLocation when Gimp opens windows that display some kind of progress and quickly closes them again. > and for most of those you probably want to be aborting the hook in > question. So, make sure it's always under control of userCode; this > would include moving the one in X.O.manage into a userCode, but that > would probably be smart anyway since I think we crash currently if the > new window we want to manage goes away before we can. Or both its uses > (one to manage initial windows at startup and one in response to > MapRequestEvent). Yes. Uhm. Ah. I haven't got the foggiest of how to do any of that. Best regards, Adam -- "Good evening. Today is Good Friday. There is no news." Adam Sjøgren asjo at koldfront.dk