How to enable spellchecker?

[BetterRed]

Originally Posted by KevinH

You have to have an established shortcut highlighted for the remove button to be enabled and to get Tab Focus, and the shortcut field must have a shortcut ready to assign for the Assign button to be enabled and get tab focus.

Press Tab



BR

[BetterRed]

Originally Posted by KevinH

And for the Reports Widgets, what exactly are you finding and in which specific report?

The Characters report… I use it to check for potentially spurious characters. Example: if I saw a Greek letter in an English poetry collection I'd wonder why. For me tapping Enter to see each occurrence is much easier than using a mouse or similar.

BR

[BetterRed]

Whoa - just noticed there are Shortcuts in Preferences for handling misspellings - why can't they be used in the Spellcheck dialogue.



And why can't the context menu in the Spellchecker be the same as the one in Codeview with the inappropriate entries greyed-out.



I notice the user assigned shortcuts are not displayed in that menu, whereas the industry standard shortcuts (Ctrl+X,C,V and A) are displayed. Displaying shortcuts in menu's is how I get to remember them.

BR

[KevinH]

It can not be "enter" that is the default "ok" button trigger on some platforms.

I think I will just make the spellcheck dialog modal and keep the hard coded shortcuts. Dialogs can have their own dedicated shortcuts. And changing them after so long is just going to make people unhappy, for not much gain.

Thanks

[KevinH]

Originally Posted by BetterRed

The Characters report… I use it to check for potentially spurious characters. Example: if I saw a Greek letter in an English poetry collection I'd wonder why. For me tapping Enter to see each occurrence is much easier than using a mouse or similar.

BR

Huh? That report is meant for users who want to embed fonts but limit them to the characters actually found in the text of the ebook. All of the chars are typically reported on a single line.

[Turtle91]

Modal?!?!?

Ummmm..... Granted, I don't use spellcheck all that much...I'm perfekt at speling...but when I do, I very often use the double click and then make multiple changes in the CV window. Having to re-run the spell check every time with its inherent re-organizing of the word list would make the process much more painful. Can we please brainstorm this a little more before making life-altering decisions??

[KevinH]

They represent two different spellcheck tools.

The red squiggle underline approach unions the Primary and Secondary dictionaries but does not track lang attributes as it is designed to be used while actively entering or editing text. This is done for speed and because when text is being edited, the tags may still be incomplete so no real lang attributes tracking can be used. This is part of CV and not a separate dialog so it must share the keyboard shortcuts set in Preferences.

The Spellcheck dialog is designed for use when primary editing/entry of text is done and tags are well formed. It fully tracks lang attributes. And can spellcheck in multiple languages (as many as used) simultaneously. It can update and fix misspelled words in multiple places simultaneously. Again this is a separate dialog that uses its own different dedicated shortcuts.

Originally Posted by BetterRed

Whoa - just noticed there are Shortcuts in Preferences for handling misspellings - why can't they be used in the Spellcheck dialogue.

Attachment 210720

And why can't the context menu in the Spellchecker be the same as the one in Codeview with the inappropriate entries greyed-out.

Attachment 210721

I notice the user assigned shortcuts are not displayed in that menu, whereas the industry standard shortcuts (Ctrl+X,C,V and A) are displayed. Displaying shortcuts in menu's is how I get to remember them.

BR

[BetterRed]

Originally Posted by Turtle91

Modal?!?!?

Ummmm..... Granted, I don't use spellcheck all that much...I'm perfekt at speling...but when I do, I very often use the double click and then make multiple changes in the CV window. Having to re-run the spell check every time with its inherent re-organizing of the word list would make the process much more painful. Can we please brainstorm this a little more before making life-altering decisions??

↑ ↑ ↑ ✔ ↑ ↑ ↑ ✔ ↑ ↑ ↑ ✔ ↑ ↑ ↑ ✔ ↑ ↑ ↑ ✔

There's thread somewhere where Tex2002ans, me and others waxed lyrical on the advantage of a non-modal list based spell checkers.

BTW he's not logged on since January, anything known?

BR

[KevinH]

Originally Posted by Turtle91

Modal?!?!?

Ummmm..... Granted, I don't use spellcheck all that much...I'm perfekt at speling...but when I do, I very often use the double click and then make multiple changes in the CV window. Having to re-run the spell check every time with its inherent re-organizing of the word list would make the process much more painful. Can we please brainstorm this a little more before making life-altering decisions??

