Feature Request: randomised slide delays.

[TheDoktar]

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.

[TheDoktar]

Anything? Its been 2 months.

[nigels-com]

Is there a link to a branch for this? Or a PR?

[TheDoktar]

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.

[nigels-com]

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.

[nigels-com]

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.

[nigels-com]

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 };