Re: Possible regression (full crash of X)

On Mon, May 29, 2017 at 02:56:47PM +0000 I heard the voice of
Yumekui Neru, and lo! it spake thus:
> 
> I have no idea what it would imply in the context of
> window-managers, but the graphical mode that I used was "borderless"
> rather than fullscreen, so maybe filling the screen might not have
> been the best words to use.

Well, I'm assuming it involves the EWMH STATE_FULLSCREEN, which does
the equivalent of ctwm's f.fullscreenzoom.


> Commenting out the iconified-line, I was able to do 10 successful
> launches in a row without reproducing the issue  (out of the 10 I
> tried). When I added the line back, it happened on the first attempt
> (on commit e5ea26e).

Interesting.

Well, I've been able to reproduce _something_.  I'm not _entirely_
sure it's the same hole you're falling into, but it seems pretty
similar (and, really, if there are TWO similar nasty bugs like this
hiding around, I quit).  It's not strictly due to StartIconified, but
it seems like that might be a way to trigger it.

The problem I'm seeing has to do with trickiness of focus handling,
and how that affects where the window gets placed.  EWMH specifies
things about "_FULLSCREEN + focused", so the window should be winding
up in different places when it's focused vs. not.  Due to various
nastiness about ctwm and X and especially the intersection between
them, that's getting out of sync, which is causing the mis-stacking.

It may take me a few days to get the time to really nail it down; I'll
have to see how ClickToFocus interacts etc., to be sure I'm not fixing
one thing and breaking another.


-- 
Matthew Fuller     (MF4839)   |  [email protected]
Systems/Network Administrator |  http://www.over-yonder.net/~fullermd/
           On the Internet, nobody can hear you scream.