Sigil-2.2.0 Released

[icallaci]

Originally Posted by mrprobert

Kevin,

Thank you. I can't reproduce the exact scenario of another instance, but it involved doing search and replace and losing the highlighting in the code window. My intuition says that it is the same bug.

Much appreciation for your time and effort maintaining and improving Sigil.

I've also noticed a loss of focus in the code window when doing search and replace, but I can't find a reliable way to duplicate it. It's usually something like searching for <i></i> and pressing the backspace key to delete it (instead of clicking the "replace" button). It works the first time, but then the window loses focus and I can't use the backspace key. I am retraining myself to use the "replace" button.

[BetterRed]

Originally Posted by icallaci

I've also noticed a loss of focus in the code window when doing search and replace, but I can't find a reliable way to duplicate it. It's usually something like searching for <i></i> and pressing the backspace key to delete it (instead of clicking the "replace" button). It works the first time, but then the window loses focus and I can't use the backspace key. I am retraining myself to use the "replace" button.

The View menu has Focus on xxxxxxx actions, which can have kb shortcuts, viz:



BR

[icallaci]

Originally Posted by BetterRed

The View menu has Focus on xxxxxxx actions, which can have kb shortcuts, viz:

Attachment 209317

BR

I had no idea that was available. Thanks!

[mrprobert]

Kevin,

Ok, what I noticed is a change of behavior in doing a repetitive search and replace on a NAV file (sometimes it's faster for me than using the TOC editor.)

Here's my process:

1. Open the NAV in CodeView.
2. Replace all instances of .xhtml with .xhtml#chapterNNN
3. Search for NNN
4. Change the instances of NNN by searching for NNN, typing a number, click find next, and roll through the file: type click type click ...

Works great for me in v2.1.0 but in v2.2.1 it seems that focus on CodeView is lost with every click of the mouse and so this scheme won't work any more.

[DNSB]

Out of curiosity, unless you are planning on having more than the one header at the start of the xhtml file, why would you want to insert an ID?

[mrprobert]

I wouldn't, this is just a simplified demonstration of the problem.

-- Mark

[mrprobert]

A better example might be:

1. Batch rename regex of files to standard form: Chapter01.xhtml and so forth.
2. Edit the NAV to standardize filenames to chapterNNN.xhtml
3. Apply my scheme.

[DNSB]

Originally Posted by mrprobert

A better example might be:

1. Batch rename regex of files to standard form: Chapter01.xhtml and so forth.
2. Edit the NAV to standardize filenames to chapterNNN.xhtml
3. Apply my scheme.

Would renaming the text files not automagically change the filenames in the nav document? Select the files you want to give the Chapter001+ name to, set the rename files starting at field to Chapter001 and apply. Take a look at nav.xhml (ePub3) or toc.ncx (ePub2) and the filenames will reflect the rename.

And please note that your renaming will leave a mass of IDs in the .opf document untouched since ePub3 has added multiple locations where those can be used.

Again, though my preference to only use IDs where they are needed. I.e. where I use more than one header in a chapter file, perhaps for subchapters.

[mrprobert]

I'm not sure what you are getting at. If the Nav entries and filenames don't match already then renaming the files won't track inside the NAV anyway. As I said before, I wouldn't use IDs in the manner as shown in my test epub.

I am simply asking what changed between v2.1.0 and v2.2.1 that affects outcome, it's not about form, content or style.

[BeckyEbook]

Two cents: I understand the problem, but I just didn't notice it, because if I use the keyboard shortcut for the "Find Next" command - the problem does not occur.

I built a new version of Sigil with the latest changes and everything is fine now. I'm sure it will be OK in the next release.

[KevinH]

I thought that maybe no button should ever get click focus (Tab only not Strong (includes Click)) so tried reverting all of those last night. I am so glad to hear that helped and did not interfere with using the keyboard to change focus.

Thanks for testing that.

[mrprobert]

Kevin and BeckyEbook,

Thank you very much for finding a fix.

-- Mark

[mrprobert]

Originally Posted by KevinH

Yes, that is a bug. Those buttons should only ever have TabFocus so that the tab key to manually move focus can tab to them for Accessibility. Mouse clicks should activate them but not give them focus.

. . .

If you can point me to any other similar instances, I will fix them.

Hi Kevin,

When I do Add Cover with v2.2.1, the file selection is not highlighted with a contrasting color (at first). Here's a screen shot:

[mrprobert]

Kevin,

I think there is a similar issue with the Metadata Editor. When I open the editor, I don't see highlighting of the current field with a contrasting color. Clicking on one of the fields shows highlighting but it disappears after clicking on the remove button.

Thank you for looking into this.

-- Mark

[KevinH]

These are all Buttons taking focus for themselves. They should all be fixed now but I will test a build from master to verify that just in case.

Thanks