[GUI Plugin] Walk Search History

[ownedbycats]

Minor glitch: When button is set to 'previous search,' clicking it after the search is cleared via a VL change will sometimes go to the second-previous search.

Screenshots to demonstrate. Searching for 'Discworld' in my Currently Reading VL:



Then I switch to 'Fiction' and press the button to go back:

[kiwidude]

@ownedbycats - I did originally type a message here asking for more steps but its because I dont use VL's myself, so on a learning adventure with them of these tabs like you have.

I did manage to get some kind of weird behavior happen so will look into it further.

EDIT 2: Ok I know what is happening. The issue is the clear search that is taking place. I intentionally ignore those "blank searches" not putting them in the history list. However this means the list of "real" searches that it maintains is now out of sync - by ignoring the blank it thinks you are still on whatever your last search was and hence going backwards should go to your second to last search. Whereas actually you want it to go to your most recent search.

Will sort out a fix...

[ownedbycats]

Yeah, I thought it was because 'clear search' is detected by the plugin but 'change VL (which clears search)' isn't.

[kiwidude]

Unfortunately it is like pulling at an end of a ball of wool, because it has me questioning other behavior in this plugin.

Right now I'm not happy with some of the inconsistencies in the history navigation. It was originally modelled after how web browser navigation behaves. The problem is that the calibre scenario is a lot more complicated.

So for example you searched for A, then for B, then for C:
- You have a history of A -> B -> C* (* being current search applied)
- If you were to dropdown the calibre search list it would also show (from bottom to top):
A -> B -> C*
- In this plugin you navigate back to B. So your history from a plugin navigation state perspective is:
A -> B* -> C
and you could from here choose to either go back to A or forward to C
- However calibre itself in it's dropdown history bar you will now see an order of:
A -> C -> B*
It puts your most recent search at the top of the list. Which is partly why I wrote this plugin in the first place to have a different behavior I wanted.

Where this starts to unravel, is lets say that we now (remembering we have gone from C back to B)...
- Do a search for D.

From a calibre dropdown perspective, it will just put D at the top of the list, so your dropdown list is now:
A -> C -> B -> D*

However this plugin attempts to follow the web browser model for how navigation works. And taking that approach, all knowledge of C (and anything in front of it) should be discarded from a navigation perspective. So your history is now represented as:
A -> B -> D*

Hence you cannot go forward, and no matter how far back you go you would never see C again using the forward/back navigation keys.

Where this gets more complicated is that in the plugin dropdown History menu, I show you effectively the same as what is you would see in the calibre search dropdown (i.e. A -> C -> B -> D* bottom to top). So you can get back to C using that. It is *not* attempting to show a visualisation of your navigation history being A -> B -> D* at this point. I don't know if that is right or wrong (personally I never use the History menu, only ever the navigation key shortcuts).

And finally the additional wrinkles to all of this is what happens when a user clears a search?

So from the top we had A -> B -> C* then user hits clear. What makes sense is to treat it as A -> B -> C -> * so that back goes to C, not to B which the plugin currently does. That is an easy fix I have made.

However what if the user now navigates back from C to B so we have:
A -> B* -> C and then user does a clear with B displayed?

From a calibre search dropdown perspective, the "last" search the user did was B. So it seems to make sense that navigating backwards after a clear takes you to B.

But should the user be able to navigate forwards after a clear, taking them to C? Or should it be treating a clear the same as the "new search" of D scenario above so anything forwards of the current point of B is forgotten about? In which case we now have:
A -> B -> *

And this gives us behavior arguably more consistent, but perhaps annoying for the user...

Sigh, long post, head hurts...

[ownedbycats]

My brain's a bit too mush to understand all that right now, but here's basically how I noticed it:

1. I was in my On Device virtual library. I clicked on 'Discworld.'

2. Then I switched to my 'Series' virtual library so I could see a different set of information and sorting (view manager views, and action chains plugin can auto-switch them on tab change). But this cleared the search.

3. So I pressed the WSH button to get the 'Discworld' search back. Instead, I got the second-last search -- in this case it was a template search I was testing (I cleared the search history before replicating it for the screenshots).

[kiwidude]

Release Notes:
https://github.com/kiwidude68/calibr...history-v1.5.3

@ownedbycats - this implements the logic I explained above (while fixing your issue).

Now if an empty search occurs (either by the user hitting Escape, the clear search button or switching virtual libraries) the navigation history resets the top of the list. So now when you navigate back after that empty search you see the last non-empty search you did (not the "second to last" which was a bug). And you can no longer navigate "forward" from that position.

If someone could give it a whirl and confirm no issues I will release it in a day or two...

EDIT: Released now

[ownedbycats]

Yes, that works the way I expect.

[kiwidude]

Release Notes
https://github.com/kiwidude68/calibr...history-v1.5.4

To anyone wondering what the flurry of updates on most of my plugins today was for (without reading the release notes). These were all translation updates only, not a single code change. My thanks to all the translators out there who have contributed their efforts to my plugins (and had to wait until now to see those included).

I always grab the latest translations whenever I push a code change release out. However as the majority of my plugins are rarely requiring any changes this sweep through was necessary to grab all those translation efforts.

[ownedbycats]

Well that explains why the plugin updater keeps going off, lol.