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>
 <CAKFCL4X3PnZU1OKfhko4RJGJNwaYT8VPawE4iEkQfT22_383ig@mail.gmail.com>
 <87y46adw0c.fsf@tullinup.koldfront.dk>
 <CAKFCL4Ww0nGxCJtXTmKs-oFeaydakM=f49OM3JWhbH5mchaNEA@mail.gmail.com>
 <87fusidstm.fsf@tullinup.koldfront.dk>
 <CAKFCL4XP0zzU7c97MyfXwh2Br6aVQVQYYcd8bC576VKq3pxN+A@mail.gmail.com>
 <87wpltjdqx.fsf@tullinup.koldfront.dk>
 <CAKFCL4UCERMqGwEH_4rk-0CEqyN1J_=HyO64RCsAoL1Ao45m=A@mail.gmail.com>
 <877fdrzbe9.fsf@tullinup.koldfront.dk>
 <CAKFCL4WmCR7VG4GJOohD8u97PRcn1_ETz8SPwUmahc3A5-oTvg@mail.gmail.com>
 <87y467xvxe.fsf@tullinup.koldfront.dk>
 <CAKFCL4XYDRHT+v5My0Qn37hoGs-oj1ipTSD_4cAeg5QVd1C=sQ@mail.gmail.com>
 <CAKFCL4W7y9_BnO81J2w2M02aWCmXfNXnowWSDvsgOFwPmD2Btw@mail.gmail.com>
 <CAKFCL4UJwqBCfg=4mZTSM9WjesY-_AO_=186fKZTmpMjBAWNNQ@mail.gmail.com>
 <87h9cvxtud.fsf@tullinup.koldfront.dk>
 <87d1njxsj9.fsf@tullinup.koldfront.dk>
 <CAF_c+NzToROErHadWRv7omtrh3SO6_W_PwcvUYW6B-Uz6-YN3Q@mail.gmail.com>
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>
 <CAF_c+Nx5HzXWYvp6kJPzeW8vKQ_wvBbmFcgS513pKf-J9JWefg@mail.gmail.com>
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>
 <CAF_c+Nx5HzXWYvp6kJPzeW8vKQ_wvBbmFcgS513pKf-J9JWefg@mail.gmail.com>
 <87mvjf5rw2.fsf@koldfront.dk>
Message-ID: <CAF_c+NxjXZ4hniMnXME5MqvEoDO1y-AP_c09X5K7=TqmXH6xjw@mail.gmail.com>

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 <asjo at koldfront.dk> 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: <http://mail.haskell.org/pipermail/xmonad/attachments/20160911/62de18eb/attachment.html>

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: <CAF_c+NxjXZ4hniMnXME5MqvEoDO1y-AP_c09X5K7=TqmXH6xjw@mail.gmail.com>
References: <8737oifhha.fsf@tullinup.koldfront.dk>
 <CAF_c+Nx5HzXWYvp6kJPzeW8vKQ_wvBbmFcgS513pKf-J9JWefg@mail.gmail.com>
 <87mvjf5rw2.fsf@koldfront.dk>
 <CAF_c+NxjXZ4hniMnXME5MqvEoDO1y-AP_c09X5K7=TqmXH6xjw@mail.gmail.com>
Message-ID: <CAKFCL4X5WNeWVbtM3v9TnTNj7FjuPHPKFhDN9Dg5y-RzNpQ=PQ@mail.gmail.com>

On Sun, Sep 11, 2016 at 7:11 PM, Daniel Wagner <dmwit at dmwit.com> 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: <http://mail.haskell.org/pipermail/xmonad/attachments/20160912/fc1fc965/attachment.html>

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>
 <CAF_c+Nx5HzXWYvp6kJPzeW8vKQ_wvBbmFcgS513pKf-J9JWefg@mail.gmail.com>
 <87mvjf5rw2.fsf@koldfront.dk>
 <CAF_c+NxjXZ4hniMnXME5MqvEoDO1y-AP_c09X5K7=TqmXH6xjw@mail.gmail.com>
 <CAKFCL4X5WNeWVbtM3v9TnTNj7FjuPHPKFhDN9Dg5y-RzNpQ=PQ@mail.gmail.com>
Message-ID: <874m5kwfzw.fsf@tullinup.koldfront.dk>

Brandon writes:

> On Sun, Sep 11, 2016 at 7:11 PM, Daniel Wagner <dmwit at dmwit.com> 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