Issue with Multiple File Reference Errors in Spine

[byword]

I verified that the Spine error occurs after building version 2.8.1 with the latest code pulled from Git. This error is consistently reproducible.

Sigil Version: 2.8.1 (built directly from git source)

Sample error code

<spine toc="ncx">
<itemref idref="Section0001.xhtml"/>
<itemref idref="Section0003.xhtml"/>
<itemref idref="Section0004.xhtml"/>
<itemref idref="Section0005.xhtml"/>
<itemref idref="Section0002.xhtml"/>
<itemref idref="Section0004.xhtml"/>
</spine>

Steps to Reproduce:

1. Create a new ePub file.
2. Add multiple XHTML files.
(e.g., In the Section0001.xhtml file, press Ctrl+Enter multiple times to split it into Section0002 through Section0007)
3. In the Book Browser, select non-adjacent files
(e.g., select Section0002, Section0004, and Section0006 with non-contiguous selection).
4. Drag and move the selected files below Section0007.


After performing these steps, Section0004 and Section0006 appear duplicated in the Spine. While the Spine entry is added to the new location after moving the files, the original entry in its prior location is not removed.

The attached sample.epub file is the resulting file after performing these steps.

[byword]

The same error persists in the 2.8.1 update.
I also tested the official 2.8.1 update file, and the same issue occurs.

I tested it on Windows 11.

[KevinH]

Thank you for the bug report. Since I was not even aware you could select and drag and drop non-consecutive/non-contiguous files (I thought drag and drop only worked with contiguous block selection) I am sure that case was never properly tested.

Please repeat your experiment using the new Reading Order Dialog which can also use Drag and Drop. Does it exhibit the same bug?

I will track down and get this fixed asap but it will not be today as I am tied up with no access but a phone.

[BeckyEbook]

In the "Edit Reader Order" window, you can select only one file, so there's no problem there.

Simply opening this window and clicking "OK" to save fixes the spine section.

[KevinH]

Good to know. So the problem/issue is the non-consecutive drag and drop. I will see if there is a good fix, otherwise I will force a contiguous selection mode.

[KevinH]

Ah! Native Qt does not support non-contiguos drag and drop reordering with their built-in code.

A quote from a web search:

Qt's default drag-and-drop mechanism doesn't natively support moving disjoint selections. To reorder multiple non-contiguous items, subclass QAbstractItemModel and implement a custom MIME type. Override mimeData() to pack the disjoint indexes, and intercept the drop in dropMimeData() to calculate the shift, removing and re-inserting the items one by one.

So I am not sure supporting it makes much sense.

[DiapDealer]

Curious what behavior (given such a thing was supported) someone would expect from a non-contiguous drag/drop here. Would all of the files become contiguous at the new drop point, or should the spacing between the files somehow attempt to be maintained?

I'm not being a smart-ass; it's just that a non-contiguous selection is simply not something I would ever think of dragging anywhere (anywhere but a trash folder or another folder in a file explorer).

[KevinH]

Well we can not simply turn off BookBrowsers ExtendedSelection mode as we would like the user to multiselect possibly non-contiguous html files for possible plugin use.

So it appears there is no easy way to turn off drag and drop if non-contiguous but still allow it for other selections.

So this might be a bit more complicated than I hoped.

[KevinH]

Okay, I found a way to subclass QTreeView to overwrite startDrag and disallow any drag if the current selection is non-contiguous. That is what I am going to implement to prevent the bug from happening,

The current Qt QStandardItemModel code always assumes when multiple indexes are selected that they are contiguous and therefore generates the bug when they are not. The reason Qt does that is that when multiple selections are non-contiguous, it is not clear either where the destination for each should be or if gaps should somehow be preserved. It is also unclear what if any relative order should be kept by simultaneously dropping items at one spot.

This is exactly what DiapDealer was concerned about above.

I will try to have a fix implemented by tomorrow night or Friday that will prevent this bug from happening.

[KevinH]

I finally got back home and was able to work on this. A fix that prevents drag and drop in BookBrowser when non-contiguous multiple-selections exist has now been pushed to Sigil-Ebook master.

This fix will appear in the next release.

The only workaround until the next release is to not use non-contiguous multiple selection for drag and drop reordering of the spine.

In addition it should be noted that dragging multiple non-contiguous selections in general is not a good idea as it does not make it clear if gaps should be kept, nor what the final target of each item dropped is meant to be, nor the order to use once dropped and support for it inside Qt was therefore never implemented.

Thank you for your bug report and detailed instructions on how to recreate the bug.
Very useful.

[BeckyEbook]

This type of non-contiguous selection is sometimes useful. I’ve never noticed this error in spine, but it often fixes itself – just drag a single file or a few contiguous ones, and the Spine section is fine.

Non-contiguous selection, by the way, has an interesting limitation – you can’t select all the "...in_book1.xhtml" files and move them directly under "book1.xhtml," because only one will be moved. You have to do it in two steps – first move them all to the very end, and only then to their final destination.

So I’m wondering if a complete block isn’t too restrictive – since you’ll only be able to move individual files in both BookBrowser and the "Edit Reader Order" window, just think about how many steps it will take to correct the example file.

[KevinH]

You can use Regex Rename to capture and mass rename files by putting book number first then chapter number in each name and then sort by name to create a new reading order faster in that case.

And you can still use multiple selection, it just that it has to be contiguous.

Given this problem has existed since the beginning of Sigil, and no one else has reported the bug (or even used it with a non-contiguous selection in my case), I do not think it is a common situation.

The only alternative is to create our own mimetype, store the indexes inside it, then unpack them and put them where you want 1 by 1 via code (which is not exactly clear) which requires new classes for each tree and model that inherit from the original and lots of code changes that may introduce more bugs.

If for a future release people want that feature we can explore that later (once people precisely define what they expect to happen with the gaps, final destination, and final order and all agree).

Just not worth the potential bugs in my opinion. But we can revisit that later.
if people think it is important.

[BeckyEbook]

OK. Over the past few years, I've had maybe three or four such cases, so it's not something I'd go out of my way to fight for.

Besides, I'll always find a workaround anyway

[DNSB]

I've run into that issue a couple of times and found that, as Becky stated, in the Book Browser windows if I simply dragged a single file to a new location, the issue was corrected.

[KevinH]

I have been reading and trying to understand where in the QStandardItemModel dropMimedata routine in Qt's source, the assumption that it must be contiguous comes into play but do not really see it. That source is quite involved as it must work in any QTreeView structure.

If we are 100% sure a simple single move and back will fix the issue, perhaps we could create a workaround that does that immediately after any drop. It is an idea to explore.