Future Release To-Do Items

[DiapDealer]

I can't see anything obvious that would break it, but I'm unable to compile in some debug output where I am to test things out.

I didn't change any ifdefs in my patch because they were a bit twisty. I DID comment a few things out that would leave the ifdefs sections empty of any code, but I added an empty ; that I was under the impression would work similar to "pass" in Python.

[KevinH]

It must be something else that is causing the issue. I went through the ifdef spaghetti in main.cpp and added #endif comments to help pair them with their ifdef starts and they all matched as far as I could tell.

Evey pushed that to master in case it might help track things down.

Very Strange!

[DiapDealer]

I think I got it working. But Code View and and Preview are not highlighting for me. I think that's normal for the original qt_styles.qss technique though, right? You had to add some code to get Code View and Preview working didn't you? Or are they supposed to work using the original qt_styles.qss technique now, too?

I just had to flat-out remove the ifdefs pertaining to Windows Darkmode to get stuff working. Apparently no amount of placeholder shenanigans was going to work.

There's no reason we can't indent those ifdefs to make things easier to match up is there?

[KevinH]

Indents should work but some old compilers wanted the # as the first char of the line but that was a long time ago.

Yes, the :focus qss qt_styles won't work on Preview and CodeView. Both use additional code that checks the focus highlight setting to enable the focus highlight to work on them.

[DiapDealer]

Originally Posted by KevinH

Yes, the :focus qss qt_styles won't work on Preview and CodeView. Both use additional code that checks the focus highlight setting to enable the focus highlight to work on them.

Ok. That makes me feel better. So we don't have to choose between using the Qt6.5+ dark theme on Windows and user-defined qss style customization. That would have been a deal-breaker. Thanks.

[KevinH]

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)

[KevinH]

Update: It seems that you actually can use tab to shift focus on buttons inside a QDockWidget by using setTabOrder.

The issue is that if the QDockWidget has a QtWebEngine as part of the setTabOrder (like our Preview does) the tab order is broken by the QtWebEngine as it literally creates its own render widget as its focus proxy widget (a QQuickWidget) on fly and it can recreate it as needed to handle rendering.

This changes the focus chain on the fly breaking any previously setTabOrder.

So getting the Preview's own toolbar buttons to handle tab shifting focus would be a real bear probably either requiring moving it to the top of the QDockWidget and/or making sure all buttons are created first before the QtWebEngineWidget.

Not something for a minor point update release anyway.

Wow this tab shift to move focus is not easy to change or control because of lots of special cases and corner cases. Especially involving QtWebEngine.

[DiapDealer]

Originally Posted by KevinH

I agree if we just want to move the Tweak Drag Distance to an environment variable, that will free up space for the Double Cursor Width setting with no extra changes.

So just be clear: this eliminates the need for new Accessibility tab , or no?

Originally Posted by KevinH

@DiapDealer, if you agree, and get a free moment would you move the tweak drag distance to an environment variable and add the double width cursor (and SettingsStore stuff)?

Will do.

[KevinH]

Yes, I am not planning to add any more preferences, so your idea of moving the drag distance to an environment var makes good sense, while freeing up space for the double width text cursor prefs.

[DiapDealer]

Thanks. I'm on it.

[BetterRed]

Originally Posted by KevinH

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

. . .

Should I assume nothing sensible can be done about tabbing between 'widgets' without significant effort?

Circling back to my the original issue - visibility of which child window has focus. If the coloured border solution can't be readily applied to the Codeview and Preview windows, how about changing the colour of the dockable child title bar.

On Windows, if a dockable child is undocked, then its title bar will have the "Accent" colour when it has focus - i.e the border is redundant. So, why not do the same when its docked. When Codeview has focus the tag on the current tab-panel item could use the same colour. viz:



Maybe the F&R non-dockable child window could be given a title bar too, then its 'X' could be put where it belongs, at the far right - rather than the loony left :-)

Curious - why isn't the F&R child window dockable?

BR

[KevinH]

Just posted a fix to master for some of the stranger tab to shift focus issues:

- made it less likely CodeView will get hit by a tab to shift focus sequence

- removed the automate, case, and headings toolbar tools from the tab to shift focus path
to match all the other toolbars

- completely reworked Preview to add its tool buttons to the tab focus chain since there were no menus to launch any of them

- modified the FindReplace tabstop sequence to better follow the visual/logical path through FindReplace (ie now top to bottom)

I have not tried stopping a tab from moving to the QDockWidgets and I am not sure it is worth the effort to try to change (and that would require a new preference setting).
We can leave it as something for the future.

[KevinH]

Yes, tabbing between dockwidgets will continue until some future release.

The focus highlight border can now be applied to both CodeView and Preview and it works.

Redrawing title bars requires overloading the paintEvent in each widget and replacing it with our own. No need now that the border works.

Find and Replace is not a QDockwidget. It is a child window of our MainWindow that is shown and hidden. Its position is locked and it can not be undocked. That means it has no titlebar. As for where the X close is. It is manually added and has been in the same place forever, and is not moving given the 10 years of muscle memory I have built up. You'll have to just live with it.

It was designed as part of the main window (just like TabManager and CodeView) so that it can be integrated visually and codewise with them. Again, a decision we will not be revisiting as it makes good sense.

Originally Posted by BetterRed

Should I assume nothing sensible can be done about tabbing between 'widgets' without significant effort?

Circling back to my the original issue - visibility of which child window has focus. If the coloured border solution can't be readily applied to the Codeview and Preview windows, how about changing the colour of the dockable child title bar.

On Windows, if a dockable child is undocked, then its title bar will have the "Accent" colour when it has focus - i.e the border is redundant. So, why not do the same when its docked. When Codeview has focus the tag on the current tab-panel item could use the same colour. viz:

Attachment 207657

Maybe the F&R non-dockable child window could be given a title bar too, then its 'X' could be put where it belongs, at the far right - rather than the loony left :-)

Curious - why isn't the F&R child window dockable?

BR

[BetterRed]

Originally Posted by KevinH

Just posted a fix to master for some of the stranger tab to shift focus issues:

. . .

- thanks

BR

[BetterRed]

@BekkyEbook

You posted the following screen shot here



I'm puzzled as to how you docked the Validation and ToC windows where you did - above Codeview and alongside Preview. I've attached some screen shots of my failed attempts.

BR