Sigil-2.1.0 Released

[KevinH]

1. I can see focus changes quite well under MacOS. Perhaps that is a platform thing? I can investigate that.

2. The View menu is not built in ui files but instead built on the fly in code with for all dockwidgets. I am not sure how easy it would be to restructure that so that the shortcuts can be registered to shortcut manager as that menu is built first before the registration process. I will also investigate that.

3. I think you are asking about an Accelerator for the main Give Focus to Menu first menu?

[BeckyEbook]

Focus in Sigil on Windows is a truly mysterious case.

I too often Tab jump over various interface elements and also run into the problem of Code View accidentally capturing focus and I get something similar to the screenshot from one of the previous posts.
* Sometimes this happens when I hide the F&R window.
* Sometimes when I have the Automate icons on the toolbar turned off.
* Sometimes when I have more than one tab open in Code View
* (and certainly in other cases that I can't remember).

For easier checking where the focus is, I can suggest a one-line entry in the qt_styles.qss file:

:focus {border: 1px solid red;}

[KevinH]

Yes, Tab to shift focus does not always work especially if CodeView grabs focus. Shift tab should still work unless it is being interpreted as input under Windows too?

[BeckyEbook]

Shift-Tab has the same problem. When Code View takes focus it still inserts tabs into the code.

[KevinH]

Wow. Okay. Let me investigate if we can use a keypress event routine to preprocess Shift-Tab as a focus change before it goes to CodeView.

Update:

Same issue happens on macOS as well. I so rarely use all keyboard so I never noticed it.

I also tried your red border qss file and it works nicely for BookBrowser, TableOfContents, and Clips Windows. Thanks you! CodeView already changes the current line background when it has focus so that is clear as well. Unfortunately Preview does not display any red border when it has focus. But since that is the only one that doesn't change, I know when it has the focus.

So the PreviewWindow probably has no border around it to change color as it is a QtWebEngineView.

Again something to add to the list to be investigated.

[Astroman]

I hope it's ok that I ask this question here instead of starting a new thread:

This winter I've been preparing text and images for my first ebook. I've read the entire Sigil manual (twice) as well as various introductions to EPUBs. I already have some coding experience. Unfortunately, my progress with Sigil has been slow because I encountered a weird problem which I've never experiences before:

Undo is not working.

That is, if I make manual changes to the text or code, I can undo this as long as I don't press Save. Needless to say, saving is a must, and saving frequently is heavily encouraged also in the Sigil manual. After saving, all undo history is lost. Nothing happens when I press the undo button or use the shortcut.

I'm currently using an older Mac running the latest supported version of Sigil, i.e. 1.9.30. After more than two hours of searching the manual, the forum, and Google, I only found a single reference to this issue. In this thread from 2017, GrannyGrump writes:

"I guess because the "Undo" cache seems to empty each time you Save in Sigil, …"

Does the recent 2.1.0 update also behaves in this way?
If so, does that mean that Sigil does not support undo (in combination with save)?

[DiapDealer]

Originally Posted by Astroman

Does the recent 2.1.0 update also behaves in this way?
If so, does that mean that Sigil does not support undo (in combination with save)?

Yes. The latest Undo behaves the same way. Sigil's Undo is bit of a relic. It will only revert very minor, very recent, very small, and very unsaved changes.

You should look into Sigil's Checkpointing feature if you want to be able to revert large changes across saves. It allows you to compare (side-by-side) differences between various saved revisions of the same epub. Always create a checkpoint before making changes you may want to revert.

[BetterRed]

Originally Posted by KevinH

Yes, Tab to shift focus does not always work especially if CodeView grabs focus. Shift tab should still work unless it is being interpreted as input under Windows too?

Even if it did overcome this issue, Shift+Tab is an unacceptable work-around for anyone who habitually uses Tab to navigate WIMPy (another word we shouldn't use) interfaces. Keyboard centric users don't press Tab once, they press it repeatedly, Shift+Tab is used when they press Tab one too many times.

Originally Posted by BeckyEbook

Focus in Sigil on Windows is a truly mysterious case.

I too often Tab jump over various interface elements and also run into the problem of Code View accidentally capturing focus and I get something similar to the screenshot from one of the previous posts.
* Sometimes this happens when I hide the F&R window.
* Sometimes when I have the Automate icons on the toolbar turned off.
* Sometimes when I have more than one tab open in Code View
* (and certainly in other cases that I can't remember).

For easier checking where the focus is, I can suggest a one-line entry in the qt_styles.qss file:

:focus {border: 1px solid red;}

Thank you.

Can I put that qt.style.qss file somewhere - I don't want to build Sigil?

Will it highlight 'dormant' dockable panel tabs, such as the Table of Contents and Clips windows I dock with Book Browser and Preview.



I think they can get focus via a Tab?

Sigil is not only mysterious on Windows. My former housemate has a Mac, in 2017 she let me install Sigil on it. I found it had the same issues that we're discussing here as I had, and still have, under Windows.

---

For me, the main issue is that its possible to inadvertently Tab into the CodeView multi-line text-box, if that could be prevented it would be good.

Telling users that the background colour of the current line will change if you end up there… and it's something they need to watch out for… is not very helpful.

On Windows the background colour of the current line is the same irrespective of keyboard focus. When the CV textbox gets focus the only visual cue is that the text cursor will show. Aside: on Sigil (Qt I guess) doesn't honour the relevant Windows Text Cursor settings.
Is there some way I can get a Tab to be visible, e.g. as a → ?

Ideally, repeated Tabs would always wrap around the controls within the current window… like they do in the Spell Check window. The fact that the window is an embedded child like F&R, or a docked child like Book Browser should not change that basic behaviour.

FYI: the calibre ebook editor has EXACTLY the same problem!

However its good to see the defect has been acknowledged.

BR

[KevinH]

A tab is a valid input character for a QPlainText (CodeView) edit so entering a Tab by accident when trying to tab focus someplace else (there is no place else to go inside CodeView) can never be distinguished from a user intentionally entering the tab character (it is a valid character to enter even in xhtml).

That is not going to change.

[BetterRed]

Originally Posted by KevinH

A tab is a valid input character for a QPlainText (CodeView) edit so entering a Tab by accident when trying to tab focus someplace else (there is no place else to go inside CodeView) can never be distinguished from a user intentionally entering the tab character (it is a valid character to enter even in xhtml).

That is not going to change.

I have not suggested that should change, and I am not aware that anyone else has.

My position is that Tab should not move the focus between windows. A tab within F&R should stay in F&R (i.e. stay in its lane), it should not change focus to other windows… especially with no obvious visible indication of doing so.

If a user wants to give focus to CV, or any other window they should click in it, or make use of the new Give Focus to XXXX menu action/shortcut feature (why no buttons ?).

I'd be surprised if any Sigil user deliberately uses the Tab key to move between Sigil's windows. I also suspect its not a by-design feature, more likely it's an unfortunate by-product of poor design.

BR

[KevinH]

Under Qt a tab will move focus to all focus receivers inside a Widget to itself and to its children.

The QMainWindow we use has QDockWidget which are in fact its children (Preview, TableOfContents, ClipsWindow, BookBrowser, etc). So tabbing will not just stay inside a single QDockWidget as it is one of many children of the QMainWindow.

Using tab to move focus among fields in a modal QDialog makes sense. But trying it in Sigil's MainWindow will be hard given the number of children and the number of focus points. I will investigate if there is any way to disable that for a set of widgets and their children, why still allowing them to get and use focus.

[BeckyEbook]

Can I put that qt_styles.qss file somewhere - I don't want to build Sigil?

Just create/edit a qt_styles.qss file in the Sigil configuration folder (you can easily go there by clicking the "Open Preferences Location" button in the lower-left corner of the Preferences window).

[BetterRed]

Originally Posted by BeckyEbook

Just create/edit a qt_styles.qss file in the Sigil configuration folder (you can easily go there by clicking the "Open Preferences Location" button in the lower-left corner of the Preferences window).

Thanks - I thought that was all,

Very useful, confirms that tabbing between windows is broken, takes multiple Tab presses to get from one window to another, but which window one lands on is erratic.

Some times F&R→→→Book Browser→→→CVTabBar→→→F&R
Other times F&R→→→Book Browser→→→→→→ToCTab→→→CVTextBox . . . can't Tab out of CVTextBox (rightly so)
Another time F&R→→→Book Browser→→→→→→ClipsTab→→ . . . →→

BR

[theducks]

FWIW Many computer Keyboards still have Tab keys with 'Back Tab' icons on them.
The first ones I saw predated the PC by a lot (IBM 3270) and the last 'refurbished' Dell I bought came with a brand (cheap) one. I have been using Back Tab to navigate Menus since MSDOS days. Repurposing (by default) does not seem to be a good idea.

[KevinH]

No worries. If anything - disabling tab to move focus across QDockWidgets in a future version of Sigil would be something enabled by the user using an environment variable (once I figure out if and how to do it) so the default behaviour would not change.