Change to stack sorting
It's a subtle change but one that might have a big effect, especially those that carefully curate their collection and how it looks. No it isn't stacks inside stacks, for those that want that, haven't taken a look yet. It will help stacks be more flexible and may help have less glitch.
It should help the cover for a stack changing seamlessly randomly or sorting not being consistent. I've already pushed some related work last update, when adding Series sorting to Virtual Tags. This change actually removes that, because this change gives more options.
First I will explain how grouping/stacking works. Myself I've been confused with it in the past requiring to check the code to understand and I've seen posts asking how to setup stacks correctly. So this will also serve as a reference for anyone interested.
When calculating the cover positions it starts with grouping, that part isn't that problematic. It creates groups based on your config. Then in each group it processes the stacks. When stacking, items in a stack are ordered based on your stack config, so if you are stacking by Series, it sorts by Series. Then the sort config comes into play, it sorts all the first item of each stacks and sorts them for your group. Any config inside the stack doesn't affect anything outside (until now).
The problem occurs when the stacks are sorted. When sorting is done it uses something called a comparer, it is a simple function that takes 2 books, compares them and says if they are equal, one is before or after. Every field in the program has one of these. Some compare dates, numbers or just text.
But since stacks are sorted by the same value they have been grouped together, all the values are (usually) the same. What goes before Marvel, Marvel or perhaps Marvel? With stacks like Published since it's a date when sorting chances are all the value will be unique. Series is also special, when you sort by series it actually sorts using this order Series → Format → Volume → Number. So if you are stacking via Series it actually sorts pretty much correctly. But when you take something like a Series Group, Virtual Tag or Publisher all the values end up the same.
If you've ever stacked with Series Group you might have ask yourself why is the cover not always the same? Try it by pressing the Refresh button (or F5) repeatedly. Since the sorting becomes worthless with text fields, the item that ends up first is just the first item that was added. Since items are added in a parallel way, the order can change on the whims of your CPU. You can even see a different cover appear mid refresh, because it recalculated, each time with a potential different top cover showing.
Then imagine you are sorting these Publisher stack via Published, since the sorting is done on the top issue and that is pretty much random, you end up with a different order for each top issue it chose during that particular refresh. This might also explain the glitch that happens when changing from a list with a stack open and returning to it later having items missing in that stack. That last one is still an hypothesis, but I believe it is because the key for the stack is also the top issue, since it isn't always the same it gives unexpected results.
So starting with the next update the stack will (in addition the existing sort) be sorted by the config set inside the stack. This will determine what appears as a first issue. In case of still needing a tie-breaker the position comparer will be used as a last resort Well scratch that last one, position is also random, sigh. So you should have a consistent order no matter what. The Series comparer is also now the default if no setting exists. It also doesn't take into consideration any grouping done inside the stacks, it just uses sort.
That last point requires additional information. Something I myself discovered only lately. There is a setting disabled by default called All Stacks in a List have the same Layout. By default (disabled) each stack has it's own config/layout, but when enabled each list uses a common layout/config for each stacks inside a lists. This will have impacts on the new changes, since you can have a separate possible sorting order for each stacks.
Stack configs are only created when opening and closing stacks. So if nothing is configured yet each stacks will default to being sorted by series, before being opened. When opening a stack for the first time the UI defaults to the current config you had at the time of opening. So it will save whatever config you had or any you change into.
Keep in mind that stack configs are limited, you were limited to 1024 stack configs per lists. I've doubled that value, but do not want to increase it too much, it was there for a reason. Not sure if to keep the database smaller or performance reasons.
If you aren't seeing the covers change like in my image because your current stacking is already sorted correctly (like using the series stack), this will not change anything. The additional sorting is only in the cases that multiple values might be the same.
If you are currently using Set as Top of Stack to achieve the same result, it will not affect you. Setting the top of the stack just forces that particular book to be the first.
Related to that, I've added in a setting called Reset Top of Stack, to reset the top issue that is being forced. It will be grayed out unless a stack already has a top of stack set. So checking that option is a way to determine if you have it set. It's a possible reason why the new change might seem to not be working. Ask me how I know 😁.
Fret not those that might like these dancing covers or are worried about performance, I've added an option to return to the legacy behavior (Check the ComicRack.ini or use the command line switch.
Copied from this Reddit post.