bugGNU Octave - Bugs: bug #50637, The GUI raises itself into...

 
 

bug #50637: The GUI raises itself into foreground upon clicking a button

Submitter:  Lars Kindermann <larskindermann>
Submitted:  Sat 25 Mar 2017 07:21:15 PM UTC
   
 
Category:  GUI Severity:  1 - Wish
Priority:  3 - Low Item Group:  Feature Request
Status:  Fixed Assigned to:  None
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sat 08 Jan 2022 07:08:11 PM UTC, comment #7: 

Fixed in bug #61770. This can be closed now.

Lars Kindermann <larskindermann>
Sun 16 May 2021 06:21:34 PM UTC, comment #6: 

I added a screenshot of xfce's focus settings dialog.

The setting I use is just "focus follows mouse".
No autorise when getting focus.
No rise on click.

Would be great if Octave could inherit this settings from the desktop.


Lars Kindermann <larskindermann>
Sun 16 May 2021 05:54:51 PM UTC, comment #5: 

"Focus follows mouse" for docked widgets has actually been implemented now as an option in settings now in 7.0.0 dev.

But the drawback is that when activated, Octave will immediately rise itself to the top, when the mouse just moves over the window.

To bring a window to the top should normally be left to the window manager to ensure consistent behavior on the desktop. See comment #3.

Lars Kindermann <larskindermann>
Wed 13 Nov 2019 11:24:40 PM UTC, comment #4: 

It has become somehow better now (as of Nov 2019) because clicking the "Run" button will not send other windows to the back anymore.
The only button that still does is "toggle breakpoint".

However, a gui setting to make widgets behave according to a "focus follows mouse" policy is still desirable.

Lars Kindermann <larskindermann>
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:


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)

Lars Kindermann <larskindermann>
Sun 26 Mar 2017 08:48:21 PM UTC, comment #2: 

Regarding "focus follows mouse" I found an open request in Qt:

QTBUG-47594: Add focus follows mouse option for widgets
https://bugreports.qt.io/browse/QTBUG-47594

Once it is resolved there, it should be very easy to make it work in Octave, too.

Lars Kindermann <larskindermann>
Sat 25 Mar 2017 11:10:06 PM UTC, comment #1: 

+1

I have "focus follows mouse" also on Windows. Doesn't work inside Octave, though. It does work for undocked panes.
So the "focus follows mouse" behavior should be mimicked inside the main GUI window, i.e., a Qt thing.

FYI, Matlab behaves exactly like Octave.

Philip Nienhuis <philipnienhuis>
Group Member
Sat 25 Mar 2017 07:21:15 PM UTC, original submission:  

I always use the following settings for any desktop environment and window-manager:

- Focus follows mouse
- Clicking into a window will not bring it to the top

However, the Octave GUI will always make itself the topmost window as soon as you klick several of the buttons, like Run or press F5. But any well behaved program should leave this decision to the window-manager for a consistent desktop behaviour.


Another issue is that the GUI itself should be able to act according to the "focus follows mouse" setting internally, too. I.e. setting the focus automatically to the pane under the mouse. Many programs behave like this, other won't. So this is rather a feature request than a bug. But for anybody adapted to the "focus follow mouse" behaviour, it would make live a lot easier. As it is definitely pretty difficult to obtain the focus setting from all different window managers and desktop environments automatically, I opt rather for a new setting in the GUI preferences.

Lars Kindermann <larskindermann>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #40166:  remove_raise.diff added by larskindermann (650B - text/x-patch)

 

Digest:
   bug dependencies.

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by pantxo (Updated the item)
  • -email is unavailable- added by larskindermann (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 11 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-01-09 pantxo StatusNone Fixed
        Open/ClosedOpen Closed
        Dependencies- Depends on bugs #61770
    2021-05-16 mtmiller Carbon-CopyRemoved 80942 -
    2021-05-16 larskindermann Attached File- Added Focus-Settings.png, #51446
    2017-03-27 larskindermann Attached File- Added remove_raise.diff, #40166
        Attached File- Added remove_raise_and_activate.diff, #40167
    2017-03-25 philipnienhuis Operating SystemGNU/Linux Any
    2017-03-25 mtmiller Severity3 - Normal 1 - Wish
        Priority5 - Normal 3 - Low
        Item GroupNone Feature Request

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code