No worries. This is still just brainstorming. Before anything is changed in code, everyone can have a say and I will not be breaking current work patterns or existing shortcuts. Just adding to them if needed.

So what typical CV changes are you making after double-clicking on a word in the Spellcheck Dialog? Do you manually refresh the spellcheck wordlist?

[Turtle91]

Originally Posted by KevinH

So what typical CV changes are you making after double-clicking on a word in the Spellcheck Dialog? Do you manually refresh the spellcheck wordlist?

I usually scan down the wordlist to find world-unique or inconsistent words (eg proper names). World-unique words get added to their own dictionary. British/Australian ‘mis-spells’ are ignored. Inconsistent words I check the count to see if it’s obvious which one is correct, double-click the word and make sure the context doesn’t support a mis-spell (dialect/accent). I tend not to use correct all if the count is low because of the context check, I just fix it in the CV.

Usually, when I am in the CV fixing that word I find other things to fix right around that word - so I do.

The problem with a modal dialog, or refreshing, is that it reorders the word list and I lose my place making me start at the top again. I suppose there is also the time lost to rebuild the list on slower machines as well.

[KevinH]

@BetterRed

Regarding the bug in Preferences KeyShortcuts that Tab focus will not properly move to the Assign button or the Remove Button ...

I have looked more closely at this and it appears to be a bug in Qt's previousInFocusChain and nextInFocusChain not including buttons that are independently enabled and disabled as this chain appears to be built once and static at the QWidgets creation (which makes no sense to me).

As it stands now, using Qt::KeyBackspace when in the shortcut field (ie. the delete key on my Mac) will properly invoke the Remove button if enabled.
The same things should work on Windows.

For the Assign button, there is no possible single key to launch it given you are in the shortcut creation field that would not be a valid possible field value.

Tab should handle this case but it does not (the nextInFocusChain Qt bug).

So unless we can figure out a single key that could be used to launch Assign (to work around this) that is not useable in assigning a shortcut we are pretty much out of luck working around this bug and will have to wait for a fix from Qt.

Sorry.

Update
--------
To workaround this Qt bug - I tried using setTabOrder but that was ignored.

Finally, I did find a way to force inject the Assign and Remove buttons into the focus chain after the Shortcut field (given they are properly enabled) with this bug workaround:

diff --git a/src/Dialogs/PreferenceWidgets/KeyboardShortcutsWidget.cpp b/src/Dialogs/PreferenceWidgets/KeyboardShortcutsWidget.cpp
index 8455ada0f..b8ec36566 100644
--- a/src/Dialogs/PreferenceWidgets/KeyboardShortcutsWidget.cpp
+++ b/src/Dialogs/PreferenceWidgets/KeyboardShortcutsWidget.cpp
@@ -293,7 +293,13 @@ void KeyboardShortcutsWidget::handleKeyEvent(QKeyEvent *event)
         if (nextKey == Qt::Key_Tab || nextKey == Qt::Key_Backtab) {
             QWidget * upnext = nullptr;
             if (nextKey == Qt::Key_Tab) {
-                upnext = nextInFocusChain();
+                if (ui.assignButton->isEnabled()) {
+                    upnext = ui.assignButton;
+                } else if (ui.removeButton->isEnabled()) {
+                    upnext = ui.removeButton;
+                } else {
+                    upnext = nextInFocusChain();
+                }
             } else {
                 upnext = previousInFocusChain();
             }

This "workaround" has been committed to master and will be available in the next release (which may be quite some time from now).

[BetterRed]

Originally Posted by KevinH

. . .

Regarding the bug in Preferences KeyShortcuts that Tab focus will not properly move to the Assign button or the Remove Button ...

This "workaround" has been committed to master and will be available in the next release (which may be quite some time from now).

In Windows I discovered can backtab to the Assign or Remove buttons (they are never both active); not directly, via a few other widgets.

BR

[KevinH]

Interesting. According to the Qt ui spec, the default tab order is the order these widgets are defined in the ui file. In our ui file the shortcut field comes immediately before the assign button which is followed by the remove button.

So I really have no idea how backtabs end up reaching them from other widgets.get there when forward tabs ignore them (even when enabled).

Glad you have a workaround for current Sigil you can use until the next release comes out.