bugGNU Octave - Bugs: bug #53836, Clicking a QDockWidget tab in a...

 
 

bug #53836: Clicking a QDockWidget tab in a stack does not activate the associated widget

Submitter:  Dan Sebald <sebald>
Submitted:  Fri 04 May 2018 06:08:38 PM UTC
   
 
Category:  GUI Severity:  1 - Wish
Priority:  3 - Low Item Group:  Unexpected Error or Warning
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
   

Fri 11 May 2018 11:55:16 PM UTC, comment #4: 

It certainly would seem that way, but I think I've found a way that doesn't require the tabData information (see attached).  It's a bit kludgy in the sense that


+              tbar->setCurrentIndex ((index + 1) % tbar->count ());
+              tbar->setCurrentIndex (index);


i.e., selecting some other tab and then going back to the current tab, appears to grab the focus.  Otherwise, I can't think of any way of causing a focus without knowing that tabData because internally the QMainWindow keeps an associated list

info->item_list.at(i)

in which info is a structure holding the list and the info->tabBar.  I suppose that since main_window is inheriting QMainWindow we might be able to access some of the internal variables, but I'd rather than do that and if they are private then they are not accessible.

(file #44143)

Dan Sebald <sebald>
Fri 11 May 2018 06:20:45 PM UTC, comment #3: 

The problems I am still seeing are how to get the widget belonging to the clicked tab and related, how to get the tabbar, a widget belongs to. The only way I am currently aware of is using the tabData feature.

Torsten Lilge <ttl>
Group Member
Sun 06 May 2018 07:53:56 PM UTC, comment #2: 

I think there might be such a signal:

http://doc.qt.io/qt-5/qtabbar.html#signals

Probably tabBarClicked().  It might be difficult to get at in the QMainWindow environment or it could involve a dynamic connection as these tab groups appear.  For example, the following signal should be emitted when a widget is docked or moved elsewhere

http://doc.qt.io/qt-5/qdockwidget.html#dockLocationChanged

Then one could check the tab stack it belongs to and make sure that tab stack has tabBarClicked() connected to some new routine that will move the focus to the parent window.  Most likely disconnect-then-reconnect so that connections don't build up with each focus change.  Or something like that.  If a tab stack disappears, it's connections should automatically go away.

Low priority, as it isn't too difficult clicking inside the content of the QDockWidget.

Dan Sebald <sebald>
Sun 06 May 2018 07:36:59 PM UTC, comment #1: 

There is no official API for accessing the tab widget that is created by the main window when dock widget are tabified. Consequently, there is no obvious way for being notified when the tab is clicked. The focus is not changed by this click.

Torsten Lilge <ttl>
Group Member
Fri 04 May 2018 06:08:38 PM UTC, original submission:  

A very minor detail, but if there is a tab stack in the main GUI or in the variable editor mouse button press on the tab of the visible panel in the stack does not bring that item into focus.  Attached are a couple screen shots which show that nothing happens when I pressed the mouse button right where the mouse cursor is shown.  That is, I tried to activate the Command Window by clicking the visible tab...nothing happened; focus did not transfer to the Command Window.  Of course, had I moved the cursor up and clicked in the actual Command Window, then focus would change.  Note that if the item in the tab stack is not the visible one then clicking on that tab brings the item to the front of the stack (i.e., visible) and gives it focus.

I'm attaching a second screenshot that illustrates the same thing happens with the Variable Editor.

Either something related to main_window::focus_changed (QWidget *, QWidget *new_widget) has to be changed, but I doubt that can be done because that slot is connected directly to the qApp signal that indicates somewhere focus has changed.

Instead, it looks like something in the label_dock_widget, which is a base class of both octave_dock_widget and variable_dock_widget, has to be changed.  Either it could be something having to do with focus proxy, or perhaps one will have to write a short mouse-press event handler for the tab buttons and change focus even when the top stack tab is pressed.

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 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 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2018-05-13 ttl Priority5 - Normal 3 - Low
    2018-05-11 sebald Attached File- Added octave-gui_qtabbar_focus-djs2018may11.patch, #44143
    2018-05-11 ttl Severity3 - Normal 1 - Wish
    2018-05-04 sebald Attached File- Added gui_main_tab_not_activate_Screenshot_20180504_125238.png, #44093
        Attached File- Added variable_editor_tab_not_activate_Screenshot_20180504_125351.png, #44094

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code