Advanced TOC editing - details and others

[KevinH]

I tried to more closely follow your descriptions and have selected the following and then hit Move Right.

See attached image:

The parent (Chapter 3) is not the first child of anything.
Chapters 4, 5, and 6 are its children.
Chapter 6 is not the first child of Chapter 3
Chapter 6 has a child (Chapter 7)

I think this test case meets your description from above:

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

Are we agreed this is a valid test case that meets your criteria?

[KevinH]

Okay with the above test case, I get a crash!

The problem is the order these ranges are presented to the MoveRight routine by Qt are now in reverse order than is expected!

The order presented by Qt:

Parent  TopRow BottomRow
Ch. 3        2          2 
Ch. 1        1          1

Which is the exact opposite order that previous test case that crashed was!

For the earlier testcase Qt always gave an order of the parent first and its child second. So the solution to that was to always do the order in reverse so that the child went first.

But in this case Qt gives me the child first, so reversing the order is the exact wrong thing to do with this second test case.

So somehow the selection order presented to the routine is random!

Sometimes leading with the child first and othertime leading with the parent first, so there is no easy way to see how these ranges should be ordered.

This will not be an easy fix.

[KevinH]

Okay, I have designed a way to compare the topleft of each user's selected range so that the ranges can be pre-sorted from top of the tree to the bottom of the tree.

That way, no matter what order Qt presents these ranges, when order matters we can move the child before the parent.

Hopefully, this will be the final fix as this code is getting ridiculously complex just to allow multi-selection to work in some sane matter.

I hesitate to think how long this code will take when presented with a tree of thousands of titles, and the user selects hundreds of ranges.

Would be a fun test!

All of this has just been pushed to master. I am calling it a day.

[DNSB]

For those using Windows, here is a link to the version with the, hopefully, last renditions of the advanced ToC editing fixes: Sigil-2.8.1-Windows-x64-Setup.exe.

The SHA-256 for this compile of Sigil-2.8.1-Windows-x64-Setup.exe is:
2744A08ABAC453764B4ECFEE9750EFAD2E6B566B7EFDABB789 150FF81A1626EF

[icearch]

Yes, we finally made it.

I tested with dummy files and a real one with like 200 h3 titles, and it works no problem.

Thanks everyone for their effort and help, and welcome others to test out the latest version.

Though mind others that want to try out: due to the catual approach, one should not employ the way of :"indent all then un-indent the wanted ones", cause it would cause the un-indent ones drop to bottom because the rest is still the childern of the original parent. Instead employ the way of "un-indent all then indent what you want".

I don't think it need to be changed or something, just different approach. And we all work on this feature way too long now, so let's call it a day.

Thanks again to all pepole worked on this. Hope the best.