Add "Open (opened+unopened) random document" on long-press

[artjomsR]

Would help with reading texts in parallel, especially when it's difficult to decide which one to pick next :)

I've considered grouping both Random functions into a folder, but that would introduce friction with using them.

---

This change is 

[hius07]

Looks good.

[artjomsR]

Is there anything I can do to support this PR? It's been a month+ with no activity, whereas other PRs are getting at least some action. It's not a big change

[Frenzie]

I'd name it something like unopened_only or skip_opened or a variety of other things that don't imply it's a property of a file. Besides that lgtm.

[artjomsR]

Thanks! I've updated the PR to rename the parameter

[poire-z]

I've considered grouping both Random functions into a folder, but that would introduce friction with using them.

You could have put in on long-press and hide the "feature" a bit :)

(Personally, I find this kind of "feature" a joke/toy. I missed (or forgot) the addition of the existing "Open random document". Seeing 2 crappy button in there makes me sad.)

[artjomsR]

You could have put in on long-press and hide the "feature" a bit :)

What do you mean exactly by a long-press here? Do you mean to display another context menu when long-pressing Open random document (effectively creating a nested context menu)?

(Personally, I find this kind of "feature" a joke/toy. I missed (or forgot) the addition of the existing "Open random document". Seeing 2 crappy button in there makes me sad.)

It's useful to me personally, and other people as well, seeing how there were contributions to this feature previously. It shouldn't matter if the feature may not be perceived as serious, as long as it provides value / enjoyment to users (which it clearly does)

@poire-z

[poire-z]

What do you mean exactly by a long-press here? Do you mean to display another context menu when long-pressing Open random document (effectively creating a nested context menu)?

Just have the most useful (ah ah) behaviour on tap, and the less useful on long-press, no need to advertise both. We have that in frontend (ie. Book map, long-press brings the "overview" mode).
Most features anyway are available and used via a gesture, where both actions are available there.
The same could work for this "open random document" feature.

It shouldn't matter if the feature may not be perceived as serious, as long as it provides value / enjoyment to users (which it clearly does)

2 years ago, some user came here with a PR that added in that same menu 3 options:
Show fishes swimming on the screen while reading
Show birds flying on the screen while reading
Select opacity of fishes and birds
I obviously got the same reaction as here : it's ridiculous !
But that user assured me that he - and his mother - would be provided value and enjoyment with having that, a little animation over an otherwise static screen page. I understand that young people get sick nowadays when nothing on a screen changes for more than 20 seconds. But still, it's ridiculous, and I stuck to my position: it was rejected.
Later on, there has been tensions between that user and his mother, and I still carry the guilt of my decision...
But because of my decisions, you (and the person who added "Open random document" in here) got to have the room in that menu to add your menu item.
One day, when we'll need to add more useful features in that menu, we'll probably hate you for having added it :)

The above is a fiction, but you get my idea :) We still have to do some policing work so KOReader doesn't becomre a crappy stack of features used by 2 people.
I stated my sentiment, @Frenzie approved, so OK I guess.

Having a quick look at the code, I assume "Open random document" opens a document from the current folder (and under?), and it won't just open any random document from the library root. So, it's not as crappy as I initially thought.
(And I find it crappy in that if that random document does not please you, or is big, you'll have to wait 40s for it to load to be able to choose another document - and you'll have to clean its sidecar and the book from history...)

[Frenzie]

I stated my sentiment, @Frenzie approved, so OK I guess.

I don't disagree with you, but it's seems small and contained. And yes, it's folder-bound.

[artjomsR]

And I find it crappy in that if that random document does not please you, or is big, you'll have to wait 40s for it to load to be able to choose another document

It prompts you with the name of the document it's about to open, so you can simply skip undesired documents, so that should help with this issue

[hius07]

I agree that the current "Open random document" button can be kept as is, and the new functionality (include opened documents) to be added to long-pressing on the button.

[artjomsR]

@hius07 I've updated it

[hius07]

You've changed the default action (on tap).

[artjomsR]

@hius07 Yes, if you were to combine both actions, then I think it makes sense to change the default: opening any document would be used more often (during the same time period) compared to the unopened document. I.e. the user eventually runs out of unopened documents, so that functionality becomes used less and less

On the flip side, you could be using open any document functionality several times per reading session, every session, so it doesn't make sense to prolong invoking this functionality

[hius07]

the user eventually runs out of unopened documents

He adds new books regularly.

I have no personal preferences (not using this feature). Just thinking about the long time default behavior that people might be used to.

[artjomsR]

@hius07

He adds new books regularly.

Fair, but my point still stands that any random document has the potential to be used more often just by its nature. Software changes all the time, so I don't see how the user wouldn't adapt here as well, it's not a big change. I don't think it's logical to keep the non-optimal default behaviour just because it was introduced first.

[Frenzie]

What's the old and what's the new behavior now precisely? (Or: write a commit message please ;-P)

[artjomsR]

@Frenzie

Before / master

On tap: open unopened random document

After / this PR

On tap: open any random document
On hold press: open unopened random document

[Frenzie]

What's the rationale for making the unexpected behavior the default?

[artjomsR]

@Frenzie Basically because you'd use opening any doc a few times during a reading session, but unopened doc - only occasionally. And due to the nature of the Open any doc, it seems logical to make its invocation to be fastest

From my comment above - opening any document would be used more often (during the same time period) compared to the unopened document. I.e. the user eventually runs out of unopened documents, so that functionality becomes used less and less

On the flip side, you could be using open any document functionality several times per reading session, every session, so it doesn't make sense to prolong invoking this functionality. I don't think it's logical to keep the non-optimal default behaviour just because it was introduced first.

[Frenzie]

I'm not quite convinced, but I suppose I'd really expect it to avoid the previous x results, which has some overlap with previously opened but is something quite different nonetheless.