Advanced TOC editing - details and others

[KevinH]

As for your number 2 above: I have fixed this in master. The problem was not actually the code that did the move, it was the code that reselects the original set of now moved items since that selection is lost during any move. This is easy when there is just one item being selected at a time, but has turned out to be a major pain in the ass as reselections were not properly merged in to grow contiguous regions meaning the next time you tried to do a move down, the selection appeared correct but was not a contigous range and instead a selection of individual items and then movement order and direction really matters.

You can see this with your test build by doing a single contiguous move down, then manually reselecting the same (now moved) items with a click and a shift click. Then hit down arrow again. This time it works! But only because you properly reselected it after the first move. Obviously that would not work long term but it strongly hinted at the real problem.

So I had to figure out why or how merging a selection from its individual items (which appeared to highlight the correct rows) but was actually a mess underneath, could actually be done properly. It turned out I had to completely regroup things into contiguous ranges and manually select each range.

Either way this should now work correctly.

As to your number 1: we must disagree here. I do not think of the items I selected as being a rigid solid block that you must abort moving when any of it can not move (even one small piece of it) as you seem to do. I view them as a collection and of those in the collection that have a legal move, go ahead and move them. And for those that hit a boundary, and can not move, drop them from the collection but still perform the move.

This seems to be quite safe as a user can use the toc editor to fix whatever mess they made by "spamming" ie. trying to force one part of an illegal selection to move in a direction it can not (thus why I call the selection illegal for that move, it includes something selected that can not move in the direction told to.

I frankly like what it does and expected it. You obviously thought otherwise. Not sure if one of us is right and one of us is wrong, just different expectations.

I am going to leave the current code (with the fix for number 2 just pushed to master) around for a while so that others can comment if they like that behaviour or if they prefer yours.

[DNSB]

Link removed as new version uploaded.

[icearch]

Sure, if you think user should be responsible for not spamming, I agree. I just want it to be more like idioit proof or prevent accident slip/ multi hit. But fair enough if you think otherwise.

[icearch]

Well, bad news buddy, you haven't fix it throughly.

I just tested it, and the bug I mentioned in testing moving right still exist (ie. when you select items in diffrent ways to get the same final group).

Here is the thing: I Shift select EFG to test move down, and I changed my mind by Ctrl H too. And guess what? It messed up. So I restart and reopen the file, this time Shift EFGH all, it works fine.

So I think there still bugs hiding around.

[icearch]

Here, I Shift DEF and Ctrl G and H:



And hit move down once:



tada

Moving up does not have this problem, works pretty robust.

[icearch]

I think you might want to read my test of moving right and left again more throughly, it's not just about sapmming, it contains software crush and different behavior with same start condition.

[icearch]

And I just repeat my test of moving right and left again, good news is it seems fixed most problem, and if you restrict yourself to just select items with same level and parent, and do not spam, it seems to work fine (need more testing).

But the crush one still exist, you might want to look into that.

[KevinH]

And it happens because you can not move right one of the selected items so it's dropped but the next item then moves under it. Again this is expected given the drop from selection at the boundary.

[icearch]

Hold on, cow boy, not so fast.

I think might just paly around for good measure, and I just random Shift and Ctrl, Select and un-select items till I got:



And hit move right once, and you guessed it:



So there are definatly bugs when it comes to selection, you might want to looking into it.

[icearch]

Originally Posted by KevinH

And it happens because you can not move right one of the selected items so it's dropped but the next item then moves under it. Again this is expected given the drop from selection at the boundary.

Oh, we cross post, which one are you mentioning?

[KevinH]

Yes, the order you select a multi-selection actually impacts how it works. Qt treats a contiguous click and shift-click of n items different from that done on n-1 items followed by a single add-on to reach n contiguous items. It is differently reported by Qt.

So unlike single-click selection, how the user actually selects a multiple selection (in pieces vs totally matters and order does matter.

So if you want to build up a region by individual clicks and not a single click-shift-click it will will impact the result that Qt reports the user's selections.

That is why I had to rebuild the selection to form normal ranges to get the follow-on move right to work at all.

I will look into replacing all of Qt's internal selection mechanism with my own to try to properly make it selection order independent just like I already did for the reselection issue that broke move right.

[icearch]

Thank you for your effort, here waiting for good news.

[KevinH]

In your example above, to Qt it looked like a bunch of single selections that just happened to sit by each other. And according to Qt to get an actual contiguous range selection, a user **must only** click on the starting item and then shift click on the ending item. That is the only way!

That is why you saw what you did above.

This choice by Qt will not be clear for the majority of users since no other software I know about makes this distinction.

So I just pushed a change to Sigil master, to make user selections consistent no matter how the user produces them.

Sigil does this by growing our own contiguous ranges every time the user selects move up, down, right, or left and actually replaces the user's final selections with proper range selections. In that way it will not matter how the user reaches that selection, only that it is contiguous (so the items in that block are all treated the same way at the same time).

This should fix those cases you reported immediately above.

Hope this does the trick.

[KevinH]

Oh and just to test icearch's approach, I have just pushed the changes to prevent any movement when any of the multiple selections are at a "boundary" for the move selected. In other words, treat them like they are a rigid block.

Please give this try and compare it to the approach of just dropping items that reach the boundary from the current selection and moving all the other ones in the direction asked for (previous to this last commit).

Please let me know which approach is preferred.

[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