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, &attributes); } 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
