Desktop windows and focus

Configuration General Questions
1

I have some interest in using file managers that draw a desktop over the root window, like Caja, with FVWM, but when I try it, I end up with undesirable focus behavior. I want strict FocusFollowsMouse, but the desktop provided by Caja does not take focus unless it is clicked, which results in windows not under the mouse retaining focus if the mouse leaves it without entering another non-desktop window. This is typical “focus follows mouse” behavior in various other window managers and desktop environments, probably by design, but I want to find out if there is a way to fix the issue from FVWM’s end. Caja’s desktop window information looks like this:

FvwmIdent

Name:				x-caja-desktop
Icon Name:			x-caja-desktop
Class:				Caja
Resource:				desktop_window
Window ID:			0x5400006
Desk:				2
Xinerama Screen:		1
Layer:				0
Width:				3840
Height:				1920
X (current page):		0
Y (current page):		0
Boundary Width:		0
StickyPage:			Yes
StickyDesk:			Yes
StickyPageIcon:		No
StickyDeskIcon:		No
NoTitle:				Yes
Iconified:				No
Transient:				No
WindowListSkip:		Yes
Gravity:				NorthWest
Geometry:				3840x1920+0+0
Focus Policy:			Locally Active
	- Input Field:		True
	-WM_TAKE_FOCUS:	Present
EWMH Window Type:	Desktop

xwininfo

xwininfo: Window id: 0x5400006 "x-caja-desktop"

  Absolute upper-left X:  0
  Absolute upper-left Y:  0
  Relative upper-left X:  0
  Relative upper-left Y:  0
  Width: 3840
  Height: 1920
  Depth: 24
  Visual: 0x2b
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x5400005 (installed)
  Bit Gravity State: NorthWestGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsViewable
  Override Redirect State: no
  Corners:  +0+0  -0+0  -0-0  +0-0
  -geometry 3840x1920+0+0

I am also looking through the Caja source code to see if it sets up anything to prevent focus on mouseover going to the desktop, but I’m not familiar enough with this issue yet to know whether it’s the deliberate work of Caja, a side effect of the applicable EWMH, or something else. Any advice will be appreciated.

2

I found something from fvwm/ewmh.c:1377 that looks relevant:

/* ClickToFocus, I do not think we should use NeverFocus */ FPS_FOCUS_CLICK_CLIENT(S_FOCUS_POLICY(SCF(*style)), 1); FPS_FOCUS_CLICK_CLIENT(S_FOCUS_POLICY(SCM(*style)), 1); FPS_FOCUS_CLICK_CLIENT(S_FOCUS_POLICY(SCC(*style)), 1); FPS_GRAB_FOCUS(S_FOCUS_POLICY(SCF(*style)), 1); FPS_GRAB_FOCUS(S_FOCUS_POLICY(SCM(*style)), 1); FPS_GRAB_FOCUS(S_FOCUS_POLICY(SCC(*style)), 1);

This is in the ewmh_HandleDesktop function, and it looks like desktop windows are being hardcoded as click to focus. I am currently trying to change it to mouse focus, although so far all I have succeeded in doing is making it so that a click on the desktop window doesn’t focus it either. Is there any background available on why desktop windows are being set this way?

3

After taking a break from this I came back to it and found what I was looking for. The issue is not in ewmh.c but in events.c’s HandleEnterNotify function. When the mouse enters an EWMH desktop window, HandleEnterNotify is returned from early, here, before any focus changes can happen. Excise the return and everything goes on as desired.

[code]
— fvwm/events.c.orig 2018-11-30 06:26:39.981171000 +0900
+++ fvwm/events.c 2018-11-30 06:26:48.101171047 +0900
@@ -2255,7 +2255,6 @@
BroadcastPacket(
MX_ENTER_WINDOW, 3, (long)Scr.Root, (long)NULL,
(long)NULL);

  •   return;
    }
    if (ewp->window == FW_W_FRAME(fw) ||
    ewp->window == FW_W_ICON_TITLE(fw) ||[/code]

I have a feeling that users of desktops and of FVWM do not intersect much, but I’ll leave this here in case anybody else is trying to use both with MouseFocus. It appears that for whatever reason, when EWMH support was first added to FVWM, it was hardcoded to do sloppy focus with desktops. I would be interested in hearing some historical context for that decision, but here is the fix, anyway.