Lions are aware than when the pendulum finally forces the last X11 software out entirely, FVWM is going to become pretty useless.  It might also be fast enough through the emulation layer, but the traditional path would be to run as close to the metal as possible.  It's not obvious if all 2D graphics aren't already being done in a texture & if they are, why it would matter if X11 was done through emulation.  It probably would matter for high resolution & frame rate video.

-------------------------------------------------------------------------------------------------------------------------------

FVWM has 2 variables which seem intended for correct mod-tab behavior: ScreenFocus, LastScreenFocus.  LastScreenFocus is no longer used.  ScreenFocus gets updated all the time.  Functions like CMD_FlipFocus are further evidence of a past mod-tab behaviour that worked.

The focus order is determined by a doubly linked list of FvwmWindow which presumably is updated every time a window is raised.

The 1st entry in the list is fixed & probably the root window.

It's normally updated properly when clicking on a window.  The 2nd entry is the focused window.  Mod-tab rolls the entire list except for the 1st entry forwards or backwards.

After cycling with mod-tab, clicking on a window does not update the linked list properly.  The previously focused window doesn't go to the last entry but goes to a random entry in the list.  __handle_click_to_focus is the entry point

set_focus_window 1089 fw=0x25d1820 LastScreenFocus=(nil)
dump_windows 78
     0x6d2760 (null)
    *0x25d1820 Heroine
     0x25bc010 Heroine
     0x25d54f0 Heroine
     0x25d3670 Heroine

User clicks on 0x25d54f0 so 0x25d1820 should go to the last or 3rd position, but

__handle_click_to_focus 1581 fw=0x25d54f0
set_focus_window 1089 fw=0x25d54f0 LastScreenFocus=(nil)
dump_windows 78
     0x6d2760 (null)
    *0x25d54f0 Heroine
     0x25d3670 Heroine
     0x25d1820 Heroine
     0x25bc010 Heroine

It swaps places with the new window's last position, 4th position, where the next mod-tab can't access it.  It needs to go to the last position so the next mod-tab can access it.  It only happens when the new window isn't the last window.  The easiest hack is repositioning the previous window when __handle_click_to_focus finishes.

That got it to work, but the order of the windows after clicking on many windows in succession is still non deterministic.

The implication of this is the user opens a dialog box, the dialog box closes & focus goes back to the program, the user goes to another window & mod-tab doesn't go back to the program anymore.  That's a job for proper window ordering.

Another problem is after opening a new program, mod-tab doesn't go back to the previous window.  Starting a text editor & flipping back to the console is a big deal.

--------------------------------------------------------------------------------

If the user taps & releases mod without tab, that's another potential failure.  It seems to be benign, since getting to that state requires releasing mod anyway.

------------------------------------------------------------------------------------