Found two bugs -- Related?

[eggheadbooks1]

I just discovered two possibly related bugs in the latest release:

1) When splitting the file, the first new file created, Section001.xhtml, appears correctly in the Book Browser and Content.opf. But as soon as you split this to create Section002, Section001 gets renamed, in my case to "xf64414a3-45dd-46a8-a724-dd073bbdbde8" in the Content.opf. See SigilBug1.jpeg.

2) If one changes the order of the HTML files in the Text folder, the document icon disappears from that file's line in the list.

I created a blank file, Section007, and dragged it to the top. The file remains, appears uncorrupted, and appears in the correct spot in the Spine in the Content.opf, just the doc icon has disappeared. See SigilBug2.jpeg.

If one then tries to merge any of the split files back, you get a Python error (SS3). You hit Close and get another error (SS4). Then you hit close again and the file merges.

[DiapDealer]

1) Not a bug. That's by design. The file isn't getting "renamed," that's the file's id property in the manifest (and the idref property in the opf spine) that's being generated for the newly-created file from the split. It's a perfectly valid id. In fact, the "x" was prepended to the uuid generated starting with this latest version (0.9.7) so that it would always be valid. The uuid id is also only generated under very specific conditions (and only when using the "Split at Cursor" feature). It happens when the preferred id Sigil wants to use for the split file is already in use.

2) I've seen that on Windows. I don't see it on Linux. But I've never seen any functionality problems because of it. I assume it's a new cosmetic-only Qt quirk.

I'm not able to recreate the Python error when merging files, but I'll keep trying.

[eggheadbooks1]

Originally Posted by DiapDealer

1) Not a bug... The uuid id is also only generated under very specific conditions (and only when using the "Split at Cursor" feature). It happens when the preferred id Sigil wants to use for the split file is already in use.

But the id is not already in use.

I re-merged everything and then I double-checked through the whole file. No Section id's anywhere.

First attached screenshot shows the file before splitting (SigilBug5.jpg).
Second SS shows the file after the first chapter split (SigilBug6.jpg). The file is appropriately named Section001.xhtml in both the Book Browser and the Content.opf.
Third SS shows the file after the second chapter split (SigilBug7.jpg). Section002 is there as expected but Section001 has been inexplicably renamed.

This cannot be right. I've never seen this happen in previous versions of Sigil.

If you then merge the files back up, you get the Python error. Which I have also never seen before when merging. As I said in my OP, the merging still works but the error is unsettling.

2) I've seen that on Windows. I don't see it on Linux. But I've never seen any functionality problems because of it. I assume it's a new cosmetic-only Qt quirk.

I'm not able to recreate the Python error when merging files, but I'll keep trying.

The missing icon doesn't appear to reduce any functionality, but it's a quirk I haven't seen before and my albeit-limited experience of "quirks" is that they're often a function of something else more sinister. That's why I'm wondering if the two seemingly separate bugs are related.

In case I'm just missing something, I've attached the ePub after re-merging and then splitting the initial file so you can see what's in it.

[DiapDealer]

1) The generated uuid id has been in Sigil all along. The only thing new is the 'x' being prepended to it. It's not new, it's not a bug, and as I said, it only happens under very specific conditions. It can be "right," and it is

I still don't get any python errors when remerging. Whatever it is, it's not related to the uuid. As I said, the uuid generation has been there all along. I'll keep looking.

2) Yes, the quirk is new. No it's not sinister. Not in my testing, anyway. Qt is full of quirks. They change from version to version.

[Toxaris]

Originally Posted by eggheadbooks1

But the id is not already in use.

I re-merged everything and then I double-checked through the whole file. No Section id's anywhere.

First attached screenshot shows the file before splitting (SigilBug5.jpg).
Second SS shows the file after the first chapter split (SigilBug6.jpg). The file is appropriately named Section001.xhtml in both the Book Browser and the Content.opf.
Third SS shows the file after the second chapter split (SigilBug7.jpg). Section002 is there as expected but Section001 has been inexplicably renamed.

The file is not renamed at all. Just the id has been changed. It has no impact on functionality at all, as long as all the references are correct (and they are).

[KevinH]

A manifest id is any properly unique string and is not a way to name files. The file name is specified in the href. One way to create a unique id string is to use a file name if that file name is unique and if it does not violate the rules for creating ids. Another way is to use a known unique id string such as those generated by uuid's and making sure they do not begin with a numeric digit.

All of that said, I hate using filenames for id's as it causes confusion (as seen above), they are generally longer than what is needed, and so are uuids based ids as well. I typically use short small unique strings such as "ch1", "ch2", "apdxA" and the like so that they are mnemonic like file names and are easy to remember and short.

Hope this helps,

KevinH

[DiapDealer]

