Re: Beta snapshot
On Fri, Dec 30, 2022 at 04:19:37AM +0100 I heard the voice of Carl Svensson, and lo! it spake thus: > > On another note, when doing a "make" followed by "sudo make install" I get > the following message: > > CMake Warning at cmake_install.cmake:104 (message): > No manpage to install: recheck config if this is unexpected. > > Is this expected for the beta snapshot? Turns out to be my fault, some testing bits from a couple years ago accidentally snuck their way into being committed in the install code. -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: Beta snapshot
So far "my" crash has not re-occurred. I enabled the address sanitizer and the undefined behavior sanitizer. The latter triggered only on a single left-shift of an "occupation" bit (once). At exit, there are some memory leaks, but nothing big. But I did notice a colormap was involved, which may be related to the crash somehow. The reports related to atexit are false-positives (well they are true, but hidden in a library and there is nothing you can do about it). Parsing the config file seems leaky. GetHints() is involved in several leaks. But I only seem to see "static" leaks, that don't re-occur over time. Nothing that re-occurs for every window, or something like that. Here is the full report: /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/ewmh.c:1529:10: runtime error: left shift of 1073741824 by 1 places cannot be represented in type 'int' = ==827==ERROR: LeakSanitizer: detected memory leaks Direct leak of 1272 byte(s) in 1 object(s) allocated from: #0 0x7a2c4c825f2c in __interceptor_realloc /usr/src/external/gpl3/gcc/dist/libsanitizer/asan/asan_malloc_linux.cc:80 #1 0x7a2c490ab205 in _reallocarr /usr/src/lib/libc/stdlib/reallocarr.c:85 #2 0x621014ff () Direct leak of 1041 byte(s) in 120 object(s) allocated from: #0 0x7a2c4c8487e6 in strdup /usr/src/external/gpl3/gcc/dist/libsanitizer/asan/asan_interceptors.cc:565 #1 0x59ffeb in yyparse /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/gram.y:1119 #2 0x50aa36 in twmrc_error_prefix /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/parse.c:298 #3 0x50a8d2 in ParseTwmrc /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/parse.c:260 #4 0x50a436 in LoadTwmrc /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/parse.c:180 #5 0x42ecf3 in ctwm_main /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/ctwm_main.c:593 #6 0x407149 in main /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/ctwm_wrap.c:6 #7 0x40705c in ___start (/mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/./build/ctwm+0x40705c) Direct leak of 64 byte(s) in 1 object(s) allocated from: #0 0x7a2c4c825bb8 in malloc /usr/src/external/gpl3/gcc/dist/libsanitizer/asan/asan_malloc_linux.cc:67 #1 0x7a2c49e09dd4 in xpmParseDataAndCreate /usr/xsrc/external/mit/libXpm/dist/src/create.c:2113 Direct leak of 56 byte(s) in 1 object(s) allocated from: #0 0x7a2c4c825d61 in calloc /usr/src/external/gpl3/gcc/dist/libsanitizer/asan/asan_malloc_linux.cc:75 #1 0x7a2c4ae2ffb5 in XGetWMHints /usr/xsrc/external/mit/libX11/dist/src/GetHints.c:131 Direct leak of 32 byte(s) in 1 object(s) allocated from: #0 0x7a2c4c825bb8 in malloc /usr/src/external/gpl3/gcc/dist/libsanitizer/asan/asan_malloc_linux.cc:67 #1 0x7a2c49143e47 in atexit_handler_alloc /usr/src/lib/libc/stdlib/atexit.c:112 #2 0x7a2c49143e47 in __cxa_atexit_internal /usr/src/lib/libc/stdlib/atexit.c:158 Direct leak of 8 byte(s) in 1 object(s) allocated from: #0 0x7a2c4c825bb8 in malloc /usr/src/external/gpl3/gcc/dist/libsanitizer/asan/asan_malloc_linux.cc:67 #1 0x428805 in FetchWmColormapWindows /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/colormaps.c:407 #2 0x408168 in AddWindow /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/add_window.c:207 #3 0x4560a3 in HandleMapRequest /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/event_handlers.c:1931 #4 0x440bdb in DispatchEvent /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/event_core.c:335 #5 0x43fff4 in HandleEvents /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/event_core.c:197 #6 0x4331ed in ctwm_main /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/ctwm_main.c:1058 #7 0x407149 in main /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/ctwm_wrap.c:6 #8 0x40705c in ___start (/mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/./build/ctwm+0x40705c) Direct leak of 6 byte(s) in 1 object(s) allocated from: #0 0x7a2c4c825bb8 in malloc /usr/src/external/gpl3/gcc/dist/libsanitizer/asan/asan_malloc_linux.cc:67 #1 0x7a2c4ae303c7 in XGetClassHint /usr/xsrc/external/mit/libX11/dist/src/GetHints.c:319 Direct leak of 6 byte(s) in 1 object(s) allocated from: #0 0x7a2c4c825bb8 in malloc /usr/src/external/gpl3/gcc/dist/libsanitizer/asan/asan_malloc_linux.cc:67 #1 0x7a2c4ae30407 in XGetClassHint /usr/xsrc/external/mit/libX11/dist/src/GetHints.c:326 Indirect leak of 128 byte(s) in 4 object(s) allocated from: #0 0x7a2c4c825bb8 in malloc /usr/src/external/gpl3/gcc/dist/libsanitizer/asan/asan_malloc_linux.cc:67 #1 0x7a2c49143e47 in atexit_handler_alloc /usr/src/lib/libc/stdlib/atexit.c:112 #2 0x7a2c49143e47 in __cxa_atexit_internal /usr/src/lib/libc/stdlib/atexit.c:158 Indirect leak of 40 byte(s) in 1 object(s) allocated from: #0 0x7a2c4c825bb8 in malloc /usr/src/external/gpl3/gcc/dist/libsanitizer/asan/asan_malloc_linux.cc:67 #1 0x4267b6 in UninstallRootColormap /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/colormaps.c:214 #2 0x426f81 in CreateColormapWindow /mnt/vol1/rhialto/c
Re: Beta snapshot
> a) roughly what you said above; use Layout instead of BorderedLayout >for strutty windows. That's broken and wrong, but it's at least >consistent with how 4.0.3 would have been wrong. I've gone ahead and implemented this variant of the workaround for the strutted windows issue, and made a new snapshot with the fix. https://www.ctwm.org/tmp/ctwm-4.1.0-beta.20230127.tar.xz SHA256 (ctwm-4.1.0-beta.20230127.tar.xz) = a9fabda24491c548e53f871e0f0c42033fe41ceb5a29b99af5113214005972fb It's pretty clear just from code inspection that it would hack around the issue, and does in my testing. Unless somebody came up with a better quick fix, a reason we need to delay to properly handle it everywhere, or some other unrelated bug we haven't seen yet, I expect to call it good enough and re a lease. -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: Beta snapshot
> a) roughly what you said above; use Layout instead of BorderedLayout >for strutty windows. That's broken and wrong, but it's at least >consistent with how 4.0.3 would have been wrong. > > 2) Disclaim strut support and ignore the properties. Then strutty >windows will at least be obeying Border stuff, but things won't get >strutted. I'm still going back and forth on these; (a) seems slightly more worky, (2) seems slightly more honest. -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: Beta snapshot
On Fri, Jan 20, 2023 at 08:40:27PM +0100 I heard the voice of
Rhialto, and lo! it spake thus:
>
> Somehow it feels like something is overwriting the contents of the
> *cwin struct; the values look too wrong to be able to be derived
> from a proper assignment. In particular the 0x10100010001 feels
> like a bitmask...
Yah; and the visibility thing I noted points at similar ("this isn't a
ColormapWindow", rather than the "->colormap got overwritten somehow"
case). Though note that's a 0x not a 0b, so if it were a bitmask,
it'd be a 64-bit one. Which I'm fairly sure we don't have, so it'd be
2 32-bitters in a row, which also we don't obviously have, or it's a
couple short's that contain small offets or borders or the like.
A quick grep over our structs doesn't suggest any likely candidates
that have a Window first followed by that sorta thing (it does look
like a Window normally does, and you said it corresponded with a win
that was actually on your screen and you were interacting with). If
it's in the middle of a struct, I ain't gonna spend the time reading
around to guess what it might be.
But how would it get there, even if we knew what else it would be?
There's nowhere we'd be writing something else into the
ColormapContext, so it'd have to somehow get free()'d and reused by
something else. I don't see any obvious place we'd do that. We'd
free the old ->colormap in HandleColormapNotify(), but we'd have
already changed cwin->colormap in that case (and that would just
result in garbage in the ->colormap anyway, not in the whole cwin).
I guess there are two cases. The "cwin in context got free'd and
reused" is the above, which I don't see a path to. The alternative
would be "XFindContext didn't actually load anything, but we proceeded
anyway and so cwin is uninitialized stack garbage, that happened to
point to some other struct somewhere". How could it happen?
vtwm looks just like us. Current twm uses XFindContext==0 instead of
!=XCNOENT in the condition in its HandleVisibilityNotify(). Commit
log just indicates it was some reorganizing done for strict-aliasing
warnings. The manual says XCNOENT is the only failure case.
Inspecting libX11 source agrees with that. So, that doesn't seem
likely either; if we get that far, FindContext must have succeeded, so
the stack garbage case seems out.
I dunno. This seems a long way off from any code we've touched in my
memory, which means it'd have to be a long-standing bug, which just
makes it weird that you'd come across it now. Which also makes it
sound pretty hard to reproduce :(
I s'pose the backtrace could just be completely bogus. Source tree
doesn't match the running binary? But the only change in trunk since
your build date was in add_window.c, so I don't see how that could
throw it off in a way that would make as much internal sense...
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
Re: Beta snapshot
On Fri, Jan 20, 2023 at 09:15:43PM +0100 I heard the voice of Rhialto, and lo! it spake thus: > > It immediately pointed out that the "occupation" bit mask should be > unsigned. We should probably even make it uint32_t, if we want to be > that modern. Yeah, in principle, bitmaps should probably be unsigned. In practice... well, we're not reading/writing to databases or doing arithmetic with them or those sorta things that are liable to cause signedness issues, so I didn't think it was worth the churn (chasing all the uses and temp variables used along the way, etc) to try chasing it down. If we were going to, I'd probably go ahead and uint64_t it, if not take that as the time to investigate making workspaces more dynamic and allow creating/destroying/rearranging/etc. them on the fly. Ah, tree-style workspaces, there we go... -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: Beta snapshot
On Fri 20 Jan 2023 at 20:40:27 +0100, Rhialto wrote: > And such things might not even be caught by valgrind or an address > sanitizer, if the overlows are limited and only write into allocated > memory... although I didn't try it yet. Well building with the address sanitizer was easier than I thought. It immediately pointed out that the "occupation" bit mask should be unsigned. We should probably even make it uint32_t, if we want to be that modern. Let's see if/when it crashes again and what it reports. -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: Beta snapshot
On Thu 19 Jan 2023 at 19:09:19 -0600, Matthew D. Fuller wrote:
> On Sun, Jan 15, 2023 at 07:14:24PM +0100 I heard the voice of
> Rhialto, and lo! it spake thus:
> >
> > Unfortunately I got a core dump from cwtm (compiled Dec 17).
> [...]
>
> > (gdb) print cmap
> > $1 = (TwmColormap *) 0x10100010001
> >
> > (gdb) print *cwin
> > $2 = {w = 79691778, colormap = 0x10100010001, visibility = 2047083,
> > refcnt = 1}
>
> That's a new one on me. Every time I see colormaps I cry a little
> inside, but I haven't seen them crash anything ever and I dunno what
> could be causing that...
Somehow it feels like something is overwriting the contents of the *cwin
struct; the values look too wrong to be able to be derived from a proper
assignment. In particular the 0x10100010001 feels like a bitmask...
And such things might not even be caught by valgrind or an address
sanitizer, if the overlows are limited and only write into allocated
memory... although I didn't try it yet.
> Hey, we can just assume everybody's running 24bpp by now, and
> eliminate separate per-window colormaps entirely, right? That's
> definitely a small simple change that won't break anything...
Some time ago I wanted to try that authentic feeling of 1 bit per pixel,
but this X server doesn't even support that any more...
-Olaf.
--
___ "Buying carbon credits is a bit like a serial killer paying someone else to
\X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto
signature.asc
Description: PGP signature
Re: Beta snapshot
On Sun, Jan 15, 2023 at 07:14:24PM +0100 I heard the voice of
Rhialto, and lo! it spake thus:
>
> Unfortunately I got a core dump from cwtm (compiled Dec 17).
[...]
> (gdb) print cmap
> $1 = (TwmColormap *) 0x10100010001
>
> (gdb) print *cwin
> $2 = {w = 79691778, colormap = 0x10100010001, visibility = 2047083,
> refcnt = 1}
That's a new one on me. Every time I see colormaps I cry a little
inside, but I haven't seen them crash anything ever and I dunno what
could be causing that...
In a little poking, everything should funnel through
CreateColormapWindow(), which seems like (after it stashes the
ColormapWindow in the context, but hey, who needs ordering...) it
should either be pulling an existing colormap (from a previous
runthru) or creating a new one via CreateTwmColormap(). Either way it
should be some malloc'd space and a valid pointer (or at least NULL).
I find the ->visibility there a little weird too. Either we set that
to one of the VisibilityFoo defines, or it gets set to the state from
a XVisibilityEvent which is defined to be one of them as well (x-ref
https://www.x.org/releases/current/doc/man/man3/XVisibilityEvent.3.xhtml
and HandleVisibilityNotify()). And...
% grep -E 'Visibility.*bscur' /usr/local/include/X11/X.h
#define VisibilityUnobscured0
#define VisibilityPartiallyObscured 1
#define VisibilityFullyObscured 2
It takes a lot of 0's, 1's, and 2's to wind up as 2047083. So,
something's pretty bogus about that whole ColormapWindow.
> I was just doing something with it when ctwm crashed (I think making
> it fullscreen or something).
Really not fair, that's supposed to crash the OTP stuff.
Hey, we can just assume everybody's running 24bpp by now, and
eliminate separate per-window colormaps entirely, right? That's
definitely a small simple change that won't break anything...
--
Matthew Fuller (MF4839) | [email protected]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
Re: Beta snapshot
Unfortunately I got a core dump from cwtm (compiled Dec 17).
Core was generated by `ctwm'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 HandleVisibilityNotify ()
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/event_handlers.c:504
504 if((cmap->state & CM_INSTALLABLE) &&
(gdb) print cmap
$1 = (TwmColormap *) 0x10100010001
(gdb) bt
#0 HandleVisibilityNotify ()
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/event_handlers.c:504
#1 0x0040dd7d in DispatchEvent ()
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/event_core.c:335
#2 0x0040e006 in HandleEvents ()
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/event_core.c:205
#3 0x0040c44d in ctwm_main (argc=,
argv=)
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/ctwm_main.c:1083
#4 0x004060cd in ___start ()
#5 0x7f7fd9a0e9f8 in ?? () from /usr/libexec/ld.elf_so
#6 0x0001 in ?? ()
#7 0x7f7fff130530 in ?? ()
#8 0x in ?? ()
That value for cmap looks bogus...
(gdb) print *cwin
$2 = {w = 79691778, colormap = 0x10100010001, visibility = 2047083,
refcnt = 1}
That 'w' value does seem to be a valid window of mpv, the media player.
I was just doing something with it when ctwm crashed (I think making it
fullscreen or something).
(gdb) print *vevent
value has been optimized out
I haven't been able yet to dig further into this.
-Olaf.
--
___ "Buying carbon credits is a bit like a serial killer paying someone else to
\X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto
signature.asc
Description: PGP signature
Re: Beta snapshot
On Thu, Jan 12, 2023 at 08:36:57PM +0100 I heard the voice of Rhialto, and lo! it spake thus: > > Then at the mentioned location in add_window.c, ctwm could use > Scr->Layout instead of Scr->BorderedLayout for these windows. Except BorderedLayout is really to handle things like BorderTop etc, and only incidentally has strut stuff applied onto it. Now, whether we should even support that sorta config in the first place... but who dares even look under _that_ rock? Certainly at the least windows should ignore their own struts; failing to do that is completely nonsense. Whether they should ignore other struts, that seems a lot less clear; if somebody's actually using things that do such things, it seems like either it doesn't matter, or really bad things would happen as soon as there's a conflict. Bleh. But at any rate, just blatting them on top of the existing Border'ing stuff seems like a mess. So it seems like to really handle them, we'd have to be doing the struts as their own thing as part of constraining sizing and moving, on top of the Border handling. In a little aimless poking at the things currently using BorderedLayout, it looks like that's a fair sized task (especially since, for the exclusions, we need to keep track of and compare the windows in question, and not every place has that information at hand). My gut feeling is that's a decently nontrivial project with a lot of thinking and edge cases to handle along the way, as well as touching a lot of code. Seems like it'd push 4.1 back a fair bit at this point. Releasing broken code isn't fun, but... what're our choices for at least coming out with something not broken in new ways vs. 4.0.3? I guess there are two things we could do quickly and confidently. a) roughly what you said above; use Layout instead of BorderedLayout for strutty windows. That's broken and wrong, but it's at least consistent with how 4.0.3 would have been wrong. 2) Disclaim strut support and ignore the properties. Then strutty windows will at least be obeying Border stuff, but things won't get strutted. And of course there's iii) Do gate the release on properly fixing strutification, which means having rejiggered a fair bit of code along the way. That's all that pops to my mind, or at least it's all the ways to misconjugate a verbified strut I can think of... -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: Beta snapshot
> So...hm. I guess windows should be constrained by OTHER windows' > struts, but not their own? My impression is that in practice applications using struts are in a separate class (like "window manager") and we can probably get away with just ignoring struts for windows that set their own struts. Now, I have no idea if this can be implemented (because of ordering considerations). Stefan
Re: Beta snapshot
On Wed 11 Jan 2023 at 19:22:56 -0600, Matthew D. Fuller wrote: > So...hm. I guess windows should be constrained by OTHER windows' > struts, but not their own? That sounds insanely tricky to manage; > certainly can't be handled by simply overriding BorderedLayout. Maybe > it's wrong to be abusing BorderedLayout for struts anyway, since it's > presumably more for user-level constraining. And let's not even think > about the weird ordering considerations of when windows or messages > show up... > I think maybe we just don't really handle struts usefully, and we > SHOULD ignore them? Possibly forever, considering the > underspecification... Olaf? It seemed so simple at the time :) I just had an idea for a potential strategy. Struts are, as I understand it, meant to keep other windows away from something like a toolbar or menu bar which is stuck to the side of the screen. In other words, the window setting the struts is located inside the area it indicates. So maybe, when calculating the effective size of the combined struts, we can ignore the struts of windows that aren't actually located (or fully located, or don't overlap, or somesuch) in their strut area. Could that be an effective strategy? Maybe not, maybe this affects strutting windows only after they are put in the wrong place. Another idea: windows that set struts get to ignore all struts (including their own). The idea is that generally, only one window per side of the screen would set struts anyway. A window that sets struts conveniently has the EWMH_HAS_STRUT flag. Then at the mentioned location in add_window.c, ctwm could use Scr->Layout instead of Scr->BorderedLayout for these windows. > Matthew Fuller (MF4839) | [email protected] -Olaf. -- ___ "Buying carbon credits is a bit like a serial killer paying someone else to \X/ have kids to make his activity cost neutral." -The BOFHfalu.nl@rhialto signature.asc Description: PGP signature
Re: Beta snapshot
On Mon, Jan 09, 2023 at 06:27:31AM +0100 I heard the voice of Per Backman, and lo! it spake thus: > > Now I compiled the 20221228 beta without EWMH support, and the > problem seems to be gone, [...] OK, I've done a little playing around, and I can reproduce some odd shuffling around with stalonetray in an otherwise empty xnest. The symtoms I get are that I start it, a small gray window pops up in the upper left. When I restart, it moves to about its height down on the left margin. Restart again, it flops to its width in on the top margin. And repeated restarts just flip it back and forth between those positions. The oddness appears to have come in with r644 with the RLayout changes. So that's why it's not showing up in 4.0.3. OK, a bunch more investigation, and here's the source. In add_window.c:1465, we adjust the positioning of any window so it's inside the BorderedLayout (as opposed to the pre-RLayout code, which just make sure it was inside the full screen size; you could argue about which behavior is a bug, really...). So when stalonetray is started, it's 24x24+0+0, and that's just fine. But on the restart, the strut exists, so we move the stalonetray window down to +0+24 so it's "on-screen". Next restart, the left side is reserved (stalonestray switched itself from going sideways to going down when it was no longer "at the top"), so it gets shoved over to +24+0 (and considers itself going sideways). And back and forth. So...hm. I guess windows should be constrained by OTHER windows' struts, but not their own? That sounds insanely tricky to manage; certainly can't be handled by simply overriding BorderedLayout. Maybe it's wrong to be abusing BorderedLayout for struts anyway, since it's presumably more for user-level constraining. And let's not even think about the weird ordering considerations of when windows or messages show up... stalonetray doesn't pay attention to _NET_SUPPORTED, so just taking the STRUTS out of our claimed support doesn't help that case; we'd have to explicitly ignore the message. I think maybe we just don't really handle struts usefully, and we SHOULD ignore them? Possibly forever, considering the underspecification... Olaf? Extra details from investigation that you don't need to follow, but I already typed out, so: The oddness appears to have come in with r644 with the RLayout changes. And it can be hidden away by just commenting out the Scr->BorderedLayout = RLayoutCopyCropped(. line in EwmhRecalculateStrut. With that done, it stays in the upper left all the time. Now, what goes on here? Let's comment that out, start up, and fire up the stalonetray. Then using xprop, we can see % env DISPLAY=:1 xprop -name stalonetray _NET_WM_STRUT_PARTIAL _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 0, 23, 0, 0 and it stays just the same on restarts. So that's claiming 24 pixels at the top, from y=0 to 23. OK. So what if we bring the BorderedLayout recalculation back? Well, it starts up the same. Then we restart ctwm: % env DISPLAY=:1 xprop -name stalonetray _NET_WM_STRUT_PARTIAL _NET_WM_STRUT_PARTIAL(CARDINAL) = 24, 0, 0, 0, 24, 47, 0, 0, 0, 0, 0, 0 Now it's claiming 24 pixels at the left, from x=24 to 47. Restart a few more times: % env DISPLAY=:1 xprop -name stalonetray _NET_WM_STRUT_PARTIAL _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 24, 47, 0, 0 24 pixels at the top, from y=24 to 47. % env DISPLAY=:1 xprop -name stalonetray _NET_WM_STRUT_PARTIAL _NET_WM_STRUT_PARTIAL(CARDINAL) = 24, 0, 0, 0, 24, 47, 0, 0, 0, 0, 0, 0 % env DISPLAY=:1 xprop -name stalonetray _NET_WM_STRUT_PARTIAL _NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 24, 0, 0, 0, 0, 0, 24, 47, 0, 0 and it just keeps flipping back and forth. We don't mess with that, it's doing it itself. Reading its code and playing with its tracing, it seems to be doing that solely based on the position of the window, so... [loop back around to add_window stuff above] -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: Beta snapshot
On January 8, 2023 at 11:17:48 pm +01:00, Matthew D. Fuller wrote: > On Thu, Dec 29, 2022 at 01:49:37AM +0100 I heard the voice of > Per Backman, and lo! it spake thus: > > > > > I have stalonetray running in the upper right corner, after restart > > it is in the left upper corner. If I move it back again it stays > > there after restart. It also happens with other apps, but not > > always. > > > Well, in a quick glance at stalonetray, nothing in the window setup > code jumps out at me as being particularly odd. I can't say I've seen > anything like that happening here, though I've mostly just got a pile > of xterms and browser windows, so there's a lot of clients I wouldn't > be exercising at all. > > A common thing to test would be disabling EWMH support and seeing if > that hides it; there's no reason that would _break_ anything, but > stalonetray does seem to participate in EWMH conversations, and one > side or the other could be crossing signals on what something means. > Apart from that, it's probably down to bisecting or otherwise trying > out some steps to find out where it shows up... I don't have any > good guesses. Were you previously in the 4.0.3 release, or some dev > snapshot in between? > Yes, I was on 4.03 before, then on the first beta. I tried 4.10B on two > distributions, PCLinuxOS and Venomlinux, two different computers, different > age and different maker (Apple and Lenovo, both Intel). Now I compiled the 20221228 beta without EWMH support, and the problem seems to be gone, at least on one computer (the Mac, from 2008, I think, and PCLinuxOS). Maybe this is more of a mystery than a problem, when I moved Stalonetray back in place by ALT+mousebutton 1, it stayed there even if I restarted CTWM ten times... Per B
Re: Beta snapshot
On Thu, Dec 29, 2022 at 01:49:37AM +0100 I heard the voice of Per Backman, and lo! it spake thus: > > I have stalonetray running in the upper right corner, after restart > it is in the left upper corner. If I move it back again it stays > there after restart. It also happens with other apps, but not > always. Well, in a quick glance at stalonetray, nothing in the window setup code jumps out at me as being particularly odd. I can't say I've seen anything like that happening here, though I've mostly just got a pile of xterms and browser windows, so there's a lot of clients I wouldn't be exercising at all. A common thing to test would be disabling EWMH support and seeing if that hides it; there's no reason that would _break_ anything, but stalonetray does seem to participate in EWMH conversations, and one side or the other could be crossing signals on what something means. Apart from that, it's probably down to bisecting or otherwise trying out some steps to find out where it shows up... I don't have any good guesses. Were you previously in the 4.0.3 release, or some dev snapshot in between? -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: Beta snapshot
On Wed, 28 Dec 2022 14:54:57 -0600 "Matthew D. Fuller" wrote: > > https://www.ctwm.org/tmp/ctwm-4.1.0-beta.20221228.tar.xz > FWIW, I'm also using DontMoveOff with the default flat look and have so far _not_ encountered any window position bugs. I'm not using stalonetray. I've been restarting CTWM quite frequently since I've been tinkering with my config a bit. On another note, when doing a "make" followed by "sudo make install" I get the following message: CMake Warning at cmake_install.cmake:104 (message): No manpage to install: recheck config if this is unexpected. Is this expected for the beta snapshot? -- Carl Svensson
Re: Beta snapshot
On December 29, 2022 at 1:49:37 am +01:00, Per Backman wrote: > > I have move off enabled and 3d disabled, so maybe I should try with the next > beta... > > Tried it, the issue persists. Per B.
Re: Beta snapshot
On December 28, 2022 at 9:57:06 pm +01:00, Matthew D. Fuller wrote: > On Wed, Dec 28, 2022 at 06:45:39PM +0100 I heard the voice of > Per Backman, and lo! it spake thus: > > > > > My only problem so far is that a few windows jump to another > > position on the screen at restart of ctwm. > > > Hm. Is that new? Do they shift further every restart, or move back > to the same place every restart, or what? I recall some bug years > back where things shifted a few pixels every start, or maybe that > frame extents thing caused some app to miscalculate and reposition > itself? > > I have stalonetray running in the upper right corner, after restart it is in > the left upper corner. If I move it back again it stays there after restart. > It also happens with other apps, but not always. I have move off enabled and 3d disabled, so maybe I should try with the next beta... Per B
Re: Beta snapshot
On Wed, Dec 28, 2022 at 06:45:39PM +0100 I heard the voice of Per Backman, and lo! it spake thus: > > My only problem so far is that a few windows jump to another > position on the screen at restart of ctwm. Hm. Is that new? Do they shift further every restart, or move back to the same place every restart, or what? I recall some bug years back where things shifted a few pixels every start, or maybe that frame extents thing caused some app to miscalculate and reposition itself? -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: Beta snapshot
On Sat, Dec 17, 2022 at 10:32:50AM +0100 I heard the voice of Maxime Soulé, and lo! it spake thus: > > Just a note, I have a never committed patch to fix a window > placement when DontMoveOff is enabled without 3D borders: Looks reasonable. Got it, and a new snapshot with it. https://www.ctwm.org/tmp/ctwm-4.1.0-beta.20221228.tar.xz SHA256 (ctwm-4.1.0-beta.20221228.tar.xz) = 909589bb13df93ef755d84bd007c557447f2dc8229b8d1a3f1771322e1c348ca -- Matthew Fuller (MF4839) | [email protected] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: Beta snapshot
On Wed, 14 Dec 2022 21:48:52 -0600 "Matthew D. Fuller" wrote: > > Only a year or two later than vaguely planned, let's test out a > release beta. With a little luck, we can promote it by New Years... > Hello, My only problem so far is that a few windows jump to another position on the screen at restart of ctwm. Per B -- http://www.tufftuff.net Railways, trams and suchlike
Re: Beta snapshot
On Wed, 14 Dec 2022 21:48:52 -0600 "Matthew D. Fuller" wrote: > If you've been following along with the dev branches, there won't be > many surprises. But a snapshot is a nice fixed point to test out, > the pre-built tarballs can be a bit easier to build from than raw > checkouts, and hey, it's a good "plz test" callout point! Been on dev builds since 2020 and now the beta for the last few days, so far no problems here with my very boring one monitor setup :-) -- Carl Svensson
Re: Beta snapshot
Hi, Le 15/12/2022 à 04:48, Matthew D. Fuller a écrit : Only a year or two later than vaguely planned, let's test out a release beta. With a little luck, we can promote it by New Years... https://www.ctwm.org/tmp/ctwm-4.1.0-beta.20221214.tar.xz SHA256 (ctwm-4.1.0-beta.20221214.tar.xz) = 2f6a3b54a94236d2a39360a8fbfc9768bbe892c3a081283d7a3f80ebe29330af If you've been following along with the dev branches, there won't be many surprises. But a snapshot is a nice fixed point to test out, the pre-built tarballs can be a bit easier to build from than raw checkouts, and hey, it's a good "plz test" callout point! [snip] It works fine on my side with 3 monitors, for a long time now ;) I use the beta since your announce without any regression. Just a note, I have a never committed patch to fix a window placement when DontMoveOff is enabled without 3D borders: https://github.com/maxatome/ctwm-mirror/commit/ad8ffa3d851069cc2e5c0da754ac2d600d13cbf0 Regards, Max.
