MobileRead Forums - View Single Post - Future Release To-Do Items

KevinH · 04-16-2024, 10:37 AM

I have now spent two days playing around with Tab to change focus using setTabOrder and found out a few things:

1. Anything in a QToolBar that does not have a menu pulldown will not get tab focus.

2. Any QToolButtons in a QDockWidget will not get focus via a tab either.
Note: FindReplace is a build in child widget of QMainWindow not a QDockWidget

None of this is documented anyplace I could find anyplace online. Just a bunch of unanswered queries about how to to use Tab focus in a QToolBar and inside a QDockWidget.

3. It would NOT be easy to prevent tab shift focus to QDockWidgets by setting use setFocusPolicy(Qt::ClickFocus). I even tried setFocusPolicy(Qt::NoFocus). They stay a part of the tab focus chain no matter what I do. I would have to overload and reimplement focusNextPreviousChild(bool next) in MainWindow and return false anytime a next in the focus chain is a QDockWidget and make double sure they appear at the end of setTabOrder. Not sure this is worth the work.

4. But I can use that approach to prevent the QToolBar QToolButtons that have pull down menus (Headings, Automate1, Automate2, Automate3, etc) from being part of the tab focus chain.

(ASIDE, RANT)
And today I learned that Qt dev guys really do not give a rat's ass about the quality of their product. They only fix the issue with the test case itself but not the underlying issue. And they refuse to look at even related sub-issues without a separate bug report and separate test case, even when a one line change in the current provided test case would show the problem!

In other words, some manager idiot decided that the number of bug issues closed (not necessarily fixed in any way) is the performance metric instead of the quality of the underlying product. That means if a Qt dev can close an issue for any reason (valid or invalid) they will do so. So sad. In the early 1980's bug reports from user's (along with sample code) were treated like gold. Not so today.

It also illustrates the problem with using easily measurable but incomplete performance metrics like number of issues closed. It is a strong incentive but in truth it is not always aligned with quality.
(/ASIDE, RANT)

04-16-2024, 10:37 AM	#81
KevinH Sigil Developer Posts: 8,915 Karma: 6120478 Join Date: Nov 2009 Device: many	I have now spent two days playing around with Tab to change focus using setTabOrder and found out a few things: 1. Anything in a QToolBar that does not have a menu pulldown will not get tab focus. 2. Any QToolButtons in a QDockWidget will not get focus via a tab either. Note: FindReplace is a build in child widget of QMainWindow not a QDockWidget None of this is documented anyplace I could find anyplace online. Just a bunch of unanswered queries about how to to use Tab focus in a QToolBar and inside a QDockWidget. 3. It would NOT be easy to prevent tab shift focus to QDockWidgets by setting use setFocusPolicy(Qt::ClickFocus). I even tried setFocusPolicy(Qt::NoFocus). They stay a part of the tab focus chain no matter what I do. I would have to overload and reimplement focusNextPreviousChild(bool next) in MainWindow and return false anytime a next in the focus chain is a QDockWidget and make double sure they appear at the end of setTabOrder. Not sure this is worth the work. 4. But I can use that approach to prevent the QToolBar QToolButtons that have pull down menus (Headings, Automate1, Automate2, Automate3, etc) from being part of the tab focus chain. (ASIDE, RANT) And today I learned that Qt dev guys really do not give a rat's ass about the quality of their product. They only fix the issue with the test case itself but not the underlying issue. And they refuse to look at even related sub-issues without a separate bug report and separate test case, even when a one line change in the current provided test case would show the problem! In other words, some manager idiot decided that the number of bug issues closed (not necessarily fixed in any way) is the performance metric instead of the quality of the underlying product. That means if a Qt dev can close an issue for any reason (valid or invalid) they will do so. So sad. In the early 1980's bug reports from user's (along with sample code) were treated like gold. Not so today. It also illustrates the problem with using easily measurable but incomplete performance metrics like number of issues closed. It is a strong incentive but in truth it is not always aligned with quality. (/ASIDE, RANT) Last edited by KevinH; 04-16-2024 at 11:37 AM.