Graphical commands entered in AnalysisWindow change focus to VisualizationWindow

[esternin]

Using the same v.4.6.2 AppImage, which was compiled and assembled under RHEL7, produces different behaviour under Ubuntu 20.04, and RHEL7 itself or Chromebook's Debian/xwayland.

Commands entered on the command line that effect changes to the Visualization Window (as simple as clear or set aspectratio 8.5/11, and any other that draws something on the canvas) under RHEL7 or on a Chromebook result in a shift of focus to Visualization Window. The cursor remains positioned over the Analysis Window but the window itself is out-of-focus. To continue entering commands requires a mouse click inside the Analysis Window.

This does not occur under Ubuntu 20.04, running the same appimage, the focus remains on the Analysis Window. In both cases (RHEL7 and Ubuntu) the behaviour is seen under xfce4, with "focus follows mouse" set. As an alternative to a mouse click, a mouse shift out of and back into Analysis Window also returns the focus to the command line entry field.

[esternin]

This is a consequence of a setting. To fix in xfce:

• Window Manager Tweaks
  • Focus
    • When a window raises itself: Do nothing

Chromebook (i.e.xwayland) fix currently unknown, but since it's not an eXtrema issue, I'm closing it.

[vadz]

FWIW I think the code shouldn't call Raise() in the first place, so IMHO it's still a bug in Extrema. The trouble is that this was my first thought and I grepped the code for the occurrences of Raise() and while there are a lot of them, none of them seems to actually end up in wxFrame::Raise(). But I must have overlooked something...

In any case, AFAICS most, if not all, of these Raise() functions in Extrema code are simply not needed at all, I don't really know what are they doing there.

[esternin]

I suspect the logic went like this: on a crowded screen, AnalWin overlaps/partially covers the VisWin, you make a graphical change, you may want to bring it out forward - though not to give it focus! - so that the results can always be seen. This works well with "focus follows mouse" mode, as the AnalWin becomes now partially obscured by the VisWin, yet your typing of commands can continue without needing to move a mouse.

I suspect the origin of this thinking is in the VT640 terminals with text and graphics overlaid right on top of one another that were the mainstay of the first decade or more of the program, and one needed to be able to, for example, clear each independently of the other. Plotdata/physica had a clear and an aclear commands for that. In a script, you would typically write

...
graph x,y
aclear
pause

which would clear the alpha "layer" before offering a pause (actually the command was called terminal back then, not pause) prompt on the first line of the cleared text screen, not obscuring any of the graphics layer underneath with text echoes of previous commands.

But! Raise() means "bring to front", it does not mean "...and switch focus to" in this approach, while others clearly think the two are necessarily connected and make wm associate one event with the other.

I still have not figured out how to fix that on a Chromebook, as xwayland is a different beast, has no equivalent settings manager (in the Google version of xwayland) and gsettings (gnome/gtk) does not report any setting that looks remotely like "shift focus on raise" switch in xfce.

[esternin]

My Chromebook received an OS update, and now the same appimage works normally, not shifting the focus to VisWindow.

I did set gsettings set org.gnome.desktop.wm.preferences focus-new-windows 'strict' instead of the default 'smart', but this is not really something that should have mattered.

The only issue on Chromebook is that it does not remember the placement of windows from run to run, always placing them both centered on the screen. It sort of remembers the size of VisWin, but AnalWin grows a bit with every re-launch (start, and immediately quit). But these are only a minor distraction, although I could chase them down. "Process Command" is still too tight for the text in it, if I do not override it with an explicit wxSize reset. But that's the only label that does that, so I am not sure what is different about it. Maybe, there is a wx bug of not determining the string width correctly if the string has spaces in it?