Sigil-2.2.0 Released

[KevinH]

Originally Posted by mrprobert

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:

Okay, I finally have a test build but my changes do not change the the behaviour you described above.

Did Sigil ever work that way in the AddCover? Why would it default to having something already selected. It is the act of clicking that actually makes your choice apparent.

I am not 100% on this.

[KevinH]

And ditto for the MetaEditor? I will look into why focus is stolen when clicking on the remove button.

Update:

I tried Sigil-2.0.2, and Sigil-2.1.0 and in "AddCover" neither one highlights a pick when first opened. So there is no change from Sigil 2.2.0 or Sigil 2.2.1.

Did the same for the MetaData Editor and nothing was highlighted there either when first opened. So Sigil-2.0.2, and Sigil-2.1.0, work the same as Sigil 2.2.X in that regard.

As for the Remove button not letting focus go back to the MetaEditor Window, I have found and fixed that.

If you run into any others. Please let me know.

[mrprobert]

Originally Posted by KevinH

Okay, I finally have a test build but my changes do not change the the behaviour you described above.

Did Sigil ever work that way in the AddCover? Why would it default to having something already selected. It is the act of clicking that actually makes your choice apparent.

I am not 100% on this.

Kevin,

You are probably correct, this is nothing new. But, I would like to use the arrow keys to cycle through the list. Consider this:

1. Start Sigil and add in some images that are potential covers, say they are flower.jpg, marmot,jpg and zebra.jpg.

2. Open Add Cover. screenshot1 shows the picture at top of the list (flower) but no highlighting. I want flower as the cover, I know what a flower looks like, and so I click OK and all is well.

3. Well, I don't want flower so I will use down arrow to see the next image. screenshot2 shows nothing has changed except flower.jpg is highlighted on the list. But I don't want flower, why didn't the down arrow key advance the list the next image in the list?

4. I press down arrow again and the image now changes to the next item in the list: marmot. Again, no highlighting, but I know what a marmot looks like. I don't want that image either so again with down arrow. There is no effect and so the down arrow key is now useless: I can't cycle through the list with down arrow key nor the up arrow key.

Here's my opinion:

1. I want to be able to cycle through the list with the up/down arrow keys but I can't, I have to use multiple mouse clicks to cycle through the list.

2. There should always be highlighting that corresponds to the visible image. Highlighting is positive confirmation that the visible image and the filename are paired. If you know names and not pictures then using the mouse (or shortcut) is the only way to go.

[KevinH]

Technically, all QTreeViews (which is what AddCover uses), should automatically use keyboard arrow keys for navigation. Somehow the timing of loading the WebEngine to show the detailed image is messing it up. I will look why that is happening.

[KevinH]

@mrprobert,

Okay, It seems that when the QWebEngineView (the big image in the left side) finishes being updated it steals focus to itself and does not return it. This is a bug in Qt. I have had to extensively re-engineer the SelectFiles.h/cpp/ui files using my own focusWidget tracking and QTimers to prevent interrupting the previous load of the QWebEngineView with a new one.

All of this now seems to work. I can use Arrow keys to now happily walk down the list of cover images.

FWIW - Instead of using WebEngineView to show the detailed image of the cover you can instead use the splitter to hide the WebEngineView and use the + and - keys to set the size of inline thumbnail images to the immediate right of the file name.

Your change request is actually a "bug report" as far as I am concerned and its fix will appear in the next release of Sigil.


Thank you.

[KevinH]

Originally Posted by KevinH

Okay, since I hate uuid based ids, I have modified the standalone opf_id_updater to version 2 that tries much much harder to generate an id based on a filename even if a collision occurs by adding a 4 digit count field to the base id only when needed.

In case others are interested I have attached it.

It works in my tests but it really needs to be tested on an OPF that has lots more potential for collisions to validate the new routine.

See the attached. Testers and Feedback welcome.

Hi All,

For those interested, I found a few epub3s that use media overlays and this opf_id_updater v2 still does not properly update the refines used for media duration information in the opf:

Support for things like the following:

<meta property="media:duration" refines="#chapter_001_overlay">0:14:20.500</meta>

where the refines value (after removing the leading #) refers to the manifest id of an smil file are not properly updated.

So there will be a v3 version of opf_id_updater coming up probably this weekend with this deficiency fixed.

[KevinH]

For those interested.

I have now updated the opf_id_updater to v3. It now will look up meta property refines and update any that point into manifest ids which are common when media overlays are used (smil) files.

I included a new test case package.opf which is the opf from the official epub3 media-overlay example file Moby-Dick. I used it to convert the package.opf to npackage.opf

As far as I know, this v3 version should be the *final* version.

So barring unforeseen issues, I will either include this as a new Sigil plugin or possibly as a internal Sigil python3lib internal tool. I have not decided if this is needed/useful to a broad enough audience to include internally in Sigil for everyone.

To run the program after unzipping opf_id_updater_v3:
cd into that folder and run:

python3 ./fix_opf_ids.py ./package.opf > newpackage.opf

Then you can compare your newpackage.opf to the included npackage.opf.

Feedback and comments welcome.

Especially whether you think this tool would be useful to enough people to actually include inside Sigil under the Tools menu or if it would be better as a standalone Sigil plugin interested users can choose to download and install.

Hope this helps.

[nabsltd]

Originally Posted by KevinH

FWIW, using the file extension helps prevent name collisions but I really hate seeing the "." as part of an identifier. I think it would be better to split off the extension and then add it back to the end of the filename prepended with an underscore and not a period.

So Cover.jpg as an id would become Cover_jpg

Because spaces (and possibly other characters) in the filename are already converted to underscores, it's possible that unique filenames could—in theory—create non-unique IDs. Depending on what characters currently get replaced with underscores, you could get a collision. In particular, if you globally replace periods with underscores (and not just the extension separator), then a very common naming scheme will cause collisons:

A.Long.Filename.jpeg
A Long Filename.jpeg

So, other than being mindful of ID collision, I agree that converting the period would be a good idea.

[KevinH]

The only period being replaced is at the beginning of the file extension. Also each potential new id is always checked for uniqueness and made unique before it is used.

Note the filenames themselves do not have to be unique at all as long as their epub relative paths from root are different. So uniqueness does not rely on just the filename.

Do you have a test case opf that illustrates an issue? If so please post it for me to recreate the bug. Or is this only in the abstract case? If the latter, no worries.