Future Release To-Do Items

[BetterRed]

Originally Posted by KevinH

Well that was a dead end. Under macOS using setCursorWidth in CodeView had absolutely no impact on either the blinking insertion point or the cursor itself.

So it appears the blinking insertion point is not controllable at all under Qt6 using setCursorWidth no matter what the docs say.

Curious - did it 'work' in single line text boxes, e.g. F&R Find?

BR

[KevinH]

QLineEdit's like those used in Find and Replace do not have a setCursorWidth setting at all, so a QStyledProxy is needed to try something like that in things like that.

I did get setCursorWidth to work in a QPlainTextEdit (CodeView) finally. It is undocumented but it must be set every time a new QTextDocument is set. So I can get a double width insert point text cursor working in CodeView but no luck so far in QTreeViews, QComboBoxes, QLineEdits and other major widgets types.

I am still investigating.

[luka]

Hello, I noticed that Article 8 has optimized the renaming efficiency when there are many files, and the speed has been greatly improved. Will the efficiency of adding/deleting files in batches when there are many files be optimized in the future? Also, it takes a long time to set up the Cover page when the file volume is large. The problem.
Many thanks

[KevinH]

Originally Posted by luka

Hello, I noticed that Article 8 has optimized the renaming efficiency when there are many files, and the speed has been greatly improved. Will the efficiency of adding/deleting files in batches when there are many files be optimized in the future? Also, it takes a long time to set up the Cover page when the file volume is large. The problem.
Many thanks

Bulk delete has previously existed for use by Merge but now will be used in more cases.

There is no easy way to speed up the "Add Existing" of huge numbers (thousands) of files as that requires creating thousands of internal Sigil resource objects and loading their contents into QTextDocuments for speed of editing, then constantly editing and reediting the opf thousands of times to create the proper opf manifest, not to mention file copying and reading times.

You would be better off using a standalone tool or python script to create a rough opf from those thousands of files and using the FolderIn plugin to load it or even use a create a simple epub from those files and start from that.

Obviously using a fast ssd based drive and staying far away from slower network drives helps too.

Literally epubs with thousands of images or thousands of files is an extreme use case.

Exactly which types of epubs have file counts like that?

Even a stats/math textbook that could have thousands of equations as separate images (because it does not properly use mathml) still typically only has less than 100 chapter files of text.

[KevinH]

Okay, after some more experimenting, I now have a way to double the insertion point text cursor width from the default 1 pixel wide to 2 pixels wide which helps to make it easier to detect. This should work in all FindReplace and all QLineEdits too.

Remember the insertion point cursor has to fit between adjacent characters. So the wider it gets the worse it looks when fonts with kerning and tight letter spacing are employed. So going more than 2 pixels is not recommended.

It is reasonably painless and seems to work requiring only a few small changes in CodeViewEditor.cpp and main.cpp.

So I am thinking of creating a Sigil Main UI Preference Appearance to enable or disable it. Changing this setting would require a Sigil restart since it involves changing the main application style on the fly.

So something along the lines of:

    [] Make text cursor insertion point more visible

I would like to know if our users would find this useful or not before fighting with the Sigil Preferences again (or begging DiapDealer to do it!).

I have attached two screen shots. Since they are static, no blinking involved. But look at the end of the xhtml comment at the line in yellow to compare the text cursors before and after.

Note: these screencaps appear much larger on the screen when I open them here on Mobileread than the actual on my display so both appear reasonably easy to see but that is not quite how it seems to me. Not sure how to show the difference otherwise.

[DiapDealer]

I would like to know if our users would find this useful or not before fighting with the Sigil Preferences again (or begging DiapDealer to do it!).

Happy to contribute.

But I worry that vertical space on the Main UI tab of the Appearances Prefs might be getting tight for space. It would mostly affect laptop users with smaller screens, but still....

There's probably a couple of options to get around it. One would be to create a new Accessibility tab that I could put the new Show Widget Focus pref and this proposed larger insertion point cursor on. Another option would be to remove the Tweak Drag Distance preference. I consider it to be a veritable boat-anchor at this point anyway. I could drop it completely, or if someone can convince me it's being used (Qt5), I could replace it with an environment variable setting for the two people in the world who might find it useful.

[KevinH]

I like the idea of a new Accessibility tab. Maybe even move ui font sizing there, the icon sizing there, the red focus border, and the larger cursor setting. There might be others.

Just a thought to free up space from other already overcrowded preference tabs.

[retiredbiker]

Cursor insertion point more visible: I wold vote Yes (as would most of my age group, I'm sure.)

I did this in Writer quite a while ago, and it makes a huge difference, even when using big text on a huge screen. (The Writer solution is a gtk.css file trick, so it probably wouldn't wouldn't help in the Qt world, I got it from here: https://askubuntu.com/questions/1027...ter-appearance)

[BeckyEbook]

My two cents on the option "Highlight Widgets with Focus" (applies to Windows, possibly others).
The simple QSS for showing focus has a certain unpleasant side-effect, which applies primarily to the two widgets: QSpinBox and QComboBox.

Well, the focus overwrites the default 'Fusion' style and ruins the aesthetics of these controls.
The problem has been known for years, but I have not found a simple solution.

Link

I am not in favor of removing this new option if users find it useful, but it is worth adding a note in the documentation that the aesthetics of the UI will suffer with this option enabled. The Accessibility tab is also a good idea.

[KevinH]

The FindReplace arrow just shrunk a bit to allow the border. But the spinbox arrows change seems really bad.

I will check things on macOS to see what happens there.

[KevinH]

@BeckyEbook,

Couldn't we restrict that :focus qss to specific classes leaving out QComboBox and QSpinbox since one highlights the text before the up/down buttons, and the other has a blinking cursor or highlight when it has focus?

[KevinH]

The opposite problem exists in macOS, as the FindReplace pulldowns look horrible and the QSpinbox is just slightly smaller.

Interesting ...

[BeckyEbook]

Originally Posted by KevinH

@BeckyEbook,

Couldn't we restrict that :focus qss to specific classes leaving out QComboBox and QSpinbox since one highlights the text before the up/down buttons, and the other has a blinking cursor or highlight when it has focus?

In theory, yes, because you only need to catch the main widget names and apply the change only to them.
Highlighting focus only on the main windows (BookBrowser, CodeView, Validation Results, TOC, Clips, Preview) will only be a substitute.
However, I acknowledge that this is not trivial if indeed this option is to be useful for people with disabilities or those using Tab/Shift+Tab to navigate the Sigil interface.

I also come across an interesting issue in Windows, when I switch windows via the Tab key, the focus also switches to the toolbar, but only to one – Automation Lists.

[KevinH]

There are ways to use a paintEvent for each Widget to draw the focus box instead of a stylesheet. All the QDockWidgets already override the paint event now. Perhaps handling it that way might work better.

I will play around a bit just to see.

[KevinH]

We can supposedly set TabOrder on each Widget to limit where Tab goes according to the docs.

I will try playing around with that.