bugGNU Octave - Bugs: bug #53600, Use convention Qt event handling...

 
 

bug #53600: Use convention Qt event handling for consistent octave_dock_widget focusing

Submitter:  Dan Sebald <sebald>
Submitted:  Tue 10 Apr 2018 05:38:41 AM UTC
   
 
Category:  GUI Severity:  3 - Normal
Priority:  5 - Normal Item Group:  Other
Status:  None Assigned to:  None
Originator Name:  Open/Closed:  * Open
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 21 May 2018 06:56:30 AM UTC, comment #11: 

@Dan: I have tested the patch and - depending on the widget having focus - some of the actions (Ctrl+number) for switching to another widget does not work.

Beside this, I am still not convinced of the necessity or the benefit of replacing the focus () by focusInEvent (). Whereas focus () is called for explicitly setting the focus, focusInEvent () is also executed when the user changed focus via mouse (where focus () was not involved so far). Finally, the focus proxies were added for giving specific objects within the dock widget focus when this widgets get focus.

Torsten Lilge <ttl>
Group Member
Tue 15 May 2018 10:54:42 AM UTC, comment #10: 

Please keep in mind that there is an influence to focus bahaviour of different window managers and user settings, too.

Especially on Linux users often have a "focus follows mouse", "no autorise" and no "click to rise" combination of window manager settings.

There are two things to keep in mind when implementing own focus strategies:

Things may work different on some systems, see bug #53890.

The other thing is to not break user settings. You should not bring windows to top in general, it is the responsibility of the window manager. Also setting the focus forcefully into another window breaks the focus follow mouse setting.


Lars Kindermann <larskindermann>
Sun 13 May 2018 08:38:49 PM UTC, comment #9: 

I've updated this patch because of some rejected hunks.  However, this doesn't seem to fix the issue of undock-then-dock an octave_dock_widget not having the focus/highlight.

(file #44149)

Dan Sebald <sebald>
Fri 11 May 2018 11:58:31 PM UTC, comment #8: 

Yeah, that focus proxy has me perplexed.  I wish the Qt documentation would give a better illustration of the idea so one knew exactly what the rules are.

Dan Sebald <sebald>
Fri 11 May 2018 06:54:38 PM UTC, comment #7: 

After some tests with an approach using setFocus() and the focusInEvent() I remember why this is not working robustly for our structure. The setFocus() does not always triggers the event. This maybe depends on the currently set focusProxy. An extra routine like focus() solves this by carrying out all required actions for the dock widget to become visible and the top level widget of the main window.

Torsten Lilge <ttl>
Group Member
Thu 03 May 2018 04:34:39 PM UTC, comment #6: 

Yes, that is correct.  I would say that "getting rid of tabData usage in VE" is unconventional in the sense that we are digging into the Qt code to figure out how it works rather than going by what is written in the Qt documentation.  Similarly, focusInEvent(), et al. are the conventional Qt routines compared to the added focus() routine.

Dan Sebald <sebald>
Tue 01 May 2018 07:32:25 AM UTC, comment #5: 

This means, this report is about two different topics: 1) getting rid of tabData usage in VE, and 2) using reimplemented focus events instead of the focus () method in octave_dock_widget. Is this correct?

Torsten Lilge <ttl>
Group Member
Sat 14 Apr 2018 05:11:20 PM UTC, comment #4: 

It's in the patch designed to bring the V.E. tab to the front when calling "openvar x":

https://savannah.gnu.org/bugs/download.php?file_id=43836

The idea of this bug report is to move away from using tabData() in such a way by simply reusing the code that already achieves that for some other feature.

As for the recursion, I recall Qt documentation stating one has to be a bit careful with the focus routines because recursions easily occur, depending on how the window manager works I would guess.

Dan Sebald <sebald>
Sat 14 Apr 2018 02:29:59 PM UTC, comment #3: 

What do yo mean by "but the routine focus_command_window() has a more straightforward method"? focus_command_window () is also just calling command_window->focus (). The focus routine is merely a replacement of the setFocus method.

Searching in all files, I only see the use of tabData in the old webinfo.cc doc-browser, which is not used anymore. Where is it used for handling octave_dock_widgets?

Torsten Lilge <ttl>
Group Member
Fri 13 Apr 2018 03:28:25 PM UTC, comment #2: 

This changeset needs a bit of work.  Testing along with a different bug patch, this can get into a recursive focus under certain conditions.  I'll come back to this one later.

Dan Sebald <sebald>
Tue 10 Apr 2018 07:16:33 AM UTC, comment #1: 

It happens that octave_dock_widget currently has a virtual method "focus()" which in theory serves the same purpose as Qt QWidget focusInEvent() handler.  So I propose moving the contents of focus() to an overridden focusInEvent() and then inherently make use of that code in all octave_dock_widget objects simply by issuing the standard setFocus() method.  Changeset attached.

Note that I removed most of the setFocusProxy() from the objects inheriting octave_dock_widget.  The focus behaved better that way because with that proxy in place the focusInEvent never occurred.  (I suppose that is why someone put the ->focus() virtual function in the code, to ensure that it is always called.)  The thing to do if one needs to ensure some child in a octave_dock_widget derivative gets the focus is to override and add to focusInEvent(), some examples of which are already in the code.

(file #43865)

Dan Sebald <sebald>
Tue 10 Apr 2018 05:38:41 AM UTC, original submission:  

In the fix for Bug #53443 the solution for bringing non-command-window octave_dock_widgets (i.e., variable_editor) to the front, even if a tabbed QDockWidget.  The code utilizes some undocumentated tabData() of QTabBars.  It works, but the routine focus_command_window() has a more straightforward method that utilizes conventional Qt methods.  The goal is to reuse such code with other octave_dock_widgets.

Dan Sebald <sebald>

 

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

Attach Files:
   
   
Comment:
   

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by larskindermann (Posted a comment)
  • -email is unavailable- added by ttl (Posted a comment)
  • -email is unavailable- added by sebald (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-05-13 sebald Attached File- Added octave-eliminate_focus_and_tab_to_front_functions-djs2018may13.patch, #44149
    2018-04-10 sebald Attached File- Added octave-eliminate_focus_and_tab_to_front_functions-djs2018apr10.patch, #43865

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code