octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #50637] The GUI raises itself into foreground


From: Lars Kindermann
Subject: [Octave-bug-tracker] [bug #50637] The GUI raises itself into foreground upon clicking a button
Date: Mon, 27 Mar 2017 04:34:57 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/56.0.2924.76 Chrome/56.0.2924.76 Safari/537.36

Follow-up Comment #3, bug #50637 (project octave):

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:


w->setFocus ();
w->activateWindow ();
w->raise ();


and in terminal_dock_widget.cc:


setFocus ();
activateWindow ();
raise ();


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)
    _______________________________________________________

Additional Item Attachment:

File name: remove_raise.diff              Size:0 KB
File name: remove_raise_and_activate.diff Size:0 KB


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?50637>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]