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.
