Advanced TOC editing - details and others

[KevinH]

Originally Posted by DNSB

For those using Windows, here is a link to the version with the next generation of fixed advanced ToC editing: Sigil-2.8.1-Windows-x64-Setup.exe.

As per a request by one user, the SHA-256 for this compile of Sigil-2.8.1-Windows-x64-Setup.exe is
18A295493275BA3A798B03CA1352BE8B8657C7007E62697C36 CA50492E231ACA

Thank you!

[icearch]

Ok, I have tested the newest version, and i'm happy to say that most problems has been solved.

Just some minor ones:

1. Sometimes when selecting or after movement, the seciton that dispaly items will scroll to the most right position. It's not a deadly bug, and maybe my own problem, just bringing it up.

2. The crush still exist, and I have narrowed it down to this: If the items you choose have parent-child relationship (can be grand or more generations), and they are not adjacent (not first born), when you click move right, Sigil will crush.

But sometimes when you moved other items around a bit, it will not crush, even if you just did what I said above. You can reproduce this consistently when you open the software fresh.

[KevinH]

If you choose a parent and a child but not the first child, they are assumed to be two independent choices not a block. So moving the parent right will already move all its children right then it will try to move that independent selected child right once again. Is that what you wanted?

The order of how these are done matters here I think.

If the independent child is moved first, you get one result, if the parent is moved first do you get a different result? We can try that by doing single moves in both orders. If both end up with the exact same order, then the multi-move code should generate the same thing no matter what the order.

Exactly what did you expect to see in this case?

Also to make sure I understand what you mean by "crush" (is it to "compress" or something else?) please provide both a before and after screen shot of a single reproducible example so I can see what you are seeing.

Thank you.

[icearch]

No, the software crush to desktop, it broken, quit.

I have nothing to say about how it should work because it just didn't proceed and crush to desktop. But from few instance that it doesn't, it seems to be fine as it is now.

[KevinH]

Oh you mean "crash"? Here I thought you meant "compress" as in children of parents move left instead of right somehow.

A "crash" is a completely different thing!

I have never seen this code crash (yet) on macOS so this may be a bug in our code or a bug in Qt on your platform.

I simply did not understand what you were saying. Crashes should never happen.
I will look what causes that and try to fix or prevent the "crash".

Thanks!

[icearch]

If you need any information of my platform, just ask.

My bad, I spelled crash wrong so many times.

[KevinH]

Just to verify, how you recreate the crash:

Select a parent and its second child but not the first, then hit Move Right.

Is that correct? Is there anything more? Does the crash happen every time of only sometimes?

[icearch]

I tested this in my old file, and to be sure I created a new file, and you can reproduce this consistently.

But the premise is a bit unclear, seems more reasons needs to be found.

untitled.epub

Use this, Ctrl select C and E, Or C and I, it will cause crash. But strangely E and I does not.

And I tried again, E and I crash too, but it didn't do that like 3 times. So I think the possibility mybe 90% the time?

[KevinH]

Okay, I could not get it to crash on my MacOS laptop (x86_64) but I could get it to reliably crash in my MacOS desktop (arm64).

So now that I can recreate it reliably I will track this down and fix it!

Thanks

[icearch]

So I think it might be:

If we choose a parent and a child:

1. they must be related

2. the parent must not be top level (this one not tested throughly)

3. the parent should not be the first born

4. the child should not be the first born

5. the child should have it's own child

[icearch]

Originally Posted by KevinH

Okay, I could not get it to crash on my MacOS laptop (x86_64) but I could get it to reliably crash in my MacOS desktop (arm64).

So now that I can recreate it reliably I will track this down and fix it!

Thanks

Hope everything goes well, thank you for your effort and patience.

I'm win11 desktop by the way.

[KevinH]

Okay, this should now be fixed in master.

As it happens Qt's selection ranges are supposed to use QPersistentIndexes (which means that the Indexes (pseudo pointers) to those ranges are supposed to be automatically updated whenever rows are moved.

Unfortuately, instead of updating, for a move right of the type you described, Qt just invalidated the range (which is what caused the crash as I did not know that a range of an array could have a top row of -1 and bottom row of -1! ie. be invalid).

So to prevent this incorrect invalidation, Sigil must move right any child BEFORE their original parent or original grandparents are moved.

So that is what I just did. Move rights of the type you described, now no longer crash and seem to work.

I have pushed this change to master.

Nice job tracking down that bug and figuring out how to recreate it!

Thank you for all your testing and feedback.

[DNSB]

Link removed as obsolete.

[icearch]

Good news: the crash rate drops to 30%!

Bad news: the crash rate is still 30%.

It works like charm in like first 5 tries, but I tested like 8 times and it starts to crash again. And just like disease, the crash rate strat to go up to like 30%, I tried to uninstall and re-install, the outcomes stay the same, the problem has solved - partially.

You can try doing it like 10~20 times, it maybe repoduced by you.

I'm going to rest so no reply soon. Hope you guys rest well too.

[KevinH]

I have now tried repeating it 10 times both inside and outside a debugger. It all just seems to work no matter what I try.

That fix should prevent the bad indexes. So this must be a new type of bug?

Could you have by accident run the previous build of Sigil on your tests 6 through 8?

Or did you change the initial structure in some way from the simple case of:

"Select a parent and its second child (not selecting its first child) and hitting move right"

That is what I have been running my tests with as it always triggered the initial bug on MacOS Desktop.

Exacly what structure are you testing with?