Hey Kevin, I'm curious if you're seeing the disappearing icon when reordering files in the Book Browser on a Mac (not that I think there's much we can do about it--but I could be wrong)?

Also curious if any others can report Python errors on file merges.

[JustinThought]

Originally Posted by eggheadbooks1

I just discovered two possibly related bugs in the latest release:

2) If one changes the order of the HTML files in the Text folder, the document icon disappears from that file's line in the list.

I created a blank file, Section007, and dragged it to the top. The file remains, appears uncorrupted, and appears in the correct spot in the Spine in the Content.opf, just the doc icon has disappeared. See SigilBug2.jpeg.

Originally Posted by DiapDealer

2) I've seen that on Windows. I don't see it on Linux. But I've never seen any functionality problems because of it. I assume it's a new cosmetic-only Qt quirk.

I work exclusively on Windows, and I had seen that as well. I found that just by re-opening the e-book, the symbol comes back. So I assume it's a display problem only.

[DiapDealer]

Also keep in mind that the uuid id only gets generated when splitting files that use the stock SectionXXXX.xhtml naming pattern (with the Split at Cursor feature). And even though it's a perfectly valid id being generated, it can be avoided if you want by renaming the file to something else before splitting, and/or using the Split at Markers feature instead of Split at Cursor.

The uuid is just a necessary evil to programmatically ensure uniqueness in that very, very particular situation.

[KevinH]

Hi DiapDealer,

Yes, if I drag and drop to change the order, I lose the icon on the latest Mac OS X as well. Perhaps this is a bug in our code but to tell you the truth, I never noticed it before so it could be a Qt specific bug.

I will try to track down where in the BookBrowser this code is and see if it is something we can fix.

Take care,

KevinH

Originally Posted by DiapDealer

Hey Kevin, I'm curious if you're seeing the disappearing icon when reordering files in the Book Browser on a Mac (not that I think there's much we can do about it--but I could be wrong)?

Also curious if any others can report Python errors on file merges.

[DiapDealer]

Thanks, Kevin.

I can verify that it doesn't happen with the Windows version of v0.9.6. In light of that, I'd be inclined to say that it's a quirk in Qt5.6.1-1. My Linux version of Sigil is built with Qt 5.7.0, so that would further suggest it's related to the Qt version that's distributed with the Windows/Mac builds (5.6.1-1).

Perhaps I'll look into Qt5.6.2. It was released some time after Sigil 0.9.6 and before I could get it ready for inclusion in Sigil 0.9.7. Perhaps it will remedy the issue.

Originally Posted by KevinH

Hi DiapDealer,

Yes, if I drag and drop to change the order, I lose the icon on the latest Mac OS X as well. Perhaps this is a bug in our code but to tell you the truth, I never noticed it before so it could be a Qt specific bug.

I will try to track down where in the BookBrowser this code is and see if it is something we can fix.

Take care,

KevinH

[eggheadbooks1]

Originally Posted by DiapDealer

Also keep in mind that the uuid id only gets generated when splitting files that use the stock SectionXXXX.xhtml naming pattern (with the Split at Cursor feature). And even though it's a perfectly valid id being generated, it can be avoided if you want by renaming the file to something else before splitting, and/or using the Split at Markers feature instead of Split at Cursor.

The uuid is just a necessary evil to programmatically ensure uniqueness in that very, very particular situation.

I've always used the Split at Cursor method and this has never happened. I've used both the generic SectionXXXX.xhtml method and I've also renamed files.

You keep saying that Sigil will do this only in a very particular situation, but that situation does not appear to be present. In which case, why is Sigil doing this to my file?

I'll try uninstalling and reinstalling and see if that fixes the issue.

[KevinH]

To repeat - using the uuid to create a manifest id is not a bug or a change. This code has always existed in Sigil. The only difference is that the uuid has been modified to always start with a letter not a number.

Perhaps you are confusing Split at Marker vs Split at cursor or used to simply used to insert Split marker?

If you want to check that yourself simply install an older version of Sigil and repeat your actions exactly.

[DiapDealer]

Originally Posted by eggheadbooks1

You keep saying that Sigil will do this only in a very particular situation, but that situation does not appear to be present. In which case, why is Sigil doing this to my file?

You're not listening. You splitting a file named Section000x.html with the Split at Cursor feature IS the situation. It IS present.

Originally Posted by eggheadbooks1

I'll try uninstalling and reinstalling and see if that fixes the issue.

Won't do any good. Neither will rolling back to v0.9.6, or any other earlier version (except that versions earlier than 0.9.7 can result in ids being generated that violate spec). It's working the way it's designed to work. Don't know what else to tell you.

[BetterRed]

Maybe it would be less confusing if the manifest id was always an 'x' preceded uuid when a split at cursor was used.

BR