FVWM mod-tab fix

The mane problem with window creation is most programs create multiple windows & they're not grouped.  So mod-tab is going to flip windows in the same program.  Of the programs lions use, only a text editor & browser create 1 window.  There's a need to properly cycle through multiple windows when the program creates multiple windows & flip a single window when the program creates 1 window.

Window creation calls HandleMapRequestKeepRaised 

Window destruction calls HandleUnmapNotify -> __restore_focus_after_unmap

The trick with these functions is they expect the previous focus in the start of the window list while mod-tab expects the previous focus in the end of the window list.  The easiest solution was to make a swap_windows function to move previous focus to the bottom of the list.  Then, they all have to reset the state of mod_released.  Using swap_windows in __handle_click_to_focus also fixes window selection.

This probably won't work with multiple desktops.  Lions haven't used multiple desktops since CDE.  It's been a 3x3 virtual desktop for 27 years.

The big question was if swapping CirculateUp & CirculateDown in system.fvwm2rc would achieve the same thing.  Attempts in this direction have not been successful.  It seems to require different but equally diabolical hacks.

Helas, the current behavior is still not very reliable.  Modeless dialogs might throw it off.  Lions just remember alt-tab in CDE being 100% reliable & using it all the time.

The hacked source code is on https://github.com/heroineworshiper/fvwm_hack

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.

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

Like most programs for its time, FVWM uses bare X11 calls everywhere.  It has a minimal widget library for users:  modules/FvwmScript/Widgets/.

It's 1 of those programs which reuses the same function name in many files.

The entry point for alt/mod-tab is events.c: dispatch_event ->

events.c: __handle_key

functions.c: __execute_function("Next") ->

conditional.c: CMD_Next -> conditional.c: circulate_cmd ->  conditional.c: Circulate

It needs to know if mod/alt was released before the current event.  If it was released, it needs to toggle windows instead of advance.  It only detects tab being released.

The display is opened & the input flags are set in fvwm/fvwm.: XOpenDisplay(display_name)

Keypress events come from the root window & go to libs/FEvent.c: FNextEvent

For some reason, the program windows detect mod/alt release but not the root window.  Verified all the key event flags are set.  The only internet hit recommended creating a thread that polls XkbGetState in its own display.  XkbGetState had to be polled at least 20 times per second in testing to detect every mod key release.

The next problem was creating a table which translates many state variables including the mod key release to a new circulate direction.  That got it to circulate properly for the 1st time. 

The next problem was clicking on a window to raise it & getting mod-tab to go to the previously raised window.  FVWM never did this properly even before the hack.

The lion kingdom has been using FVWM on Linux for over 27 years now.  It's the lion form of retro computing.  They might have been some of the 1st retro computing fans, before any computing was really old enough to be retro.  

The lion kingdom picked FVWM because it was the window manager on SGI & it was efficient.  It made a cheap PC look like an expensive SGI.  In those days, SGI was something else because only they did a good job with multimedia.  The trick to getting all that hardware support in those days was a more capable operating system like UNIX, so the 1st multimedia was all in UNIX.

FVWM always had a few problems:

alt-tab never alternated between 2 windows.   It only cycled 1 way.  You had to remember if the last action was alt-tab or alt-shift-tab to alternate.  This has been the mane productivity drag for the last 21 years.

Windows can no longer be always on top.

alt-click no longer moves the window to the front.

Lions did everything they could with the config files.  The next step is to try to make it work in the source code instead of config files.  The mane files are in fvwm-2.6.8/fvwm/  The mane problem with fixing it in source code is you have to run it in an ssh connection to another machine.  It's a lot of work for just 1 key.

The lion kingdom's 1st window manager & the one which will always be affiliated with a high end workstation is CDE.  It's been open source for some time.  The docker panel was utterly worthless & took up a lot of space.  None of the default programs were ever used.  The file manager was horribly slow.  It was however smooth & expensive.

Conspicuously, the screenshots on kiwipedia show none of today's common programs: a browser, app store, word processor, settings, & ads.  They still show what UNIX supported 25 years ago, manely a command line with a graphical border & no ads.