Mon 27 Mar 2017 08:34:56 AM UTC, comment #3:
Regarding to the bug, that Octave always raises its terminal window to top, even if it shoudn't according to the window manager settings, I located the relevant code. But fixing it does not really solve it at the moment, because there is a similar bug in the underlying Qt lib, too.
The code to transfer focus can be found in octave_dock_widget.h:
and in terminal_dock_widget.cc:
The raise() does not belong there and is surplus, as activateWindow() should handle all necessary stuff by itself and conform to the X11 window manager settings as stated in the Qt documentation:
http://doc.qt.io/qt-4.8/qwidget.html#activateWindow
Thus, raise() should only be used if one deliberately wishes to make a window topmost, regardless what the window manager policy is, e.g. to display a splash screen. It should be removed here.
But in fact Qt's activateWindow() currently seems not to care about any focus and autorise setting of of the Linux desktop, contrary to the documentation: it always raises the window to top by itself.So removing raise() in Octave will not change anything at all at the moment. One should file a bug to Qt.
But removing both activateWindow() and raise() from Octave produces the correct behaviour for my settings and - as far as I can see - does not change behaviour in most other scenarios, except this one: Working in an undocked editor and pressing F5 or clicking the "run" button will not bring the terminal to front but stay inside the editor. What is the intended behaviour for Octave in this case?
I suggest to remove at least the raise() from Octave, which does not change anything at the moment but - just in case Qt will be fixed one day - eventually will make it behave more cooperatively within the desktop settings.
Additionally removing activateWindow(), too, would be preferred by me, as setFocus() alone seems to perform all neccessary actions and makes Octave obey the window manager settings. But we should consider what the majority of users really expects when pressing F5.
Why do I care about this and consider it important, even if not a true "bug"? Personally - spending several hours per day in the GUI at the moment and being used to work with the perhaps untypical but nevertheless fully legit "focus follows mouse" and "no autorise" settings - I found myself typing into the wrong Octave window a thousand times at least. And in general, I think programs should comply to desktop standards as close as possible and not enforce their own specific behaviour. It's a question of design philosophy.
Attached are two patches to tryout, one removing raise(), the other removing also activateWindow().
(file #40166, file #40167)
|