derf
Feature Request: randomised slide delays.
I realise I added this feature request in the wrong place before.. sorry!
I have code ready that I would like to submit. Its a simple thing but aims to make slideshows more interesting by varying the slide delay on a random basis. -D 15 Behaves as it always has, giving a 15 second pause between slide changes - nothing new there. -D 1,2,5,10,15 Give slide delays chosen randomly from the list, with each item having the same probability. Duplicate values are allowed. -D 1x10,2x5,10 Gives 10 chances to the 1 second delay, 5 for the 2 second delay and 1 for the 10 second delay. The actual probabilities being 10/16, 5/16 and 1/16 in this case. All arguments may be real numbers, so -D 1.2x10,2x5,10x0.5 Is valid and handled as you might think, giving 1.2 seconds for 20/31 of the time, 5 seconds for 10/31 of the time and 10 seconds for 1/31 of the time. This sounds more complex than it actually is! As was previously the case, a preceeding - to the slideshow delay string starts the slideshow in paused mode. (But otherwise everything is set up as it would be without the '-' ) This is essentially a simple fix that adds great interest to slide shows since the delay is not all the same! Its flexible and backwards compatible. I feel there is no downside to accepting this.
Could others comment with their thoughts?
Assuming this is accepted, I am not quite sure what the submission process would be. At the moment I have this as a local branch in git.
Hi Nigel,
It was a while ago I did this, but if I recall I was not able to create a pull request, needing permission to do so. But would be very happy to engage in discussion with anyone about its merits once a pull request is created.
Sounds like this would involve a C implementation of Python random.choices.
My other thought would be to separate the -D/--slideshow-delay delays from the --slideshow-delay-weight weights, but they would need to be the same size.
There is a complication that a negative delay implies paused mode.
case OPTION_slideshow_delay:
opt.slideshow_delay = atof(optarg);
if (opt.slideshow_delay < 0.0) {
opt.slideshow_delay *= (-1);
opt.paused = 1;
} else {
opt.paused = 0;
}
break;
So we'd also need to look at the first weight for compatibility purposes.
Would it be acceptable to limit the number of delays (and weights) to a fixed maximum such as 16 or 32?
Using a linked list in C is definitely more code than fixed-size array of struct { double value, weight, cumulative };
Sounds like this would involve a C implementation of Python random.choices. No, I dont think it would, its all C. So we'd also need to look at the first weight for compatibility purposes. Already handled, as stated. limit the number of delays It might be, but theres no need. Its malloc based, and parses the string each time on demand. This is fast as its very simple parsing and a very short string..
Thank you very much for spending time on this, by the way: whats frustrating is that I STILL cannot send my pull request, if I could do that not only could we discuss the code, but you could run it also and see if you liked it. We could discuss bugs (Surely not!!).
So my biggest question is how do I submit this code so that it may become the subject of analysis and discussion?
So in the normal scheme of things on github. Fork this repository into your own account. Then push your branch there. And once ready for review, file a "pull request" on this repo pointing at yours. Does that make sense?
https://docs.github.com/en/get-started/exploring-projects-on-github/contributing-to-a-project
That was pretty helpful and I now think I have a pull request! "Randomly Chosen Variable Time Delays for Slideshows #784 " I think you can see it here https://github.com/derf/feh/pull/784 Any comments about its functionality, would be very welcome.