Re: Fedora 40, Wayland, and ctwm
On Mon 19 Feb 2024 at 10:00:17 -0600, Quentin Barnes wrote: >- Do what I can to encourage the community to port ctwm to Wayland. One of the problems of Wayland is that it doesn't *have* the concept of window managers... -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: Calling system(3) when SIGCHLD is SIG_IGN'd
On Fri 12 Jan 2024 at 20:28:12 -0600, Matthew D. Fuller wrote:
> On Sat, Aug 12, 2023 at 03:22:56PM +0200 I heard the voice of
> Rhialto, and lo! it spake thus:
> > There seems to be only a single fork() in ctwm anyway, to call m4 to
> > parse the config file. The SIGCHLD changing could be limited to that
> > area, then set back to default.
> >
> > Or, alternatively, a proper signal handler for SIGCHLD could be set up.
>
> Presumably, we'd need to do the latter to handle the "inheriting
> unexpected children" case properly anyway. I wonder what happened
> before the SIG_IGN change. I guess we just accumulated zombies?
I expect so - I didn't really check.
> >From the looks of that PR, it doesn't seem like any kernel-side
> changes have fallen out of it, and cvsweb doesn't show any recent
> changes to system(3), so I presume this is still needed?
I didn't see any followup either. Their variant of the change goes like
this (but my version fits better with the current handler naming scheme
I think):
Index: signals.c
===
RCS file: /cvsroot/xsrc/external/mit/ctwm/dist/signals.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- signals.c 5 Jul 2023 07:36:07 - 1.1
+++ signals.c 20 Oct 2023 10:18:55 - 1.2
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include "ctwm_shutdown.h"
#include "signals.h"
@@ -26,6 +28,15 @@
// needs to trigger an action.
bool SignalFlag = false;
+void ChildExit(int signum)
+{
+ int Errno = errno;
+ /* reap dead children, ignore status */
+ while (waitpid(-1, NULL, WNOHANG) > 0)
+ continue;
+ /* restore errno for interrupted sys calls */
+ errno = Errno;
+}
/**
* Setup signal handlers (run during startup)
@@ -46,9 +57,12 @@
// die...
signal(SIGALRM, SIG_IGN);
- // This should be set by default, but just in case; explicitly don't
- // leave zombies.
- signal(SIGCHLD, SIG_IGN);
+ /* Setting SIGCHLD to SIG_IGN detaches children from the parent
+* immediately, so it need not be waited for.
+* In fact, you cannot wait for it, so a function like system()
+* breaks.
+*/
+ signal(SIGCHLD, ChildExit);
return;
}
> Matthew Fuller (MF4839) | fulle...@over-yonder.net
-Olaf.
--
___ Olaf 'Rhialto' Seibert
\X/ There is no AI. There is just someone else's work. --I. Rose
signature.asc
Description: PGP signature
Breezy
Hi, Can we get rid of breezy (brz)? I am the one packaging it for pkgsrc since ctwm is the only thing that needs it. Today I'm trying to update to vesion 3.3.4 and it is being extremely annoying. Compared to the previously packaged version, it now requires Rust. And for no good reason that I can see. It looks like somebody is just trying stuff out, to see if it is possible. Also it doesn't work with the latest 2 versions of Python. I don't like breezy any more. It is too much a pain in the ass. It claims it can use git format repos, so we can simply convert, and whoever wants to keep using it, would be able to. That won't be me. -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: Calling system(3) when SIGCHLD is SIG_IGN'd
On Sun 13 Aug 2023 at 13:51:53 +0200, Michael van Elst wrote: > On Sun, Aug 13, 2023 at 01:04:00PM +0200, Rhialto wrote: > > I suppose that the problem was not noticed since 2018 because > > there are several preconditions: > > The problem didn't exist for NetBSD before the recent ctwm update in xsrc. The change was made in ctwm in 2018 and I used it on NetBSD, pretty much always the HEAD version. > > - session startup script must start some programs in the background, and > > end with "exec ctwm". Just "ctwm" without "exec" doesn't do it. This > > is so that the started background processes become children of ctwm > > (even if ctwm didn't start them itself). > > Indeed, that's the standard way to start a session. Exiting the window > manager will then also finish the session. I would say it is one of the two major ways. I end the session startup script with "exec xterm". That way you can exit the window manager (or it can crash... that can happen while developing new things) but it won't end your X session. > > - on FreeBSD (and probably Linux too) they apparently don't follow the > > described semantics of wait*(2) regarding SIGCHLD set to SIG_IGN, OR > > in system(3) they work around it somehow. Alledgedly, POSIX doesn't > > require system(3) to work in this state. > > I haven't found anything that would even talk about it, but the sematics > of waitpid in this case (wait for all children to finish) seem to forbid > that system can work correctly unless it works outside of POSIX system calls. Maybe the POSIX people overlooked this case, that is also possible. > Michael van Elst -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: Calling system(3) when SIGCHLD is SIG_IGN'd
On Sat 12 Aug 2023 at 23:49:43 +0200, Michael van Elst wrote:
> On Sat, Aug 12, 2023 at 03:22:56PM +0200, Rhialto wrote:
> >
> > Or, alternatively, a proper signal handler for SIGCHLD could be set up.
>
> ctwm had a signal handler for SIGCHLD (not 100% correct). And that got
> replaced
> by ignoring the signal to avoid waiting for children.
Yes, looking at the history, it got replaced in commit 647.1.4. This was
removed (amongst other things):
#ifdef __WAIT_FOR_CHILDS
/*
* Handler for SIGCHLD. Needed to avoid zombies when an .xinitrc
* execs ctwm as the last client. (All processes forked off from
* within .xinitrc have been inherited by ctwm during the exec.)
* Jens Schweikhardt
*/
void
ChildExit(int signum)
{
int Errno = errno;
signal(SIGCHLD, ChildExit); /* reestablish because we're a one-shot */
waitpid(-1, NULL, WNOHANG); /* reap dead child, ignore status */
errno = Errno; /* restore errno for interrupted sys calls
*/
}
#endif
The "one-shot" comment is no longer true (POSIX says "Once an action is
installed for a specific signal, it shall remain installed until another
action is explicitly requested (by another call to sigaction()), until
the SA_RESETHAND flag causes resetting of the handler, or until one of
the exec functions is called." in
https://pubs.opengroup.org/onlinepubs/9699919799/functions/sigaction.html
The waitpid() call should be in a loop, because there may be multiple
children to wait for. I read somewhere about "SysV semantics" that would
cause exactly one SIGCHLD for each child, but I wouldn't want to invoke
those semantics.
The __WAIT_FOR_CHILDS was probably never defined so this code was
probably never used. BUT, the comment on the new "signal(SIGCHLD,
SIG_IGN);" says "This should be set by default" but that also isn't
exactly true. Default action for SIGCHLD is to do nothing, but that
isn't the same as SIG_IGN (as discussed in the initial mail and the
referenced Problem Report).
I suppose that the problem was not noticed since 2018 because
there are several preconditions:
- session startup script must start some programs in the background, and
end with "exec ctwm". Just "ctwm" without "exec" doesn't do it. This
is so that the started background processes become children of ctwm
(even if ctwm didn't start them itself).
- on FreeBSD (and probably Linux too) they apparently don't follow the
described semantics of wait*(2) regarding SIGCHLD set to SIG_IGN, OR
in system(3) they work around it somehow. Alledgedly, POSIX doesn't
require system(3) to work in this state.
-Olaf.
--
___ Olaf 'Rhialto' Seibert
\X/ There is no AI. There is just someone else's work. --I. Rose
signature.asc
Description: PGP signature
Re: Calling system(3) when SIGCHLD is SIG_IGN'd
On Sat 12 Aug 2023 at 16:05:34 +0200, Rhialto wrote:
> On Sat 12 Aug 2023 at 15:22:56 +0200, Rhialto wrote:
> > Or, alternatively, a proper signal handler for SIGCHLD could be set up.
>
> I propose something like this.
> It worked for me in a quick test, also when I changed the style of my
> .xinitrc file from my usual
>
> xterm &
> exec ctwm
>
> to
>
> ctwm &
> exec xterm
I meant that the other way around. The bug shows in the first case.
I've also updated it slightly to save and restore errno.
=== modified file 'signals.c'
--- old/signals.c 2018-11-18 22:08:49 +
+++ new/signals.c 2023-08-12 15:03:42 +
@@ -8,6 +8,8 @@
#include
#include
#include
+#include
+#include
#include "ctwm_shutdown.h"
#include "signals.h"
@@ -16,6 +18,7 @@
/* Our backends */
static void sh_restart(int signum);
static void sh_shutdown(int signum);
+static void sh_sigchld(int signum);
// Internal flags for which signals have called us
@@ -46,9 +49,8 @@
// die...
signal(SIGALRM, SIG_IGN);
- // This should be set by default, but just in case; explicitly don't
- // leave zombies.
- signal(SIGCHLD, SIG_IGN);
+ // Explicitly don't leave zombies.
+ signal(SIGCHLD, sh_sigchld);
return;
}
@@ -123,3 +125,18 @@
SignalFlag = sig_shutdown = true;
}
+/**
+ * Handle SIGCHLD so we don't leave zombie child processes.
+ * SIG_IGN'ing it would cause system(3) to malfunction.
+ */
+static void
+sh_sigchld(int signum)
+{
+ pid_t pid;
+ int old_errno = errno;
+
+ while((pid = waitpid(-1, NULL, WNOHANG)) > 0)
+ ;
+
+ errno = old_errno;
+}
-Olaf.
--
___ Olaf 'Rhialto' Seibert
\X/ There is no AI. There is just someone else's work. --I. Rose
signature.asc
Description: PGP signature
Re: Calling system(3) when SIGCHLD is SIG_IGN'd
On Sat 12 Aug 2023 at 15:22:56 +0200, Rhialto wrote:
> Or, alternatively, a proper signal handler for SIGCHLD could be set up.
I propose something like this.
It worked for me in a quick test, also when I changed the style of my
.xinitrc file from my usual
xterm &
exec ctwm
to
ctwm &
exec xterm
Before the fix, the second form did indeed cause ctwm to get blocked.
=== modified file 'signals.c'
--- old/signals.c 2018-11-18 22:08:49 +
+++ new/signals.c 2023-08-12 13:44:27 +
@@ -8,6 +8,7 @@
#include
#include
#include
+#include
#include "ctwm_shutdown.h"
#include "signals.h"
@@ -16,6 +17,7 @@
/* Our backends */
static void sh_restart(int signum);
static void sh_shutdown(int signum);
+static void sh_sigchld(int signum);
// Internal flags for which signals have called us
@@ -46,9 +48,8 @@
// die...
signal(SIGALRM, SIG_IGN);
- // This should be set by default, but just in case; explicitly don't
- // leave zombies.
- signal(SIGCHLD, SIG_IGN);
+ // Explicitly don't leave zombies.
+ signal(SIGCHLD, sh_sigchld);
return;
}
@@ -123,3 +124,15 @@
SignalFlag = sig_shutdown = true;
}
+/**
+ * Handle SIGCHLD so we don't leave zombie child processes.
+ */
+static void
+sh_sigchld(int signum)
+{
+ pid_t pid;
+ int status;
+
+ while((pid = waitpid(-1, , WNOHANG)) > 0)
+ ;
+}
-Olaf.
--
___ Olaf 'Rhialto' Seibert
\X/ There is no AI. There is just someone else's work. --I. Rose
signature.asc
Description: PGP signature
Re: Calling system(3) when SIGCHLD is SIG_IGN'd
Problem Report from the NetBSD side: https://gnats.netbsd.org/57579 -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Re: Calling system(3) when SIGCHLD is SIG_IGN'd
There seems to be only a single fork() in ctwm anyway, to call m4 to parse the config file. The SIGCHLD changing could be limited to that area, then set back to default. Or, alternatively, a proper signal handler for SIGCHLD could be set up. -Olaf. -- ___ Olaf 'Rhialto' Seibert \X/ There is no AI. There is just someone else's work. --I. Rose signature.asc Description: PGP signature
Calling system(3) when SIGCHLD is SIG_IGN'd
I came across an interesting bug caused by the way ctwm sets up signals, the POSIX description of SIGCHLD and wait(2), and a common way of starting a window manager. It's at http://mail-index.netbsd.org/tech-userlevel/2023/08/12/msg014107.html and any followups can be read from there, but I'll quote the whole message here. Can we avoid setting doing `signal(SIGCHLD, SIG_IGN)`? It is done in signals.c:setup_signal_handlers(). - >From: Taylor R Campbell >To: tech-userle...@netbsd.org >Subject: system(3) semantics when SIGCHLD is SIG_IGN'd >Date: Sat, 12 Aug 2023 11:58:36 + What should system(3) do when the signal action for SIGCHLD is SIG_IGN, or has SA_NOCLDWAIT set? Setting SIGCHLD to SIG_IGN has the effect of reaping zombie children automatically, so that calling wait(2) is unnecessary to reap them -- and, further, doesn't return _at all_ until the last child has exited. This semantics -- same as setting SA_NOCLDWAIT -- is enshrined in POSIX: If the calling process has SA_NOCLDWAIT set or has SIGCHLD set to SIG_IGN, and the process has no unwaited for children that were transformed into zombie processes, the calling thread will block until all of the children of the process containing the calling thread terminate, and wait() and waitpid() will fail and set errno to [ECHILD]. https://pubs.opengroup.org/onlinepubs/7908799/xsh/wait.html So if a process already has a child, and calls system(3) as it is currently implemented in libc in ~all versions of NetBSD, system(3) will hang indefinitely until the existing child exits. This manifests in newer versions of ctwm which set SIGCHLD to SIG_IGN if you have a .xsession file that does something like: xterm & xclock & exec ctwm This causes ctwm to start with two children already, which in turn causes system(3) to hang when you try to start an application from the ctwm menu. The ctwm hang led to PR kern/57527 (https://gnats.netbsd.org/57527, `kern' because at first it looked like a missing wakeup in the kernel before we realized this is exactly how POSIX expects SIG_IGN and SA_NOCLDWAIT to behave), which has some litmus tests for the semantics and draft code to mitigate the situation in system(3). So, should we do anything about this in system(3)? Pro: Makes existing code code like ctwm work. Cons: - POSIX doesn't ask system(3) to work when SIGCHLD is set to SIG_IGN or when it has SA_NOCLDWAIT set, so this code is nonportable anyway; might break on other systems too, so breakage on NetBSD leading to an upstream bug report is helpful. - Changing signal actions has the side effect of clearing the signal queue, and I don't see a way around that. Alternative would be to say: don't do that; fix the buggy code that calls system(3) with SIGCHLD ignored, either by having it set a signal handler that calls waitpid(-1, NULL, WNOHANG) until success, or by having it use something other than system(3). - signature.asc Description: PGP signature
Re: Partial success completing transition to Ubuntu more help needed
> [I'll understand if anyone finds all that unintelligble...] Well surely it sounds like the various installers got confused about what to put where. I won't pretend to be able to diagnose the situation fully, but I do think I know some tools that may help you with that. In particular, which partitions exist exactly and who is using them. For example, I have a suspicion that you have a single /boot or /boot/efi partition which has been overwritten or changed by multiple installers. First, the command "lsblk" should show you all "block devices" your current kernel sees, and where they are mounted. If they are not mounted, they likely belong to some other Linux install. Likely you will have a /boot or /boot/efi partition (at least, Ubuntu likes to have it that way). In there there is likely a directory with a grubx64.efi and grub.cfg: those are likely the boot loader and its config file as started by your UEFI firmware. In the Ubuntu I'm looking at, the grub.cfg file merely defers to another grub.cfg file, something like ($root)/boot/grub/grub.cfg. If you can still boot all the different Linux installs you made (I don't recall if you mentioned that), likely there are multiple directories with grub inside /boot/efi, or the second-stage grub.cfg file has multiple entries for the different systems. In any case, each of those would show a place to look for things. In particular they would indicate which partition to use as a root partition. Maybe it will show you that there is no place that the CentOS stuff could be hiding. Perhaps Ubuntu overwrote (part of) it. If CentOS installed itself with separate / and /usr partitions (I have no idea if it would) then some of it may still be available. I suspect its / partition to be re-used by Ubuntu though, given the name of centos-root which you see in Ubuntu. Second, you mention "/dev/mapper/centos-root". The first part of that, "/dev/mapper" usually refers to the Logical Volume Manager. To get an overview of which logical volumes exist, issue the "lvs" command as root. There is also "pvs" to list Physical Volumes (in case you have multiple disks) and "vgs" to show Volume Groups. There might be multiple LVs around for different Linux versions. Hopefully this will at least help you to find data which may still be available on your disk even though you don't see it, so that you may save or discard it as you wish. -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
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 CreateCol
Re: Help needed completing transition to ctwm on Ubuntu
On Thu 26 Jan 2023 at 11:59:26 +0100, Per Backman wrote: > There should be a ctwm.desktop-file in /usr/share/xsessions, ... > My ctwm.desktop looks like: > > [Desktop Entry] > Name=CTWM > Exec=/usr/bin/ctwm > TryExec=/usr/bin/ctwm > Icon= > Type=Application On my laptop I even found old remnants of a twm.desktop file. Installing ctwm didn't also install a ctwm.desktop, so you would have to create it yourself in /usr/share/xsessions. The example only starts ctwm and nothing else; you probably have a .xessionrc or .xinitrc script to set up your session, and you can put that in place of Exec= if you want. If you build ctwm yourself (the one from Ubuntu is 3.7.1 so rather old) you don't even have to overwrite the packaged one; you can just put it in $HOME/bin, and if either the .desktop file or the .xsessionrc file refers to it, it should be used. Oh, I almost forget: you can choose the "desktop session" from the login screen. The username box has a thingie that brings up a menu (I'm not sure if I kept the default desktop manager, but the place to click isn't obvious if you don't suspect that the feature exists) which lists the options from /usr/share/xsessions and a few 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 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
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: What are struts?
On Thu 12 Jan 2023 at 16:10:39 -0500, Steve Litt wrote: > There's been a discussion of "struts" in the context of "other windows' > struts", but I don't know what struts are. A strut is an area (typically along the edge of the screen) where windows should stay away from. Usually there is something like a task bar or menu bar or panel there. But if you maximize a window, that area will remain unused. With some window managers you can't even move another window over them, even partially. The task bars are also windows, of course, and it would be usual that those windows also set the strut. But in theory it could be a totally different window which does it. Here is a page describing it: https://specifications.freedesktop.org/wm-spec/1.3/ar01s05.html linked from https://stackoverflow.com/questions/21384819/x11-struts-geometry ctwm treats _NET_WM_STRUT_PARTIAL like _NET_WM_STRUT, so the extra fields (which reduce the reserved area) are ignored. > SteveT -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 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) | fulle...@over-yonder.net -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
Bazaar and breezy
To be able to work on ctwm, I have been packaging the version control client bazaar and then breezy for pkgsrc. The problem with bzr is that it uses a wy end-of-life version of Python; it is still on 2.7. Also, its GUI tool to visualise the repository (qbzr), which I find rather essential for working with graph-based version control, is based on Qt4 which is also being phased out actively. The replacement, breezy, doesn't seem to have a working replacement for qbzr, at least last time I checked. I did check for updates to breezy just now, and the release notes for version 3.3.0 say: * Breezy now requires setuptools-rust and a rust compiler to be built. (Martin Packman, Jelmer Vernoo#) I'm sorry, but this is getting out of hand. -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 BOFH falu.nl@rhialto signature.asc Description: PGP signature
Re: Iconified Windows, and Workspaces
On Sun 25 Sep 2022 at 21:53:51 +0100, Richmond wrote:
>
> If I iconify a window, is there a way to move the icon to a different
> workspace? If the window is not iconified I can use the mouse to do this
> by dragging it on the workspace map, but if it is iconified it is not
> visible on the workspace map.
Yes, the icon follows the same workspace occupation rules as its window.
So you can attach a menu entry or shortcut key to the icon to bring up
the Occupation Window. I have it in a menu (I think it's derived from
some default config):
Button3 = : icon : f.menu "iconmenu"
menu "iconmenu" {
"Actions" f.title
"" f.separator
"Restore" f.iconify
"Move" f.move
"Occupy ..."f.occupy
"Occupy All"f.occupyall
"" f.separator
"Close Window" ("white":"red") f.delete
"Kill App" ("white":"red") f.destroy
}
> When windows are iconfied is there a way to arrange them automatically,
> and with no text? The text can be very long for example with Seamonkey.
> They are placed at random not very intelligently, i.e. sometimes half
> off the screen, sometimes on top of other icons.
I think the icon placement is determined the first time you iconify the
window, and then it's the mouse position or something like that. After
that they keep the same position.
You can use the IconRegion to specify where icons should go, but the
application may override that (they probably rarely do).
ShrinkIconTitles can make the icon titles at least smaller while the
mouse is away from them. Older ctwm versions used the misspelling
"SchrinkIconTitles". There are also MaxIconTitleWidth width and
NoIconTitle [{ win-list }].
-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: Some enhancements for stack based window switching
On Wed 27 Jul 2022 at 02:11:49 +0500, Vitaly Shevtsov wrote: > I'm sorry, I've attached the wrong file. This is the correct one Which version did you use? I wrote a patch for this, so you're probably referring to that one, but the latest version doesn't have "StackLeader" any more. It got a bit outdated, but I merged in the trunk and now you can get a fresh version again at https://code.launchpad.net/~ctwm/ctwm/windowstack2 . I don't have time to try it out in detail right now, but it might be that this works the way you want. The commit comment "RingLeader can change if we enter or leave windows. That would rotate the stack. Therefore we designate "Scr->Ring" as a fixed point to start every time." makes me think that; but it has been a while so I'm not sure :) So, in case this version still has the issue you're fixing, I hope it is still possible to fix it again but differently (given that StackLeader is no longer there). My design goal for the patches was that if you don't use the stack but the ring, then you don't execute *any* extra code at all. So keeping both a stack and a ring administration, for example, would not match that goal. But code that is not terribly efficient for the stack (if it's used) would be acceptable. That's why I put all the code that manages the stack in the keyboard mapping, via f.warpring "startstack" and f.warpring "finishstack" (when pressing or releasing the Alt or Windows key). I don't think I succeeded 100% (I think there is some extra assignment or check here and there, even in the ring case) but I would like to stick to it as much as possible. Can you try if the version I linked above works as you expect? If not, would it be possible to adjust your patch to that version? If that also doesn't work, maybe it's possible if you re-introduce some variable that takes the role of StackLeader as you used it? (Note that with, e.g. BottomOfStack, I have to be very careful that it is still a valid pointer by the time I try to use it for anything; the window it points to may have been deleted in the mean time). Cheers, -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: ctwm "forgets" keybindings after a while
On Sun 10 Oct 2021 at 15:52:04 -0700, Jonathan Thornburg wrote: > Brilliant! You are indeed both correct -- my problem was mainly Num-Lock > (which on my keyboard is needed in order to enable the numeric keypad), > but when I tested, Caps-Lock also causes my bindigs to be ignored. One shortcoming with the solution is that it doesn't work for the case when you have *both* of these modifiers active. This stems from the somewhat annoying fact that to make key mappings work, they have to be "grabbed" from the X server, including all modifiers that apply to them correctly set. So if you have a key mapping for plain 'X' and you ignore CapsLock and NumLock, ctwm needs to grab 'X', CapsLock+'X', NumLock+'X', and CapsLock+NumLock+'X'. If you were to ignore 3 modifiers, it would need to grab 8 different keys. Of course this gets out of hand very very quickly. And the person who wrote the IgnoreModifier code didn't think of this anyway, since it only grabs the keys with 1 modifier at a time... I don't know if there is a better solution than what I sketeched above. Because I dislike it so much, I haven't made such a change. I'm not sure if there is a better solution though... -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: ctwm "forgets" keybindings after a while
On Fri 08 Oct 2021 at 23:18:00 -0700, Jonathan Thornburg wrote: > > I'm using ctwm 4.0.3 > > (bzr:fulle...@over-yonder.net-20190721212859-1hko50q7rrvqttfb) > on OpenBSD 7.0 (2021-Sep-27 snapshot). My .ctwmrc contains the lines > > "F1"= : window : f.raise > "F1"= : title : f.raise > > "F12" = : window : f.lower > "F12" = : title : f.lower > > When I start ctwm, these work fine -- the F1 key raises the current > window to the front, and the F12 lowers the current window to the back. > > The problem is, after running ctwm for a while (anywhere from a few > minutes to some hours, depending on my usage), these keys stop working > (they no longer raise/lower the current window). I've checked with > 'xev' and these keys are still generating keypress X events. The most common thing that causes such a symptom is having Caps Lock pressed. It counts as a modifier, so pressing CapsLock + F1 doesn't match your mapping. > Is this a known issue with ctwm? If not, are there debug features > I could activate to help in tracking down the problem? If that is not it, there is a #define DEBUG_EVENTS that you could enable in event_handlers.c, and recompile ctwm. Unfortunately it doesn't add any output for key presses... but you could add some printf statements inside the function HandleKeyPress() to check how far it gets. If you restart the modified ctwm (ctwm --replace) from a text console, it can freely print its stuff, unhindered by X. -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: how to make icon images opaque? or get rid of icon images altogether?
On Fri 01 Oct 2021 at 22:36:09 -0700, Jonathan Thornburg wrote:
> When ctwm iconifies a window, it usually (e.g., for xterm, xpdf, firefox,
> & iridium) shows an icon which has a transparent image, and vertically
> immediately below this there is an opaque textbox with the icon or
> application name. Is there a way to make all icon images opaque other
> than my supplying new images for every application via the .ctwmrc
> /Icons/ variable?
>
> And/or, is there a way to get rid of the icon images entirely (so icons
> would show only the opaque textbox with the icon or application name)?
> I thought of setting the /IconSize/ variable to "1x1", but then there's
> that magic phrase in the ctwm man page, "If an icon with the exact size
> is not available, one with the nearest (area) size will be chosen.".
>
> I've looked through 'man ctwm' and https://www.ctwm.org/manpage.html
> (which is the same), but not found precisely what I'm looking for.
> I'm currently using ctwm 4.0.3 on OpenBSD 7.0 (snapshot from 2021-09-27),
> but I could easily compile a different version from source if need be.
Some programs set their own icon(s). You can see them with the xprop
program: _NET_WM_ICON is displayed as a sort of ascii-art.
For programs that don't specify their own icon, you can give a default
with UnknownIcon "xpm:unknown1.xpm". There is also ForceIcons, to
override client-supplied pixmaps with those given in Icons{}, but this
does not override _NET_WM_ICON icons if there is nothing in Icons{}.
But since the names in Icons{} are regular expressions, you should be
able to just always assign an empty icon with
ForceIcons
Icons { ".*" "xpm:empty.xpm" }
if you make an empty icon. Or whatever other thing you want.
-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: ctwm blocks "wmctrl -c"
On Fri 01 Oct 2021 at 19:24:58 -0500, Matthew D. Fuller wrote: > It feels a little bleh to be faking our way in through > ExecuteFunction(), but that happens elsewhere in the EWMH stuff > already, and DTRT'ing would mean redoing or extracting a lot of the > logic in the handler anyway, so the alternative seems like a fair bit > of work to get somewhere not obviously better anyway. As a first approach, I was even looking at calling DFHANDLER(deleteordestroy) directly, but faking up all its arguments, which are hidden in a macro, was even uglier. So I didn't even finish that approach. I merged the branch just now. > Matthew Fuller (MF4839) | fulle...@over-yonder.net -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: ctwm blocks "wmctrl -c"
On Fri 24 Sep 2021 at 18:45:20 -0500, Matthew D. Fuller wrote: > So... it's _possible_, but only if someone implements it 8-} Such as in https://code.launchpad.net/~rhialto/ctwm/net-close-window aka lp:~rhialto/ctwm/net-close-window. The changes aren't big: https://bazaar.launchpad.net/~rhialto/ctwm/net-close-window/revision/691 I was deliberating whether I would use f.delete or f.deleteordestroy. The former only works if the application supports the WM_DELETE_WINDOW protocol; if it doesn't, the whole application is killed (as mentioned elsewhere in this thread). The documentation as given does contemplate that the window manager uses XKillClient. But it seems a bit drastic and unexpected that if you want to close just one window of some multi-window program, that you run the risk to kill the whole program. But if people insist, it can be changed easily :-) > Matthew Fuller (MF4839) | fulle...@over-yonder.net -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 BOFH falu.nl@rhialto signature.asc Description: PGP signature
Re: Releasing and VirtualScreens' future
On Sat 17 Jul 2021 at 12:04:06 -0400, JOHN URBAN wrote: > Hopefully, you are not talking about workspaces, which almost everyone > I know uses No, fortunately we're not :-) Your question shows that Virtual Screens are a very obscure feature. In the manpage they are probably only mentioned under the VirtualScreens keyword. "Virtual screens are designed to be used when you have several physical screens bound together with the Xinerama X extension." which practically nobody has (any more) in the first place. Each screen can then show a different workspace. This only works in a useful way if your screens are the same size. Which, I think, is less common today than it used to be (for instance laptops with an external screen attached would have different sizes). Also, a window that is supposed to be visible in both those workspaces can't be, because of X "limitations". So there is lots of tricky code to catch that sort of cases and prevent them. -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: Releasing and VirtualScreens' future
On Thu 15 Jul 2021 at 22:05:48 -0500, Matthew D. Fuller wrote: > - Then over time we can start unwinding ->vs and the various > Scr->*root things as we have to deal with them, since they could > only ever be in one known state. I would propose to do this more thoroughly, when we get to that point. Remove variables and struct members related to virtual screens, and fix up all code that breaks because of it. That should get the majority of the work done. I suspect that after that, there will be some less obvious cases of "strange code" or "weird design" that are still there. Those we can improve as they get identified. > So, who wants to speak up in favor of VirtualScreens? Or against > working up a release? Down with virtualscreens! Long live a release! :) What could get a similar treatment are WindowBox and "-w [win-id]". Both play nasty games with coordinates and *Root windows. In theory, a WindowBox is a nice way to group windows. I played with it in the past, but there are too may weirdnesses there. -w [win-id] is sort of nice for debugging ctwm and/or configurations. Things like f.hypermove speak to the imagination. It is also somewhat reminicent of the thing from MSWindows 3.x where you'd have an application like an IDE which has one big master window, and subwindows inside that for editing or debugging or whatnot. I've forgotten what it's called. It would be great if programs like The GIMP which have a similar feature could use the user's preferred window manager for that. But it'll never happen, I fear: too late. -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: [Branch ~ctwm/ctwm/trunk] Rev 686: Update minimum cmake version to 3.6.
On Mon 12 Jul 2021 at 00:50:38 -, nore...@launchpad.net wrote: > Merge authors: > Matthew Fuller (fullermd) > > revno: 686 [merge] > committer: Matthew Fuller > branch nick: ctwm > timestamp: Sun 2021-07-11 19:49:19 -0500 > message: > Update minimum cmake version to 3.6. This change may have broken with the cmake version that I'm using. $ cmake --version cmake version 3.20.4 $ make VERBOSE=1 ... [ 4%] Built target man make -f CMakeFiles/ctwmlib.dir/build.make CMakeFiles/ctwmlib.dir/depend [ 5%] Building parser with yacc. /usr/bin/yacc -d\ -b\ gram /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/gram.y Usage: /usr/bin/yacc [options] filename Options: -b file_prefixset filename prefix (default "y.") -Bcreate a backtracking parser -dwrite definitions (.tab.h) -iwrite interface (y.tab.i) -gwrite a graphical description -lsuppress #line directives -Lenable position processing, e.g., "%locations" -o output_file(default ".tab.c") -p symbol_prefix set symbol prefix (default "yy") -Pcreate a reentrant parser, e.g., "%pure-parser" -rproduce separate code and table files (y.code.c) -ssuppress #define's for quoted names in %token lines -tadd debugging support -vwrite description (y.output) -Vshow version information and exit *** Error code 1 Stop. Note the extra backslashes in "/usr/bin/yacc -d\ -b\ gram". I think this comes from cmake_files/setup_yacc.cmake, which has set(YFLAGS "-d -b gram") I suppose that cmake thinks that this string is meant as a single argument and therefore it escapes the spaces to make it so. Looking at the documentation at https://cmake.org/cmake/help/latest/command/set.html doesn't mention anything related to this though. Some other cases of set() use the value unquoted (which seems like a weird and unsafe syntax to me though) and removing the quotes here seems to help. The next yacc flag manipulation is more problematic: string(APPEND YFLAGS " -t -v") With the quotes I get more backslashed spaces. Without them all spaces disappear and everything gets stuck together, which is also wrong. [ 5%] Building parser with yacc. /usr/bin/yacc -d -b gram-t-v /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/gram.y So how to solve this one, I'm not sure yet. -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
Ctwm mentioned on Heise.de news site :)
It's really about the new NetBSD 9.2 release but ctwm is mentioned near the end. https://www.heise.de/news/NetBSD-9-2-Stabiler-effizienter-und-mit-geschlossenen-Sicherheitsluecken-6052462.html Weitere Verbesserungen Die mitgelieferte Konfiguration für den Standard-Window-Manager ctwm wurde verbessert. Es floss Feedback der Benutzer ein, um die Bedienung zu verbessern. Zudem behebt das neue Release Probleme mit dem Fensterfokus. or: Further improvements The included configuration for the standard window manager ctwm has been improved. There was feedback from users to improve the usage. The new release fixes problems with the window focus. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: Resize window size
On Wed 14 Apr 2021 at 17:38:05 +0200, Michael van Elst wrote: > Hello, > > (c)twm opens a small window showing title and geometry when placing > a window, moving or resizing it. > > I noticed that the first case displays the text truncated at the bottom > when using a larger ResizeFont like: > > ResizeFont "-misc-fixed-medium-r-*-*-*-200-*-*-*-*-iso10646-1" > > The Resize window is sized correctly for the move and resize case. > > The window height calculation in add_window.c differs from those > done in functions_win_moveresize.c and win_resize.c. Aligning > the code in add_window.c like: That is from 4.0.3 I guess. I just see that there is a new branch in the NetBSD repository; you're importing the 4.0.3 release? I like it! In any case it is good to have the same size calculations here, but (at least with the current trunk code) I can't readily reproduce it. Maybe my font or window titles are not conspiring to show the problem. If I read the code correctly, the XmbTextExtents() call (just above the context of the diff) is applied to the window title, so more than just ": ", which comes below (at the end of the context). Maybe if the digits are taller than the tallest letter in the window title I would expect a miscalculation. Unicode fonts often have quite large vertical sizes, because they often contain non-ASCII glypghs that are much taller than ASCII text. In some places in ctwm there is a mitigation to avoid ugly layout from that effect. I guess for this little window that doesn't seem to be a problem (yet, anyway). Anyway, I'm ok with this change (but I don't make the final decision), in the context of using the same sizing method in all comparable places. > I don't know if or how you accept patches, but if you think this > is correct, feel free to use it. Sending patches here is perfectly fine. > Michael van Elst Cheers, -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: Some small cleanups
On Tue 09 Mar 2021 at 22:55:19 -0600, Matthew D. Fuller wrote: > Hey, guess what; when you delete a window (say, exit an xterm), we > call the Unlink. If the window isn't on the ring (say, you have no > WindowRing stuff enabled in your config, and you never f.ring'd it), > guess what's in next/prev? Turns out _I_ know the answer to that one > now; ask me how I learned it...:p Ha interesting, I had not tested that case! It is actually somewhat surprising, because not *all* windows get put on the ring, even when it's enabled. The workspacemanager and icon manager windows for example. So somehow those cases already miraculously worked... > Matthew Fuller (MF4839) | fulle...@over-yonder.net -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: SloppyFocus
On Mon 08 Mar 2021 at 17:10:58 +0100, Rhialto wrote:
> So it seems that ctwm does something to prevent the default way that focus
> moves, and didn't always move it itself.
Another candidate, close to the place of the previous example:
(tmp_win->w is the actual client window)
> /*
> * Setup various events we want to hear about related to this window.
> */
> {
> unsigned long valuemask;
> XSetWindowAttributes attributes;
>
> valuemask = (CWEventMask | CWDontPropagate);
> attributes.event_mask = (StructureNotifyMask | PropertyChangeMask
> | ColormapChangeMask | VisibilityChangeMask
> | FocusChangeMask
> | EnterWindowMask | LeaveWindowMask);
> attributes.do_not_propagate_mask = ButtonPressMask | ButtonReleaseMask
>| PointerMotionMask;
> XChangeWindowAttributes(dpy, tmp_win->w, valuemask, );
> }
The do_not_propagate_mask now includes PointerMotionMask where it
doesn't in twm.
This also makes no difference. Which makes me wonder why it's needed.
The PointerMotionMask has been there for a long time: since bzr revision
11, i.e. ctwm-3.2p1. This was still by Claude Lecommandeur. It was
checked in into the monotone repository on 2003-02-02. Too bad there are
no detailed change logs from the changes back then...
https://bazaar.launchpad.net/~ctwm/ctwm/trunk/revision/11/add_window.c
-Olaf.
--
___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert
\X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl
signature.asc
Description: PGP signature
Re: Alt+Tab behavior [ now with experimental code on a new branch ]
On Mon 08 Mar 2021 at 13:34:26 -0600, Matthew D. Fuller wrote: > I guess we're post-py2 now, so I should updated the webpage to talk in > terms of brz... I am indeed not so fluent with bazaar/breezy that I am up to date with the latest developments. I am using "bzr qlog" a lot to visualise the history. There is development going on to update this to breezy, python3 and Qt5 (since Qy4 is deprecated too). As far as I could see, the code is there but there is not release of it yet. Maybe there are some details that are still blocking that; I haven't tried it. https://code.launchpad.net/qbrz -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: Alt+Tab behavior [ now with experimental code on a new branch ]
On Tue 29 Dec 2020 at 15:16:10 +0100, Rhialto wrote: > You can still find the branch at > https://code.launchpad.net/~ctwm/ctwm/windowstack > (lp:~ctwm/ctwm/windowstack). I "rebased" this branch because of recent commits to trunk. Bzr doesn't have a "rebase" command, so when I say "rebased", I say "I have painstakenly cherry-picked all relevant commits to a new branch". And when I say "cherry-picked", because bzr also does not have a cherry pick command, I mean "I used a script I randomly found on the Internet". So the branch is now called https://code.launchpad.net/~ctwm/ctwm/windowstack2, because it isn't a rebase but a new branch. Also, some weirdness snuck in (because it was entangled somewhat with the window ring cleanups that are now on trunk) and I had to add an extra commit to fix that. I haven't checked if it needed even more fixups. If history rewriting were a bit easier, I would have combined it with the first commit. There is a "bzr-rewrite" plugin, but it hasn't been updated since 2012 and it doesn't work with Python 3.7. https://bugs.launchpad.net/bzr-rewrite/+bug/1918171 -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: SloppyFocus
On Sun 07 Mar 2021 at 17:20:20 -0600, Matthew D. Fuller wrote:
> On Wed, Mar 03, 2021 at 08:18:59PM +0100 I heard the voice of
> Rhialto, and lo! it spake thus:
> >
> > With the ctwm included in 9.1 (still with SloppyFocus), xev did get
> > mouse events, but its window did not get the focus decoration
> > change. Keyboard events went to the previous window (which had the
> > focus decoration). I'd say that this is a bug compared to later
> > versions.
>
> Well, I dunno what version that is, though
> https://man.netbsd.org/NetBSD-9.1/i386/ctwm.1 lists 3.7. Yow.
Maybe the manual is out of date; /usr/X11R7/bin/ctwm -info says
$ /usr/X11R7/bin/ctwm -info
Twm version: MIT X Consortium, R6, ctwm 3.8.2
Compile time options : XPM USEM4 I18N
> But anyway, xev doesn't set any WM_HINTS, so it'd be 4.0.0 before we
> started forcing focus onto it anyway. So, one _could_ argue that, as
> a program that's there to monitor events, and probably wants keyboard
> events, it's a bug that it doesn't ask the WM for keyboard events
> too... but yeah, current version would be always giving it focus
> anyway.
I tried it with twm (from NetBSD 9.1, and it doesn't report a version
number), and its own default config, and it also gives the xev window
focus.
But it seems it won't call SetFocus() on it if there is no WM_HINTS with
input enabled, or if TitleFocus is not enabled. There must be some
other arrangement for windows to get focus? When there is no window
manager this happens too, after all (even xload seems to get focus, as
far as one can tell anyway). I was hoping to get some enlightenment
from
https://tronche.com/gui/x/xlib/events/input-focus/normal-and-grabbed.html
but that doesn't mention at all what happens as the result of moving the
pointer.
https://tronche.com/gui/x/xlib/events/window-entry-exit/normal.html is
about moving the pointer but doesn't mention focus.
So it seems that ctwm does something to prevent the default way that focus
moves, and didn't always move it itself. I thought It may well be
FocusChangeMask which is set on the window:
/*
* Setup various events we want to hear about related to this window.
*/
{
unsigned long valuemask;
XSetWindowAttributes attributes;
valuemask = (CWEventMask | CWDontPropagate);
attributes.event_mask = (StructureNotifyMask | PropertyChangeMask
| ColormapChangeMask | VisibilityChangeMask
| FocusChangeMask
| EnterWindowMask | LeaveWindowMask);
attributes.do_not_propagate_mask = ButtonPressMask | ButtonReleaseMask
| PointerMotionMask;
XChangeWindowAttributes(dpy, tmp_win->w, valuemask, );
}
where the twm code doesn't include FocusChangeMask.
(this code is from trunk but the 3.8.x code is functionally the same)
However a quick attempt to rebuild the 3.8 code, minus FocusChangeMask,
didn't show any difference. So I'm still in the dark.
I just discovered randomly that GVim (at least the Gtk2 version) is a
WM_TAKE_FOCUS window with no input WM_HINTS; my Firefox too; probably all
Gtk2 and/or 3 windows. That makes them "globally active".
> Matthew Fuller (MF4839) | fulle...@over-yonder.net
-Olaf.
--
___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert
\X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl
signature.asc
Description: PGP signature
Re: SloppyFocus
On Sun 07 Mar 2021 at 18:14:05 -0600, Matthew D. Fuller wrote:
> It's probably not entirely unreasonable to imagine that all the "react
> to focus change" things like decorations etc should be purely in
> HandleFocusX, and SetFocus either (a) should just achieve them via the
> synthesized events, or (2) should call a shared function for them.
Some day...
> But, the details of just what X actually sends are surprisingly
> surprising; I spent a while tracking focus and enter stuff a while
> back when working on somethingorother, and all my dreams of "this is
> The Way X Will Always Signal This, so we can stop half-implementing
> parts of it scattered all over different events" were dashed pretty
> hard, and I decided it was simplest to assume it all worked perfectly
> and pretend I never saw any of that code :|
Yeah I just read the ICCM text on focus that you linked to and that
already is not so enlightening...
> > I re-ordered it like below, and the results are a lot better.
> >
> > if(!Scr->TitleFocus) {
> > if(Tmp_win->wmhints->input) {
> > SetFocus(Tmp_win, ewp->time);
> > }
> > if (Tmp_win->protocols & DoesWmTakeFocus) {
> > SendTakeFocusMessage(Tmp_win, ewp->time);
> > }
> > }
>
> This seems facially reasonable, in light of
>
> > I'm also uncertain about what is meant with "both locally & globally
> > active clients".
>
> This is the ICCCM focus stuff:
> https://www.x.org/releases/X11R7.7/doc/xorg-docs/icccm/icccm.html#Input_Focus
That leads me to moving the code and comments around like below.
I added "passive and" to the first comment, and I took the
SynthesiseFocusIn() in the conditions. It could be called and also
SetFocus(), which would be duplicative. Also this mirrors the code above
better although it doesn't quite match the structure.
if (Scr->TitleFocus) {
if(Tmp_win->wmhints->input
&& Event.xcrossing.focus) {
SynthesiseFocusIn(Tmp_win->w);
}
} else {
if(Tmp_win->wmhints->input) {
/* passive and locally active clients need
help from WM to get the input focus */
SetFocus(Tmp_win, ewp->time);
}
/* must deal with WM_TAKE_FOCUS clients now, if
we're not in TitleFocus mode */
if(Tmp_win->protocols & DoesWmTakeFocus) {
/* for both locally & globally active clnts */
SendTakeFocusMessage(Tmp_win, ewp->time);
}
}
This structure seems more comprehensible. However when I tried to apply
the same structure to the code above (for the frame), the icon manager
focus spoiled it. I could however condense the somewhat verbose
condition
bool icon_manager_focus =
Scr->IconManagerFocus &&
Tmp_win->iconmanagerlist &&
ewp->window == Tmp_win->iconmanagerlist->w;
which was used basically twice.
https://bazaar.launchpad.net/~rhialto/ctwm/fix-sloppy-notitlefocus/revision/677
> But with the matrix as is, we only need the two orthagonal checks;
> Passive and Locally Active would both have wmhints->input set, and
> those are the only cases where we'd want to SetFocus(). And only the
> *Active's will have DoesWmTakeFocus, and only they should get the
> SendTakeFocusMessage(). So the existing comments are correct-ish,
> though probably slightly misleading in that they suggest a diff
> between Locally Active and Passive, in a place where there isn't
> one...
It does seem kind of weird that there is a case where both
wmhints->input and DoesWmTakeFocus are set, so that both
XSetInputFocus() and SendTakeFocusMessage() are called. But I can't read
from the ICCCM docs that it isn't meant that way...
> Matthew Fuller (MF4839) | fulle...@over-yonder.net
-Olaf.
--
___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert
\X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl
signature.asc
Description: PGP signature
Re: Some small cleanups
On Fri 05 Mar 2021 at 17:51:39 -0600, Matthew D. Fuller wrote: > Couple random notes and one slightly bigger: > > - r676, "Add a missing break statement." By my reading, this doesn't > _functionally_ change anything (except maybe a doubled up weird > error message if you mess up your config somehow), just makes the > code flow more proper? Exactly. I think I noticed because I got a weird double message. > - The NULL check removals in the ring manglement funcs. Sounds > reasonably in general, but wanted to be sure you checked it in edge > cases; e.g., if there's nothing in the ring or the like, might we > have NULL's snuck in somehow? I did check edge cases with removing all windows from the ring one by one and adding some back. It turned out that the Occupy Window is also on the ring so it isn't really empty yet when you would think it is. I suspect the window ring used to be a normal doubly-linked list at some time in the past. That would explain the existing checks for NULL. With the factored out adding and removing code, there is also more assurance that NULLs cannot sneak in. > - r681: WindowIsOnRing() should be static? If it stays there, yes, but (see next item) > And the one slightly bigger: > > - AddWindowToRing() and friends should probably live somewhere other > than functions_internal.c, since they're used from code not related > to functions. Pulling in functions_internal.h in non function*.c > files smells a bit. Maybe win_utils.[ch]? 's a bit of a dumping > ground, but maybe it's the right dumping ground? Yes, I wasn't really sure where exactly to put them. functions_internal.h is a bit of a strange header file since it contains declarations for functions in multiple functions_*.c files, including functions_warp.c, which by itself seems like a nice place for window (warp) ring related stuff. But I don't like the inclusion of functions_internal.h much either. Maybe it's worth some new files, win_ring.[ch]. It would be at least as meaningful as clicktofocus.c. I'm adding a revision with this change. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Some small cleanups
While making changes for optionally making the window ring behave like a stack, I came across some things I'd like to merge to trunk anyway. They are in my "small beer" branch: lp:~rhialto/ctwm/smallbeer or bzr+ssh://bazaar.launchpad.net/~rhialto/ctwm/smallbeer/ . Changes can be viewed at https://bazaar.launchpad.net/~rhialto/ctwm/smallbeer/changes If there are no objections I will merge these to trunk in a few days. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: SloppyFocus
After adding lots of tracing intrumentation (printf debugging...) I've
come to the following analysis. If you want to follow along, get the
file event_handlers.c handy, with the function HandleEnterNotify().
This does a lot of stuff first that is not so relevant to our
discussion. Then it gets to
if(Tmp_win->mapped) {
/*
* unhighlight old focus window
*/
/*
* If entering the frame or the icon manager, then do
* "window activation things":
*
* 1.
* 2. install frame colormap
* 3.
* 4. focus on client window to forward typing
* 4a. same as 4 but for icon mgr w/with NoTitleFocus
* 5. send WM_TAKE_FOCUS if requested
*/
Here we have Scr->SloppyFocus is TRUE and Scr->TitleFocus is FALSE.
Let's assume we're having normal windows which accept input, so
Tmp_win->wmhints->input is TRUE.
Windows are first entered in their wrapper Tmp_win->frame, if the mouse
enters further it reaches Tmp_win->w, the application window itself.
Since TitleFocus is false, several things that are normally done on
entering frame should now be done later when entering w.
One thing that happens in this situation is
SynthesiseFocusIn(Tmp_win->w). So my first plan of attack was to also
SynthesiseFocusOut(Scr->Focus->w), the previously focused window.
This plan failed, because HandleFocusOut() ignores these synthetic
messages just like it ignores the real FocusOut message.
Another plan is to duplicate the actions when entering the frame a bit
better (but only when TitleFocus is FALSE).
Here it turns out that SetFocus() is NOT called in this case. That seems
to be because these nested conditions are ordered unfortunately:
/* must deal with WM_TAKE_FOCUS clients now, if
we're not in TitleFocus mode */
if(!(Scr->TitleFocus) &&
(Tmp_win->protocols & DoesWmTakeFocus))
{
/* locally active clients need help from WM
to get the input focus */
if(Tmp_win->wmhints->input) {
SetFocus(Tmp_win, ewp->time);
}
/* for both locally & globally active clnts */
SendTakeFocusMessage(Tmp_win, ewp->time);
}
We have nothing to do with DoesWmTakeFocus so this whole fragment is
never executed. I re-ordered it like below, and the results are a lot
better.
if(!Scr->TitleFocus) {
if(Tmp_win->wmhints->input) {
SetFocus(Tmp_win, ewp->time);
}
if (Tmp_win->protocols & DoesWmTakeFocus) {
SendTakeFocusMessage(Tmp_win, ewp->time);
}
}
This doesn't bring both cases (entering frame and w) in perfect
agreement but it is at least closer.
I've been wondering about the use of SynthesiseFocusIn().
SetFocus() does mostly the same as what HandleFocusOut() followed by
HandleFocusIn() does, plus an actual call to XSetInputFocus(). And those
are the exact functions that get called to handle the synthetic focus
messages. It would be cleaner perhaps to have either one method or the
other but not both.
The code as is may call both SynthesiseFocusIn() and SetFocus(). It
won't hurt since code will check if focus is already set, but I wonder
about the usefulness of SynthesiseFocusIn() in general, and if it is
useful, if it shouldn't always have been a full SetFocus().
I'm also uncertain about what is meant with "both locally & globally
active clients".
A branch with this change (and possibly more as the situation develops)
is at lp:~rhialto/ctwm/fix-sloppy-notitlefocus or
https://code.launchpad.net/~rhialto/ctwm/fix-sloppy-notitlefocus, and a
diff of the change above is attached. I'd like to get some feedback if
this seems a sensible route to take.
-Olaf.
--
___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert
\X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl
revno: 676
committer: Olaf 'Rhialto' Seibert
branch nick: fix-sloppy-notitlefocus
timestamp: Thu 2021-03-04 22:52:41 +0100
message:
Attempt to fix the situation where SloppyFocus is on and TitleFocus is OFF.
This causes that the de-focusing code of the previous window is never call
Re: SloppyFocus
On Wed 03 Mar 2021 at 20:18:59 +0100, Rhialto wrote: > I added SloppyFocus to my config, and xev worked (it printed events > (including mouse and key events) and its window got the proper > decoration for a focussed window). I tried with the most recent code > and with the released version in pkgsrc. Enabling icon managers didn't > change this. With the config in NetBSD 9.1 and trunk ctwm, I did notice some focus weirdness when there was an xload window present. The window decoration for focus isn't that distinctive, but in the icon manager it was clear that several windows could have the "focus" indication at once. This happened if you moved "too fast" from one window to another, and happened even without SloppyFocus. But I don't see a similar effect in my usual config... hm. I do (sometimes, depending on mouse speed it seems) that the focus remains on the previous window if I move into xload. It seems the setting NoTitleFocus (which is in NetBSD's config but not in mine) makes the difference here (for the inconmanager case). I suppose I should look into that. I guess the "focus event lookahead" logic (see HandleFocusChange()) may be contributing here too. NoTitleFocus would change the behaviour when you're crossing the window title or border, I think. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: SloppyFocus
I've had a bit of time to look at code and experiment a bit. On Wed 03 Mar 2021 at 13:51:48 +0100, Rhialto wrote: > I don't use SloppyFocus (just FocusFollowsMouse), and I noticed that for > instance xconsole does't seem to want input focus. And as a result, > keyboard shortcuts for window depth arrangement don't work on it. Oops, I misremembered, that would be xload. You can see it with xprop: WM_CLASS(STRING) = "xload", "XLoad" WM_HINTS(WM_HINTS): Client accepts input or input focus: False Initial state is Normal State. bitmap id # to use for icon: 0x81 I've grepped through the current ctwm source, and I can find the following places where SloppyFocus has an effect: - HandleFocusOut() i.e. when a FocusOut message is received. When SloppyFocus, all processing is skipped. - HandleDestroyNotify() i.e. whena window has been destroyed. When SloppyFocus, focus is placed on some other window. - SetFocus() i.e. when we want to put focus on some window, or on no window. When SloppyFocus and the new window is NULL and the old window is NOT an icon manager: skip all processing. This means that via the icon manager a window CAN lose focus when the new window is the root window, even if SloppyFocus is set. - GotoWorkSpace() i.e. when switching workspaces. When SloppyFocus, "the last window" is focussed. and that's it. I added SloppyFocus to my config, and xev worked (it printed events (including mouse and key events) and its window got the proper decoration for a focussed window). I tried with the most recent code and with the released version in pkgsrc. Enabling icon managers didn't change this. With the ctwm included in 9.1 (still with SloppyFocus), xev did get mouse events, but its window did not get the focus decoration change. Keyboard events went to the previous window (which had the focus decoration). I'd say that this is a bug compared to later versions. When the mouse was in the icon manager, it did get key events (iirc, ctwm forwards those explicitly). If I were to analyze this, I would first start looking in the code for HandleEnterNotify() and HandleLeaveNotify(). The latter has a very big comment blob about various subcases. But based on my findings so far, I think updating the ctwm included with NetBSD would improve SloppyFocus behaviour (and deeply diving into the old version's HandleEnterNotify() seems not so useful at this point). -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: SloppyFocus
On Tue 02 Mar 2021 at 10:16:42 +, nia wrote: > For example, with SloppyFocus enabled programs like xev can never obtain > keyboard focus and focus is not lost when moving the cursor outside of > a window. It is my understanding that SloppyFocus is supposed to be very similar to FocusFollowsMouse, except that the focus is not moved to the root window (and instead it stays on the previous window). The things you mention that differ from that sound like bugs somewhere. Note that there are programs that for whatever reason indicate they dont want to receive focus, and I think that ctwm then faithfully complies (even though most programs should never say such a thing). I don't use SloppyFocus (just FocusFollowsMouse), and I noticed that for instance xconsole does't seem to want input focus. And as a result, keyboard shortcuts for window depth arrangement don't work on it. (Maybe that could be fixed somehow too) But it is weird that the SloppyFocus behaviour would have changed over versions, because I'm not aware of any intentional changes here. Maybe some programs somehow react differently if the "modern" Extended Window Manager Hints are supported. Although for xev, I cannot imagine such a thing... > Anyone know anything about this? It should probably be documented. At the very least, the manual currently doesn't say anthing useful about SloppyFocus. -Olaf. -- ___ Q: "What's an anagram of Banach-Tarski?" -- Olaf "Rhialto" Seibert \X/ A: "Banach-Tarski Banach-Tarski." -- rhialto at falu dot nl signature.asc Description: PGP signature
Re: Alt+Tab behavior [ now with experimental code on a branch ]
On Sun 27 Dec 2020 at 18:51:57 +0100, Rhialto wrote: > So, after some thinking I made a first go at a window ring that behaves > like a stack. I made some small tweaks in the code, and a user-visible change. I noticed that the so-called RingLeader (the window that is the starting point for Modifier-Tabbing) can change when you enter or leave windows[1]. That is no good if you want to see the ring as a stack, since it rotates the stack. So I have designated the Ring pointer, which points to the "start" of the ring, as the fixed starting point. [1] Aside: I would think it should be based on focusing, not mere mouse movement, but that's how it is right now. You can still find the branch at https://code.launchpad.net/~ctwm/ctwm/windowstack (lp:~ctwm/ctwm/windowstack). -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Alt+Tab behavior [ now with experimental code on a branch ]
So, after some thinking I made a first go at a window ring that behaves like a stack. Based on the following observations: - The difference between a window ring and a stack is effective at the moment the modifier key is released. - at modifier-down time, we remember the "top of the stack". - at modifier-up time, we move window we moved to (if any) to the top of the stack. - So if we can do some administrative work both when the modifier is pressed and when it is released, we can make a ring into a stack. - We can already make bindings for pure modifier keys. - All current bindings are for key-down events. - We can make bindings for key-up events if we pretend this is a new modifier. # This makes bindings for the usual window ring: "Tab" = m4 : all : f.warpring "next" "Tab" = m4 | s : all : f.warpring "prev" "Return" = m4 : all : f.ring # This turns the window ring behaviour into a stack behaviour: # Note that the Super key corresponds to modifier 4. "Super_L" =: all : f.warpring "startstack" "Super_L" = up | m4: all : f.warpring "finishstack" You can find a branch at https://code.launchpad.net/~ctwm/ctwm/windowstack (lp:~ctwm/ctwm/windowstack). I guess that's a "ctwm" more than needed but I had to try a few times to get the syntax right and I didn't want to overwrite trunk. There are some things in it that I'm not so happy about yet. - Names of things. startstack and finishstack aren't the best names, but the code in f.warpring looks at the first letter only right now to decide, so I wanted distinct first letters. - I factored out some code to manipulate the window ring (add and remove a window) and I'm not sure in which source file that belongs. - There are probably some edge cases that this code doesn't handle. I tested it lightly and that seemed to work though. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Alt+Tab behavior
On Thu 17 Dec 2020 at 09:09:22 -0500, Steve Litt wrote: > What do you think? We thought about this before, but I couldn't find it quickly, so I'll summarize what I remember from it. The big difference with a window stack is (assuming Alt-Tab as hotkey) is that it does different things depending on when you let go of Alt. For ctwm Alt-down Tab-downup Tab-downup Alt-up is the same as Alt-down Tab-downup Alt-up Alt-down Tab-downup Alt-up because it doesn't look at Alt-only key events (I think [1]). But for the first sequence, you switch to the 2nd window down your stack, and for the second one, you switch to the 1st window on your stack and then back to the original (which is on top of the stack after the first switch). Also, you need to be able to express the difference in the key bindings in some sensible manner. Then the rest is trivial. Patches welcome, I'd say. H if [1] isn't true, or could easily be fixed so that you can write a key binding that matches an Alt-up or an Alt-down specifically, possibly you could get quite far by using f.altkeymap to switch between various states... I didn't try to elaborate on this thought though. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Is there a way to disable edge grab/resize?
On Wed 16 Dec 2020 at 21:17:44 -0500, Ian Primus wrote: > I'm using ctwm 4.0.3, compiled from source. I've spent a fair bit of > time looking at the options available for .ctwmrc, but have not found > a way to disable the behavior of grabbing the edge of a window to > resize it. I could be looking right past it, of course - but I figured > I'd ask the experts. > > Basically, I only want the window to resize if I specifically grab the > resize button and drag it - and to NOT resize when the edge is > grabbed. I keep accidentally grabbing the edge of the window when > clicking the scroll bar, and it would be nice if that wouldn't happen. It looks like it is this line in the default ctwmrc that configures that: Button1 = : frame : f.resize and there are two more lines that configure actions on the frame: Button1 = m : frame : f.move Button2 = : frame : f.raiselower Personally I like this (alhough I changed the mapping a bit), and I have added ``BorderResizeCursors'' to make it more visible. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Not all function keys work in latest ctwm on Fedora 32 [Correction]
On Sun 30 Aug 2020 at 09:28:32 +0100, Aaron Sloman wrote: > > I was working too late when I wrote this: > > > If run in full graphic mode (Level 5), with ctwm as window manager: > > Key pressed: > > F1 F2 F3 F4 F5 F6 F7 F8 F9F10 > >F11 F12 > > > > input characters generated (\^[ = ESC) > > \^[OP \^[OQ \^[OS \^[[18~ \^[[19~ \^[[20~ \^[[21~ > > > > Note that keys F3 F11 and F12 have no effect. This also resembles the difference between "application keypad" mode, and whatever the opposite is called. This was in an xterm, right? Xterm has a menu uption in the middle-mouse menu. Maybe somehow you changed that setting somewhere in one of your config files. (I don't think this theory would explain all differences, but it may explain a few) -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Has anyone managed to get full resolution on new intel cpu?
On Sun 26 Jul 2020 at 10:29:47 -0400, Stefan Monnier wrote: > So your best bet is to try a more recent Linux kernel, You could even try to run the kernel from one distribution on the other. (Don't forget to copy kernel loadable modules or other stuff you need except for the kernel file; I'm not a Linux expert so I'm vague on that sort of details). Generally I expect that such a thing should work; of course you probably lose some tuning/patches from one distro and gain those of the other. In this case, hopefully, better graphics support. > Stefan -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Title bars much too tall after reinstalling linux on laptop
On Sat 11 Jul 2020 at 11:20:58 -0500, Matthew D. Fuller wrote: > Yeah, qbzr hasn't seen any work in a long time. It's never been > updated to QT5, never mind catching up to py3 etc, and I'm sure even > with old QT and py2 it's broken with breezy anyway :| I have opened this bug on qbrz. https://bugs.launchpad.net/qbrz/+bug/1850054 I attempted to get qbrz updated to python 3 and Qt5, but I got stuck on Qt5. I made the patches available but it seems nobody has picked it up to finish. Meanwhile I found what I needed to install additionally for qbzr so at least there I'm fine again. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Title bars much too tall after reinstalling linux on laptop THANKS
On Fri 10 Jul 2020 at 00:30:07 +0100, Aaron Sloman wrote:
> As reported previously, I've compensated for lack of title bars by
> providing more function key actions. One decision I previously reported was
> using F10 (now changed to F4 because of an unnoticed clash) to delete the
> current window.
>
> I later decided that just a function key is is too risky, e.g. if I hit F4
> instead of F3 by mistake, ...
>
> So "delete window" now requires a modifier key + F3.
The solution I found is that my shortcut key opens a pop-up menu with
just one entry, and I have to select that option before it really
deletes the window.
"w" = HRDWNDWMETA : window|title|icon : f.menu "closemenu"
menu "closemenu" {
"Close Window (W)" ("white":"red") f.delete
}
-Olaf.
--
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___ Anyone who is capable of getting themselves made President should on
\X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
signature.asc
Description: PGP signature
Re: Title bars much too tall after reinstalling linux on laptop
On Thu 09 Jul 2020 at 18:29:15 +0200, Tadziu Hoffmann wrote: > Could it perhaps be related to your locale, in that CTWM > chooses the font in some particular encoding that has > different metrics? What happens if you start CTWM > explicitly using the "C" locale, as in > > LANG=C LANGUAGE=C LC_ALL=C ctwm & > > (and whatever else needs to be (un)set)? > Or maybe using Latin-1 (LC_CTYPE=en_US.ISO8859-1)? I was about to suggest the same thing. I think I had some UTF-8 font related changes at some point in the past. Mainly because the UTF-8 fonts contain so many more characters, the maximum ascenders and descenders are a lot bigger than with more limited Latin-1 character sets. I think there was even some code change somewhere in ctwm to compensate for this, but I'm now trying very hard to remember where that was... (and currently `bzr qlog` has broken on my system... claiming it can't find a module named sip, even though I have sip for both python 2.7 and 3.7...) -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: m4 error at startup
On Sat 15 Feb 2020 at 18:26:25 -0600, Matthew D. Fuller wrote: > So, maybe the m4 process is inheriting our SIG_IGN there, and isn't > prepared for that to be the case? You could try commenting out the I suspect you have something there: my manual page for sigaction(2) says: The execve(2) system call reinstates the default action for all signals which were caught and resets all signals to be caught on the user stack. Ignored signals remain ignored; the signal mask remains the same; signals that restart pending system calls continue to do so. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Firefox field autocomplete drop-down menu annoying problem
On Thu 17 Oct 2019 at 11:23:58 -0400, Stefan Monnier wrote:
> In any case, I'm now running with the patch below (i.e. Maxime's but
> without the KDE part, with a few comments added, and using the {...}
> syntax to initialize the array) and it also fixes the problem for me.
Maybe we need some further change to support receiving
_NET_REQUEST_FRAME_EXTENTS ? On the other hand, what we're doing here
now seems to be much like what happens if _NET_REQUEST_FRAME_EXTENTS is
received for every window (we always add the property when a window gets
mapped).
The "specification" isn't entirely explicit on this point. On the one
hand, it says "The Window Manager MUST set _NET_FRAME_EXTENTS" (at
https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472552416
) but then the _NET_REQUEST_FRAME_EXTENTS action "To retrieve such an
estimate [about an unmapped window], the Client MUST send a
_NET_REQUEST_FRAME_EXTENTS message to the root window. The Window
Manager MUST respond by estimating the prospective frame extents and
setting the window's _NET_FRAME_EXTENTS property accordingly. "
(https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472648576)
is rather superfluous...
Maybe they mean that _NET_FRAME_EXTENTS is meant to be set only *after*
a window is mapped, and _NET_REQUEST_FRAME_EXTENTS can request that it
happens earlier. But then they might have mentioned that a bit more
clearly.
> Stefan
-Olaf.
--
Olaf 'Rhialto' Seibert -- rhialto at falu dot nl
___ Anyone who is capable of getting themselves made President should on
\X/ no account be allowed to do the job. --Douglas Adams, "THGTTG"
signature.asc
Description: PGP signature
Re: Firefox field autocomplete drop-down menu annoying problem
On Thu 17 Oct 2019 at 17:53:51 +0200, Bradan J. Wolbeck wrote: > (I have a pair of attachments showing the difference for anyone who hasn't > encountered the issue for themselves.) Thanks, that is illustrative. You can't see it on these pictures, but do you use 3D borders (UseThreeDBorders, or UseThreeDTitles perhaps?) I was thinking that I do not, and several places in the source of ctwm point out that coordinates inside the window are differently organized between 3D and non-3D borders. Maybe this can explain why some people have the problem, and some don't? > Bradan J. Wolbeck -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: Firefox field autocomplete drop-down menu annoying problem
On Thu 17 Oct 2019 at 09:59:19 -0400, Stefan Monnier wrote: > Does anyone know what _NET_FRAME_EXTENTS is supposed to mean? Seems to be described here: https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472552416 > > Stefan signature.asc Description: PGP signature
Re: Firefox field autocomplete drop-down menu annoying problem
On Tue 15 Oct 2019 at 23:41:17 +0200, Maxime Soulé wrote: > I don't know whether you encounter this problem or not, but in my case > (Linux or FreeBSD, with ctwm and without any session manager nor desktop), > the field autocomplete feature of firefox is very annoying as the drop-down > menu of possible completions appears just over the field itself. Interestingly, I don't seem to have that problem. I wonder if there is some setting which makes the difference... I tried your change and fortunately it doesn't suddenly break it for me (I didn't see any change, really). So the addition is fine with me. -Olaf. -- Olaf 'Rhialto' Seibert -- rhialto at falu dot nl ___ Anyone who is capable of getting themselves made President should on \X/ no account be allowed to do the job. --Douglas Adams, "THGTTG" signature.asc Description: PGP signature
Re: 4.0.3 release announcement
On Sun 21 Jul 2019 at 16:52:53 -0500, Matthew D. Fuller wrote: > Welcome to the world, CTWM 4.0.3 release. I saw something about forcing focus on unwilling windows. I also noticed that my xload windows don't get focus any more (the title bar doesn't show it, and my keyboard shortcuts for depth manipulation don't work on it). I guess the second is not intentional, given the first? -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: fullscreen not quite using all the screen
On Wed 24 Jul 2019 at 10:12:29 -0400, Stefan Monnier wrote: > That seems like a bug to me. To me too. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: assertion error "PRI(owl) >= priority" otp.c line 248
On Thu 11 Jul 2019 at 20:15:36 +0200, Rhialto wrote:
> Indeed, I can't reproduce it anymore now with this scenario. I'm pretty
> sure it is the same bug that happened "randomly" before.
but I did find some other scenario that does weird things :-(
It's not an OTP assertion failure but some sort of loop or deadlock or
something.
Scenario: start with fullscreen Xine ("F"), with open on top of that its
Panel window ("P) with its Navigator side-window ("N") with even more
DVD controls. In Xine's Panel you get that window if you click the N in
its bottom right. The problem does not occur without N.
Now, maybe first some focussing on N and P might be needed, or maybe it
is not required. Then with the mouse on F, hit the "f" key to switch
from fullscreen to a normal window.
Now ctwm freezes. F and N get un-painted, but F doesn't change and in
fact no other events seem to have any effect.
I have ctwm running in gdb and that shows nothing weird. But if I
interrupt it and get a stack trace, it is in a location where it ought
not be very long ever (NetBSD now ships with debugging symbols for all
system libraries and programs, so even within X libs there is useful
info):
(gdb) run --replace
Starting program: /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/build/ctwm
--replace
load: 0.21 cmd: ctwm 1719 [select] 0.18u 0.22s 0% 3580k
Program received signal SIGINFO, Information request.
0x76704223e28a in poll () from /usr/lib/libc.so.12
(gdb) bt
#0 0x76704223e28a in poll () from /usr/lib/libc.so.12
#1 0x767041e18b91 in _xcb_conn_wait (c=c@entry=0x76704451f000,
cond=cond@entry=0x767044520128, vector=vector@entry=0x7f7fff5f9c78,
count=count@entry=0x7f7fff5f9c74)
at /usr/xsrc/external/mit/libxcb/dist/src/xcb_conn.c:479
#2 0x767041e16517 in _xcb_out_send (c=c@entry=0x76704451f000,
vector=vector@entry=0x7f7fff5f9cf0, count=count@entry=3)
at /usr/xsrc/external/mit/libxcb/dist/src/xcb_out.c:458
#3 0x767041e16588 in xcb_writev (c=c@entry=0x76704451f000,
vector=vector@entry=0x7f7fff5f9cf0, count=count@entry=3,
requests=requests@entry=819)
at /usr/xsrc/external/mit/libxcb/dist/src/xcb_out.c:406
#4 0x767043e48f76 in _XSend (dpy=dpy@entry=0x76704451d000,
data=data@entry=0x0,
size=size@entry=0) at /usr/xsrc/external/mit/libX11/dist/src/xcb_io.c:486
#5 0x767043e49272 in _XFlush (dpy=0x76704451d000)
at /usr/xsrc/external/mit/libX11/dist/src/xcb_io.c:503
#6 0x767043e6da55 in _XGetRequest (dpy=dpy@entry=0x76704451d000,
type=type@entry=12 '\f', len=len@entry=12)
at /usr/xsrc/external/mit/libX11/dist/src/XlibInt.c:1707
#7 0x767043e290b5 in XConfigureWindow (dpy=0x76704451d000, w=16777841,
mask=mask@entry=96, changes=changes@entry=0x7f7fff5f9e00)
at /usr/xsrc/external/mit/libX11/dist/src/ReconfWin.c:48
#8 0x004220d3 in InsertOwlAbove (owl=0x767044583a40,
other_owl=0x767044583a10)
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/otp.c:483
#9 0x0042420d in OtpFocusWindowBE (oldprio=,
twm_win=0x767044540c00, twm_win=0x767044540c00)
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/otp.c:1675
#10 0x004242b3 in OtpFocusWindow (twm_win=twm_win@entry=0x767044540c00)
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/otp.c:1718
#11 0x0042f8de in SetFocus (tmp_win=0x767044540c00, tim=)
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/win_ops.c:171
#12 0x0000004096b0 in HandleEnterNotify ()
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/event_handlers.c:3304
#13 0x000000408804 in DispatchEvent ()
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/event_core.c:331
#14 0x000000408aa8 in HandleEvents ()
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/event_core.c:203
#15 0x00407eff in ctwm_main (argc=, argv=)
at /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/ctwm_main.c:1055
#16 0x004061ab in ___start ()
#17 0x7670449ed000 in ?? ()
#18 0x0002 in ?? ()
#19 0x7f7fff5fa838 in ?? ()
#20 0x7f7fff5fa86e in ?? ()
#21 0x in ?? ()
(gdb)
Maybe the XConfigureWindow() call has some impossible arguments that are
not caught in Xlib? It looks like a reply never arrives, or maybe there
is a loop of some kind.
One time I caught it at
(gdb) run
Starting program: /mnt/vol1/rhialto/cvs/other/ctwm/bzr/trunk/build/ctwm
load: 0.86 cmd: ctwm 2269 [0x421e16/0] 0.13u 0.09s 0% 3588k
Program received signal SIGINFO, Information request.
XFindContext (display=0x768b6991d000, rid=27264372, context=-1,
data=data@entry=0x7f7fff372c38)
at /usr/xsrc/external/mit/libX11/dist/src/Context.c:252
252 /usr/xsrc/external/mit/libX11/dist/src/Context.c: No such file or
directory.
(gdb) bt
#0 XFindContext (display=0x768b6991d000, rid=27264372, context=-1,
data=data@entry=0x7f7fff372c38)
at /usr/xsrc/external/mit/libX11/dist/src/Context.c:252
#1 0x00432cdc in GetTwmWindow (w=
Re: assertion error "PRI(owl) >= priority" otp.c line 248
On Sat 06 Jul 2019 at 23:34:07 -0500, Matthew D. Fuller wrote: > Sigh. The whole way we look for the transients is wonky, because of > the assumptions it makes about where they already are. So we just > have to expand it and search the whole thing. So, new iteration: the An obvious change here would to link all transients for a window to that window. Although transients for transients (if those would occur) should probably be linked to the "master intransient" (or whatshallwecallit). A less drastic way might be to just add a boolean to each window, indicating if it is a "master intransient" window or not. That would save searching in case it isn't. > === modified file 'otp.c' > --- otp.c 2018-08-19 22:50:13 + > +++ otp.c 2019-07-07 04:23:24 + > @@ -1579,6 +1579,99 @@ The code for OtpFocusWindowBE() could avoid a copy of TryToMoveTransientsOfTo() if that function got an extra parameter: the old_priority, equal to PRI(owl) (or in case of OtpFocusWindowBE(), equal to oldprio). Since it calls PRI(owl) several times, and that is more expensive than it looks, it is even a good thing to turn that into a parameter. There is also less risk that PRI(owl) would change somehow through the list iteration. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: assertion error "PRI(owl) >= priority" otp.c line 248
On Sun 30 Jun 2019 at 18:36:20 -0500, Matthew D. Fuller wrote: > > The change (or lack thereof) in SetFocus() makes no difference at > > all in either case for me. Which seems a strange; a fairly small > > amount of thinking on the matter _does_ suggest it's a thing that > > should be needed, but somehow... isn't? I'll have to think more on > > that. > > FWIW, I figured this out; a little experimentation showed that my > crash happened on the OtpRestack on the _new_ focused window, not the > _old_ being-unfocused window. So it was because of the transient that > wasn't pre-raised to where it was expected. So maybe if your crash > was on the way down, you may also have crashed in that second (when it > wasn't lowered right), in which case the Focus NULL'ing wouldn't make > a different. Or maybe you crashed in the first one somehow, in which > case it would have? Mmph. Lot of moving parts, to keep in the head, > trying to guess... Intersting! My theory so far was that *during* the change of focus, the window depths might be inconsistent. But after OtpRestackWindow()ing the newly focused window, it should be finished, and all consistent and happy. That was consistent with my crash between the two calls to OtpRestackWindow(). My change was also based on that idea. So far I haven't turned on debugging to print all restacking operations, but maybe it is time for that... and we might find out that everything is different... -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: assertion error "PRI(owl) >= priority" otp.c line 248
On Wed 26 Jun 2019 at 21:56:07 -0500, Matthew D. Fuller wrote: > So, the solution to _a_ problem (maybe not yours) is that we need to Looking at my test case (Xine), it has indeed a small window with playback controls, and it is also a transient of the main window (fullscreenable). WM_NAME(STRING) = "xine Panel" WM_TRANSIENT_FOR(WINDOW): window id # 0x52002ff With xprop(1) I noticed that it ALSO has _NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_TOOLBAR which sounds weird to be, but it definitely complicates window stacking! I didn't get a reliable way to get the crash. I just noticed it mostly seemed to occur if I was switching to another workspace while the main window fullscreened, or when switching away from fullscreen mode. I didn't take notice of any other windows. I guess I'll experiment a bit more. > reposition even the 'small' transients up to the top of the stack, > letting the 'small' just determine whether they get jammed on top of > the main window or not. Hopefully I can experiment more in the next > few days... My first impression, after reading your description, was that we have found different problems. But now that my Xine Panel window turns out to be transient as well, maybe it's the same one, or at least more related than I thought. It is a fairly small window. But when taking focus away from the main window, it also changes the calculated proper position of the panel window. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
assertion error "PRI(owl) >= priority" otp.c line 248
I have been using a video player recently that uses full-screen windows,
the kind that get promoted all the way to the top as long as they have
focus.
I have also seen lots of the asserts from $SUBJECT recently, while I was
interacting with such a window.
I think I finally found out what's wrong, while running ctwm from a
debugger.
First, the stack trace (transcribed by hand since I didn't run the
debugger in an xterm, of course). Most recent call at the bottom.
HandleEnterNotify() event_handlers.c line 3301
SetFocus() win_ops.c line 168
OtpRestackWindow() otp.c line 1578
OtpCheckConsistency() otp.c line 200
OtpCheckConsistencyVS() otp.c line 248
assert()
The code in SetFocus() around the call site looks like
(do stuff with SetFocusVisualAttributes() and AutoSqueeze())
163 Scr->Focus = tmp_win;
164
165 #ifdef EWMH
166 /* Priority may change when focus does */
167 if(old_focus && OtpIsFocusDependent(old_focus)) {
168 OtpRestackWindow(old_focus);
169 }
170 if(tmp_win && OtpIsFocusDependent(tmp_win)) {
171 OtpRestackWindow(tmp_win);
172 }
173 #endif
174 }
and otp.c:
1571 void
1572 OtpRestackWindow(TwmWindow *twm_win)
1573 {
1574 OtpWinList *owl = twm_win->otp;
1575
1576 RemoveOwl(owl);
1577 InsertOwl(owl, Above);
1578 OtpCheckConsistency();
1579 }
1
The first call to OtpRestackWindow() would eventually call the failing
assert(PRI(owl) >= priority) in OtpCheckConsistency() but after it has
already fixed its target.
Now PRI here looks innocent, but in reality it is defined as
#define PRI(owl) OwlEffectivePriority(owl)
In other words, it calls a function that dynamically determines window
priority, possibly depending on which window has focus.
But which window that is, is just changing. Suddenly there may be one or
two windows in the stacking order which are in the wrong place. When we
check consistency after adjusting the first candidate (old_focus), the
second candidate (tmp_win) may still be wrongly stacked, causing the
assertion failure.
Now I'm trying to convince myself that the following code change is
necessary and sufficient:
163
164 #ifdef EWMH
165 /*
166 * Priority may change when focus does: do PRI calculation
167 * on old_focus and tmp_win while it doesn't have focus.
168 */
169 Scr->Focus = NULL;
170
171 if(old_focus && OtpIsFocusDependent(old_focus)) {
172 OtpRestackWindow(old_focus);
173 }
174
175 Scr->Focus = tmp_win;
176
177 if(tmp_win && OtpIsFocusDependent(tmp_win)) {
178 OtpRestackWindow(tmp_win);
179 }
180 #else
181 Scr->Focus = tmp_win;
182 #endif
Does anybody has ideas about that?
I'm running with this now, and I'll see if I have more of these
problems.
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power
\X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond
signature.asc
Description: PGP signature
Re: [Branch ~ctwm/ctwm/trunk] Rev 632: Fixup dryrun and improve error on signal.
On Sun 21 Oct 2018 at 21:58:23 -, nore...@launchpad.net wrote: > modified: > tools/try_all_opts.pl Nice! The first thing I did was to add /usr/X11R7/include /usr/pkg/include to the default @INCDIRS. Then I could use all of the options that it can realistically test on my machine: USE_EWMH USE_JPEG (found in /usr/pkg/...) USE_M4 USE_XPM (found in /usr/X11R7/...). Indeed I don't have rplay installed. All 16 combinations built without complaints. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
Re: The one improvement I'd like on ctwm
On Mon 08 Oct 2018 at 20:40:55 -0400, Steve Litt wrote: > Contrastingly, ctwm keeps the windows on a given workspace in a ring > buffer. This requires two different keystrokes: One to navigate > clockwise, and one to navigate counterclockwise. For whatever reason, > even after 2 months using specially created hotkeys for these > circular navigations, I couldn't get my muscle memory to work with the > 2 key solution. The window manages that keep a stack instead of a ring also have 2 different key bindings for forward and backward, but the second one isn't used much, typically. Usuallt ALT-TAB and SHIFT-ALT-TAB. I just looked at the code, and in principle it isn't hard to change the ring into a stack. Adding an option to do it is just a bit more work. BUT: it would be useless. Other window managers keep some kind of box open as long as you keep the ALT (or for me WINDOWS) key down. You can press TAB several times. When you finally let go of ALT, the then-selected window is really made active, and pulled to the top of the stack. But ctwm doesn't work like that. Every time you hit the key combination, it immediately switches to the next window in the ring. If you pull that one out to the "top", you'd simply keep switching between two windows. MAYBE if we can link an event to "letting go of ALT", that could be bound to a new action that modifies the ring to behave like a stack. But I haven't looked yet how easy or hard that would be. But if it is possible it would be a nice configuration flexibility. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- "What good is a Ring of Power \X/ rhialto/at/falu.nl -- if you're unable...to Speak." - Agent Elrond signature.asc Description: PGP signature
http://olduse.net/ (or nntp.olduse.net)
http://olduse.net/ (or nntp.olduse.net) currently has in comp.windows.x several articles about twm, including a 3-part posting of what might be the first version :-) -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Focus problems with firefox (and possibly others) possibly fixed
On Sat 05 May 2018 at 22:07:21 +0200, Rhialto wrote: > The real window wasn't actually gone(!!!) In the workspace where I moved > it to, it kept behaving like a non-painting fullscreen window, > inhibiting any redraws. Even though I'd kill -9'ed mplayer. I reverted my ctwm version to 612, and this weird behaviour remained. So it's not the focus handling fix that makes this happen, it really must be something in mplayer. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Focus problems with firefox (and possibly others) possibly fixed
On Sat 05 May 2018 at 20:24:05 +0200, Rhialto wrote: > I have no idea if the following is related to this change (I can think > of no real correlation except in time), but in the last several days the > following happened to me twice: It's even a bit weirder. It is happening more now... > 1. I was watching something with mplayer, full-screen. That uses the >EWMH fullscreen feature of being on top when focused. > 2. Xscreensaver kicked in, fading out the screen to black. > 3. For some reason, when that happens there is always a short hickup in >playing. I never checked it in detail but I suspect some window >blocks the screen, similar to when (c)twm draws a window outline > 3. I moved the mouse to stop the screensaver. > 4. The screensaver ended but mplayer didn't continue playing. Apparently it is not timing sensitive, something may have changed in mplayer (I recently rebuilt all my packages). Mplayer stops playing as soon as xscreensaver puts up its own window. And even when I (try to) type into mplayer to make it continue (either its fullscreen window or the xterm it runs in), it doesn't. >The window stayed fullscreen and blocked everthing else in the >workspace. When switching to the workspace, nothing was (re)drawn so >it looked as if I was still in the previous workspace. > 5. I moved the fullscreen mplayer window to a different workspace >(to get access to the xterm where mplayer was running from) and >killed mplayer. > 6. Strangely enough, the window did not disappear from the workspace >manager, even though its corresponding real window was gone. The real window wasn't actually gone(!!!) In the workspace where I moved it to, it kept behaving like a non-painting fullscreen window, inhibiting any redraws. Even though I'd kill -9'ed mplayer. > 7. After a while, apparently while I was writing this email, it turned >out that the mini-window was gone anyway. I didn't notice when it >happened. It doesn't always take the same amount of time. I thought at some point that it was just the workspace manager window lagging reality; perhaps it would update itself if a new window appeared. But that wasn't it. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Focus problems with firefox (and possibly others) possibly fixed
On Sun 29 Apr 2018 at 19:09:31 -0500, Matthew D. Fuller wrote: > > > I've got a change up in a branch at [...] > > Landed in trunk now. I have no idea if the following is related to this change (I can think of no real correlation except in time), but in the last several days the following happened to me twice: 1. I was watching something with mplayer, full-screen. That uses the EWMH fullscreen feature of being on top when focused. 2. Xscreensaver kicked in, fading out the screen to black. 3. For some reason, when that happens there is always a short hickup in playing. I never checked it in detail but I suspect some window blocks the screen, similar to when (c)twm draws a window outline 3. I moved the mouse to stop the screensaver. 4. The screensaver ended but mplayer didn't continue playing. The window stayed fullscreen and blocked everthing else in the workspace. When switching to the workspace, nothing was (re)drawn so it looked as if I was still in the previous workspace. 5. I moved the fullscreen mplayer window to a different workspace (to get access to the xterm where mplayer was running from) and killed mplayer. 6. Strangely enough, the window did not disappear from the workspace manager, even though its corresponding real window was gone. 7. After a while, apparently while I was writing this email, it turned out that the mini-window was gone anyway. I didn't notice when it happened. The timing of step 3 seems to matter, since 1-3 happen quite often without causing a problem. I also don't remember that it happened before. Maybe this is even an issue in XQueryTree(). The workspace manager quite oftten calls this to update itself. (I had plans to change that, so that it uses the internal OTP list, but never got around to it so far) -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Focus problems with firefox (and possibly others) possibly fixed
On Fri 20 Apr 2018 at 22:43:05 -0500, Matthew D. Fuller wrote: > So it turns in my best understanding that we actually need to be a > little smarter about how we interpret the Leave events and shift the > focus up to the root. I've got a change up in a branch at > <https://code.launchpad.net/~fullermd/ctwm/focus> which fixes things > for me. Some broader testing would be good; especially from people > running with multiple Screen's (:0.0, :0.1, etc; not Xinerama-ish > mode), since that has its own case with Leave's. I'm running it now; indeed I notice that the weirdness with the Firefox URL bar is fixed! From the description, I'd guess that ctwm was receiving a Leave message with NotifyNonLinear when Firefox was moving the focus was moving from its main window to the dropdown. But that isn't a case which is affected in the change. So I guess there is something I'm still missing. > This seems to be a "bug" (at least very bad interaction) that goes > all the way back to twm :) We should make a one-issue website about it and give this bug a cool name! Something like FocusDown, or SpectreFocus or something ;-) -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Multiple monitors, VirtualScreens and/or Xrandr
> > - ability for a window to be in several workspaces (as it is already > > possible), but at different positions (add a functions family to zoom/move > > on current workspace only + reset position); On Tue 03 Apr 2018 at 09:55:54 -0400, Stefan Monnier wrote: > Along the same lines, a window that's in screen 0 could only belong to > workspaces of screen 0 and not to workspaces of other screens (so > there's never a situation where you might need to display a given window > at two different places at the same time). Of course, displaying > a given window at several places at the same time might be reasonably > easy to do by "compositing" but I don't know if anyone is up to making > ctwm do it. Something with compositing might be possible, but then you probably still have one "real" workspace where the window really belongs and some "fake" ones. Windows have exactly one parent (except the root window) and I don't think we can get around that completely. It is precisely the "exactly one parent" restriction that adds annoying complexities to the Virtual Screens. Every time a window is about to be shown in some workspace, ctwm must make sure that that is the only parent for the window, and reparent it if needed. On the other hand, having separate sets of workspaces for differently sized screens appeals to me. In particular if we adopt the idea of allowing a window to have a different location in each workspace (which should not be too difficult to add, I think[1]. Then you can still drag windows from one group of workspaces to another. The problem that the position might be inconvenient or out of frame doesn't occur then. One can even think that if you have, say, 3 displays, where 2 of them are the same size, that those 2 share one set of workspaces and the differently-sized display has the other set. [1] Currently the window is XMapWindow()ed when it newly appears on-screen. Just before that, it can be moved to the desired position. The rest is just keeping track of locations. > Stefan -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Accessing gnome utilities via ctwm in Fedora27
On Sat 31 Mar 2018 at 10:49:47 -0400, Steve Litt wrote:
> On Fri, 30 Mar 2018 23:38:24 +0100
> Aaron Sloman <a.slo...@cs.bham.ac.uk> wrote:
> > Would it be possible for CTWM users to extend the functionality
> > of .ctwmrc with an environment section, e.g., by analogy with 'Color:'
> >
> > Something like:
> >
> > Environment_extensions:
> > {
> > XDG_CURRENT_DESKTOP GNOME
> > PATH ...
> > }
> >
> > so that all commands invoked will from ctwm will have the required
> > environment-extensions.
>
> I'd argue against doing this on general principle, because what it's
> really doing is complexifying ctwm ...
What you can do instead: in the script where you call ctwm, change it to
XDG_CURRENT_DESKTOP=GNOME ctwm ...the usual args...
Setting a shell variable on the command line before the command
basically exports it only to that command, and has no effect on the
shell's own environment and later commands.
This is true, I think, for at least the bourne-shell-like shells; if it
doesn't work, the same effect can be had with the env command:
env XDG_CURRENT_DESKTOP=GNOME ctwm ...the usual args...
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X
\X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly.
signature.asc
Description: PGP signature
Re: Multiple monitors, VirtualScreens and/or Xrandr
On Fri 30 Mar 2018 at 12:54:23 -0400, Stefan Monnier wrote:
>
> >> Could add an option to automatically provide the VirtualScreens thingy
> >> based on the xrandr monitor information?
> >> It wouldn't fix those quirks, clearly, but it might encourage people to
> >> use VirtualScreens and in turn to try and fix them.
> > If we want to go this way, we have to define clearly what VirtualScreens
> > should provide.
>
> I was thinking of having a new option such as
>
> VirtualScreensViaXRandR
>
> which would behave as if you had written a VirtualScreens { ... }
> section with one virtual screen per monitor.
>
> > At this time, sharing the same config file for different
> > size screens is for example de facto problematic (workspace manager
> > position and other geometry settings).
>
> I think you're referring to yet-another-problem with VirtualScreens.
> I agree that there are probably lots of problems to solve there, but
> that seems independent from the introduction of VirtualScreensViaXRandR.
I think VirtualScreens were meant only for use on several screens of the
same size. A main feature is that the same workspace might be shown on
any of the monitors, which clearly only works sensibly if they are all
the same size.
But I like the option to set them up automatically if the XRandR info
shows that the screen configuration is appropriate.
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X
\X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly.
signature.asc
Description: PGP signature
Re: CMake Failure - no rule to make ctwm.1.xml on OpenSuSe Leap 42.3
On Sun 14 Jan 2018 at 23:21:38 +, Mowgli Assor wrote: > I will say though that one behavior I saw (briefly before CTWM > crashed) was that where before (3.8) I had a nice little box in the > lower right labelled "one" "two" "three" and "four" for my different > desktops, those were replaced with pictographs of what's running on > them. This kind of defeats the purpose of me labelling them in the > .ctwmrc file, and is fanciness that I'd rather be able to toggle in > what should be a relatively simple desktop manager. Additionally I now > have to guess where to click for another desktop, because anything > that doesn't have something running on it is blank - and that makes it > a big blank box to start. If that's something that can be toggled and > turned off, and the old behavior (of labelled desktops) returned I'd > appreciate that. That, is, I think, a changed default for the StartInMapState setting. Or you can press the CTRL key while the window has focus. > But the big problem is the crashing. I'm not a big fan of Ubuntu, but > will switch to it if I have to to get reliable CTWM behavior. That's > really all I want out of this. I am doing this on an older Toshiba > Portege m750 which is my default hardware platform. This one claims to > have a "Centrino vPro" inside, but the CPU on these things actually > varies a bit (most are Core2 Duos or something of that vintage). Ctwm could really be crashing, or as another possibility, it could fail an internal consistency check and terminate "voluntarily". Do you have a file .xsession-errors, or something similar, possibly, in your home directory? It may contain a message from ctwm. For me, for instance, despite that it is really quite well tested, in the last year I got one or two instances of the following: assertion "PRI(owl) <= PRI(other_owl->above)" failed: file ".../ctwm/bzr/trunk/otp.c", line 449, function "InsertOwlAbove" I just got it "randomly", but if you get it consistenly, there must be some pattern we could find. And perhaps you get some other message. If you don't find anything here, another option could be to run ctwm from inside the debugger (gdb) and try to find out what happens when it terminates. > - Mowgli -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Trouble upgrading to 4.0.1
On Sun 14 Jan 2018 at 05:27:31 -0600, Matthew D. Fuller wrote: > (Also WBNI other people could give a quick whirl, just to be sure it > doesn't have surprising side effects. I don't expect any.) I haven't tried it yet but it looks good to me. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Three focus concepts
On Sat 18 Nov 2017 at 22:21:05 +, Aaron Sloman wrote: > Would it help to modify the iconmanager so that in addition to showing > which windows are open and which shut it also shows which one has the > focus, e.g. using a colour change, selectable by user, as happens in the > workspace manager when I move around workspaces? (Using CTRL+L or CTRL+R) At the risk of telling you something you already know (but want differently), it already does that. The focused window has a thicker black border than the unfocused windows. Of course it may not be such an obvious marking, depending on colours. Indeed something like changing colours might be a nice addition. Now that I'm looking at the icon manager anyway, another thing that might be nice if its order reflected the window ring order, or that of the yet-to-be-created window LIFO order. Or if you could rearrange the order of the window-icons inside it by mouse or by f.functions. (Not that that would be trivial, since the icon managers of the different workspaces have a weird interdependent data structure and the code to update it is weird and hard to comprehend). > Aaron -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Three focus concepts
Hi Steve, just a quick reaction to one part of your mail: On Sat 18 Nov 2017 at 15:17:25 -0500, Steve Litt wrote: > DUAL FOCUS > -- > As far as I know, this never happens for people who operate ctwm with > their mice. It's a keyboard thing. Sometimes, when a new window pops up > or an old (that was on top) goes away, you get a situation where one > window appears to have focus according to its colors and on-toppedness, > but another window receives the keystrokes. Sometimes the colors and > on-toppedness tell different stories. I *think* what you describe is similar to or the same as somehting that was mentioned earlier in this mailing list. Sometimes, apparently, the focus is not on the window that looks like it should have the focus. Note that the window decoration is (or should be) authoritative for that. The window on top does not need to have the focus! (Or more accurately, the window that gets the focus does not need to be brought to the front: see options such as AutoRaise, ClickToFocus and RaiseOnClick). Anyway, when window decoration and focus disagree, that's a bug, plain and simple. We haven't been able to pinpoint it so far, though. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: ctwm 4 is hiding X client titles
I like the extra window names, and I want more :-) I see that the "TWM Icon Manager" has nameless subwindows so there is room for expansion :-) -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: f.gotoworkspace doesn't work for me
On Wed 30 Aug 2017 at 04:43:21 -0400, Steve Litt wrote: > I set meta 7 to be f.gotoworkspace "7", but pressing meta 7 didn't Is your workspace named "7"? Mine are named "One", "Two", "Three", etc. Like on one of the example rc files. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/falu.nl -- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Who the heck uses HOSTNAME?
I do use (or rather did use) SERVERHOST: dnl WINDOWMETA is the window manager meta key: dnl windows if available, Alt otherwise. dnl HRDWNDWMETA is optional, and can only be the windows key. dnl Use this if it would interfere with application keys if it were Alt. ifelse( SERVERHOST, [moon], [define(WINDOWMETA, m1)], [define(WINDOWMETA, m4)])dnl define(HRDWNDWMETA, m4)dnl My one display, "sun" (it was a Sun 3/50) had more keys on its keyboard than the other, "moon" (it was a HP 700 dedicated X terminal with pc keyboard). And my key bindings are in terms of WINDOWMETA and HRDWNDWMETA. But that was a long time ago... -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Multiple monitors, VirtualScreens and/or Xrandr
On Tue 13 Jun 2017 at 04:25:23 -0500, Matthew D. Fuller wrote: > My gut says that _doing_ the right thing probably isn't that hard; the > tricky thing will be doing it in all the right places. I don't know > much about the whole vscreen/xinerama/etc implementation, but from > what I've seen I think it's probably pretty hard on the "quick" > side of things. > > A lot of things probably only appear to work by accident due to the > rather simple model when the rule is "everything's a giant rectangle". > Change that model, and I'll bet we'll find all _sorts_ of bizarre > schrodinbugs coming out of the woodwork... should be great fun :) Well we'll just HAVE to try it out! :-) -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Problem with OccupyAll
On Fri 14 Apr 2017 at 15:19:07 +0100, Aaron Sloman wrote: > The problem seems to be that regex_match in file list.c is too general. Try adding ^ and/or $ into the regex, for start and end if string. Without that, regex matches are often allowed anywhere in the string (although some people disagree with that and program things differently; usually one operation is called a regex match and the other a regex search). > aaron -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Flippin' defaults
On Tue 07 Mar 2017 at 23:58:40 -0600, Matthew D. Fuller wrote: > - OpaqueMove and OpaqueResize. The former dates back to twm; the > latter came in with ctwm 1.1. The main reason these are non-default > is performance; they make the server work a lot harder to keep up. > That's why they're so slow and choppy visually, and pretty much make > everything else on the system grind to a halt when you use them. In fact, the drawing of the outlines is done with the display (b)locked, so it will prevent all other programs from painting. Another reason to prefer the opaque versions. (Yes I used to have a Sun 3/60 as X display, and later a HP 700 X server, and there outlining was useful, but today not so much any more). > - StartInMapState. This is probably partially as it is for I think that in the beginning I was not even aware of the Map state. Only when I pressed the CTRL key accidentally when in the button window I discovered it. Note that permanently switching the state doesn't need to use f.setmapstate / f.setbuttonsstate / f.togglestate. Pressing CTRL while the workspace manager has focus, and only releaseing it when it lost focus, is a good way to switch. > - RandomPlacement. I'll bet there are old twm-heads who want to > manually place every window that comes up and not be able to do > anything else until they do. But I'd give good odds there are a > zarking lot more on the other side. And like the above, it exists > in pretty much every config file I can find out in the world. In fact, if the manual placement comes up while a screen locker is active (at least with xscreensaver) ctwm goes in a busy loop while it is trying to display the frame. > Comments? Agreements? Arguments? Torches and pitchforks? Cake? Looks good to me. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Using two displays
I have in the past pondered a bit about making ctwm's root window resizable (which is currently explicity not supported, I think). Given the existence of xrandr it is easy for users to add/remove monitors, or change resolution, or rotate the screen, all of which changes the root window. But so far, nothing concrete has come from it. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Summer of ctwm
On Wed 02 Nov 2016 at 03:26:59 -0500, Matthew D. Fuller wrote: > So, consider this my What I Did This Summer report. Congratulations! That is a serious amount of work, and we appreciate it! -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Problems with JabRef
On Mon 26 Sep 2016 at 12:32:04 +0200, Alexander Klein wrote: > The real trouble starts with JabRef 3.4, which requires OpenJDK 8 and won't > do a thing most of the time when trying to type in the web search dialogue. What if you run the older jabref with the newer jdk? Maybe that experiment can establish in which of the two the problem is. The jabref command is just a shell script containing #! /bin/sh exec /usr/pkg/bin/openjdk8-java -jar /usr/pkg/lib/java/JabRef-2.10.jar "$@" so you can simply use that, adapting the paths you need and the version combinations you want to try. Where did you get JabRef 3.4 from? My version comes from http://sourceforge.net/projects/jabref/files/jabref/2.10 . I found 3.6 at https://sourceforge.net/projects/jabref/files/v3.6 . I tried $ /usr/pkg/bin/openjdk8-java -jar ./JabRef-3.6.jar and I got 13:06:39.048 [AWT-EventQueue-0] WARN net.sf.jabref.JabRefGUI - There seem to be problems with OpenJDK and the default GTK Look Using Metal L instead. Change to another L with caution. I don't know what problems it's referring to, but it looked like the Swing I'm used to, and web search seemed to work. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Problems with JabRef
On Fri 23 Sep 2016 at 12:59:18 +0200, Alexander Klein wrote: > %xev -id 0x133 ... > The strangest thing ? to me ? is that not a single KeyPress event is > generated when typing text in the dialogue, but only when typing over the > X-Background with keyboard focus still on the Jabref-window, but then again, > I'm certainly not an X-pert. ;) Could it be somehow that the dialogue is not a child of the main window of which you are tracing the events? That would of course be rather unusual, but not impossible. For instance if it were a separate toplevel window that is unmanaged by the wm (much like dropdown menus are) and kept positioned in the right place above the main window. If the windows were separate that way, it could sort-of explain weird focus problems. Firefox had weird depth effects with its pull down menus at some time, for instance (fortunately they fixed it; I have no idea what the actual problem was). -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Ctwm startup advice
On Mon 12 Sep 2016 at 10:21:52 +0100, Aaron Sloman wrote:
> It turns out that if I manually kill firefox then later restart it, it does
> restore its state. So I've now altered my .xinitrc so that just before it
> exits it kills firefox ('killall firefox'). Presumably simply exiting X
> does something like 'kill -9' which doesn't give it a chance to save a
> record of open windows and tabs.
I have found a few times that if you close the Firefox window, it
forgets all the tabs in it (optionally it warns you for that with a
pop-up). But if I Quit firefox (via the menu or Control-Q) it remembers
them.
I am guessing from this that exiting X will do the equivalent of closing
the Firefox window, instead of choosing its Quit function.
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly.
signature.asc
Description: PGP signature
Re: Menus and building (was Re: menus stay where first activated (on XQuartz))
On Tue 26 Jul 2016 at 18:09:17 -0700, Greg A. Woods wrote: > So, ctwm will now be included in > future releases of NetBSD in the default base X11 install. And hopefully, when we get to do a new fully revamped release, that will be taken on too. > As you can see it's mostly lists of filenames and a few other settings. One thing that really helps for the conciseness of the BSD Makefiles is that when building for a NetBSD base system, it is simply known what facilities are available, and where they are, so there is simply not any kind of system inspection needed to find that out. And that is usually the complex bit. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Vivaldi has no frame
On Fri 08 Jul 2016 at 14:07:25 +0200, Frank Steiner wrote: > Worse... Even with that option there is still no title so that I > cannot define a warpto shortcut etc. Many (all? I did not look it up) of the lists of window names also accept class names. Each window doesn't just have a name but also a class. You can find it with xprop and look for WM_CLASS, such as WM_CLASS(STRING) = "lxterminal", "Lxterminal". > They also don't support normal X11 parameters like -title, -geometry > etc. Of course, since the developers don't stick to conventions at all, they may e failing in the WM_CLASSS department too. I wonder how difficult it might be (and how useful) to generalise window lists to be able to match on any string-like window property. > Dipl.-Inform. Frank Steiner Web: http://www.bio.ifi.lmu.de/~steiner/ -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: menus stay where first activated (on XQuartz)
On Fri 17 Jun 2016 at 00:05:19 -0500, Matthew D. Fuller wrote:
> --
> === modified file 'menus.c'
> --- menus.c 2014-05-09 13:48:53 +
> +++ menus.c 2016-06-17 04:44:26 +
> @@ -1638,6 +1638,7 @@
> MenuDepth++;
>
> if (Scr->Root != Scr->CaptiveRoot) {
> +fprintf(stderr, "CAPTIVE %s\n", menu->name);
>XReparentWindow (dpy, menu->shadow, Scr->Root, x, y);
>XReparentWindow (dpy, menu->w, Scr->Root, x, y);
> } else
>
> --
I agree that that `if' there is kind of suspicious. Menu windows get
created as children of Scr->Root already.
Maybe Scr->Root changes when "virtual screens" are involved (it has been
a while, I'd need to recheck that) but if so, this check still seems
wrong. (It might change because with virtual screens, 2 or more
workspaces are visible at the same time and they each have their own
"root" window, which is different from the "real" root window).
The manual page I have doesn't say it isn't allowed to reparent a window
to the parent it already has. But it also doesn't say that in that case
the move to (x,y) happens. It is imaginable that an X server might
simply do nothing (not even the move) if the parent doesn't change.
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X
\X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly.
signature.asc
Description: PGP signature
Re: menus stay where first activated (on XQuartz)
On Tue 07 Jun 2016 at 18:19:05 +0200, Rhialto wrote: > By the way, the first time I tried it, XQuartz miserably fails with > xeyes. (Somehow it seems to work better now). So I don't expect it to be > perfect and anything that goes wrong may easily be an XQuartz problem. Ah, on the second try it fails again. When you move and/or resize the xeyes window, it doesn't properly refresh its displayed bits. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: menus stay where first activated (on XQuartz)
[wo...@planix.com removed from To: because his mailer doesn't like my mailer] On Sun 22 May 2016 at 19:07:41 -0700, Greg A. Woods wrote: > when a native OSX Xquartz compiled ctwm-3.8.2 runs locally How do you run ctwm locally on the Mac? At work I have XQuartz too but if I try to start ctwm I get $ ./build/ctwm --replace ./build/ctwm: another window manager is already running on screen 0? ./build/ctwm: unable to find any unmanaged screens By the way, the first time I tried it, XQuartz miserably fails with xeyes. (Somehow it seems to work better now). So I don't expect it to be perfect and anything that goes wrong may easily be an XQuartz problem. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- Wayland: Those who don't understand X \X/ rhialto/at/xs4all.nl-- are condemned to reinvent it. Poorly. signature.asc Description: PGP signature
Re: Something seems seriously wrong...
On Sun 19 Jul 2015 at 11:42:13 +0200, J.O. Aho wrote: I have had the impression that the Gnome stuff was for Gnome 1.x and it's not been supported since RedHat 8, so if I'm right, shouldn't that code be removed? That was my impression. As far as I know the Extended Window Manager Hints were designed to completely replace the Gnome stuff and everybody who implemented that now implements EWMH. That's why I disabled the Gnome stuff when I implemented EWMH. //Aho -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpbntkG0CbUs.pgp Description: PGP signature
Re: [Branch ~ctwm/ctwm/trunk] Rev 397: Merge fixes that get compile working fine and (almost) warns clean on
On Sun 19 Jul 2015 at 09:03:20 -, nore...@launchpad.net wrote: Make use of glibc's features.h to properly set defines we need, since -std=c99 make it stricter. modified: Yes I find that terribly annoying. Conflating language features and library features is less than optimal I think. There ought to be separate options for that. (I think the same problem exists when you -D one of those POSIX defines, but it was a while ago that I tried and I never tried it since.) NetBSD's libc is much more sensible in this. -std=c99 enables the language features of C99 but doesn't disable the POSIX and NetBSD (etc) functions. Why one would want to disable POSIX when compiling something on a POSIX system I don't know. As far as I'm aware they are not forbidden by the C standard, merely extensions. A workaround is to use -std=gnu99, but that also enables the GNU extensions to the language. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpXyMQHN9UOl.pgp Description: PGP signature
Re: SloppyFocus prevents focussing
On Sat 27 Jun 2015 at 17:03:04 -0500, Matthew D. Fuller wrote: On Sat, Jun 27, 2015 at 04:53:06PM +0200 I heard the voice of Dario Niedermann, and lo! it spake thus: I still think that - if the other WMs let users focus the window anyway - ctwm probably should too. I wouldn't per se rule it out. I just wouldn't want to do it offhand without being fairly sure of the implications (and it would take a little care in a ctwm-internals sense to avoid side effects). Doesn't the ICCM say explicitly that a window should ask for focus and otherwise it won't get it? See http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.7 : It discusses the WM_HINTS and WM_TAKE_FOCUS' presence in the WM_PROTOCOLS property: The four input models and the corresponding values of the input field and the presence or absence of the WM_TAKE_FOCUS atom in the WM_PROTOCOLS property are listed in the following table: Input Model Input Field WM_TAKE_FOCUS -- --- - No InputFalse Absent Passive TrueAbsent Locally Active TruePresent Globally Active False Present Passive and Locally Active clients set the input field of WM_HINTS to True , which indicates that they require window manager assistance in acquiring the input focus. No Input and Globally Active clients set the input field to False , which requests that the window manager not set the input focus to their top-level window. The original test program would be the No Input case, and the modified one Passive. What Locally Active semantically means exactly doesn't become quite clear to me... -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgpEbMSWSusrY.pgp Description: PGP signature
Re: RFC: EWMH Desktop windows.
If we had such a generic redirection facility, then we could use it to
redirect events sent to the Desktop window to the Root window.
Good idea! When I get back I'll try to make a little program for it.
I did a little test, and for some reason I could not catch any
keystrokes from the Desktop window on a Xubuntu system. If I tried
listening in on a terminal window, that worked fine. Maybe it needs more
than just an XSelectInput() to get input in the general case?
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
/*
* Forward key and mouse button events from one window to another.
*
* This is useful to use a Desktop window as a Root window.
*/
#include stdio.h
#include stdlib.h
#include X11/Xlocale.h
#include X11/Xlib.h
char *ProgramName;
Display *dpy;
int screen;
static void
usage(void)
{
static const char *msg[] = {
-display displaynameX server to contact,
-id windowiduse existing window,
-root use root window,
-name stringwindow name,
,
NULL
};
const char **cpp;
fprintf(stderr, usage: %s [-options ...]\n, ProgramName);
fprintf(stderr, where options include:\n);
for(cpp = msg; *cpp; cpp++) {
fprintf(stderr, %s\n, *cpp);
}
exit(1);
}
int
main(int argc, char **argv)
{
char *displayname = NULL;
int i;
Window w;
XWindowAttributes wattr;
long event_mask;
int done;
Window ws[2]; /* from-window, to-window */
int wi = 0;
char *name;
ProgramName = argv[0];
if(setlocale(LC_ALL, ) == NULL) {
fprintf(stderr, %s: warning: could not set default locale\n,
ProgramName);
}
w = 0;
for(i = 1; i argc; i++) {
char *arg = argv[i];
if(arg[0] == '-') {
switch(arg[1]) {
case 'd': /* -display host:dpy
*/
if(++i = argc) {
usage();
}
displayname = argv[i];
continue;
case 'i': /* -id */
if(++i = argc || wi 1) {
usage();
}
sscanf(argv[i], 0x%lx, w);
if(!w) {
sscanf(argv[i], %lu, w);
}
if(!w) {
usage();
}
ws[wi++] = w;
continue;
case 'n': /* -name */
if(++i = argc || wi 1) {
usage();
}
name = argv[i];
continue;
case 'r':
switch(arg[2]) {
case 'o': /* -root
*/
if(wi 1) {
usage();
}
ws[wi++] = -1;
continue;
default:
usage();
}
continue;
default:
usage();
} /* end switch on - */
}
else {
usage();
}
} /* end for over argc */
dpy = XOpenDisplay(displayname);
if(!dpy) {
fprintf(stderr, %s: unable to open display '%s'\n,
ProgramName, XDisplayName(displayname));
exit(1);
}
screen = DefaultScreen(dpy);
if(ws[0] == -1) {
ws[0] = RootWindow(dpy, screen
RFC: EWMH Desktop windows.
On the ewmh branch (https://code.launchpad.net/~rhialto/ctwm/ewmh) I've
just added code to support Desktop and Dock windows in a limited way.
(EWMH = Extended Window Manager Hints, see
http://standards.freedesktop.org/wm-spec/wm-spec-1.5.html )
If you use Ctwm with, say, Xubuntu, the Desktop window (that's the one
that has the file and directory icons on it) is now automatically at the
lowest priority, and has no title and border. (You can replace *buntu's
wm with ctwm --replace )
However, this limits access to your key/mouse bindings on the Root
window. If you have a binding to move or iconify a window without
needing a window border
(I use this:
DontShowWelcomeWindow
Function move-or-lower { f.move f.deltastop f.lower }
i = m4 : window|title|icon : f.iconify
Button1 = m4 : window|icon : f.function move-or-lower
)
then you can get the Desktop window out of the way and access the root
window and its bindings.
That's however a bit inconvenient. I was trying some other kludge to
treat a Desktop window much like the Root window, for purposes of
bindings. It doesn't work so well, so if you want to try it you'll have
to find and uncomment /* #define EWMH_DESKTOP_ROOT */.
I'm hoping to get some input on how to do this better. Hopefully some of
you can try it and offer suggestions.
-Olaf.
--
___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
pgpDbKScJGyFA.pgp
Description: PGP signature
Re: Windows being repositioned wrong...
On Wed 28 May 2014 at 12:43:07 +0200, Richard Levitte wrote: (is this a problem in other wms?)? Yes, as far as I can see. I have a netbook with an old Ubuntu (from 2010 or so), and every time I start VLC, its initial location shifts down and right - by the size of the title and left border, as far as I can see. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- The Doctor: No, 'eureka' is Greek for \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.' pgppTwuB9FWmq.pgp Description: PGP signature
