xscreensaver-getimage and xscreensaver-getimage-file don't respect "chooseRandomImages: False" in .xscreensaver

This bug was fixed in the package xscreensaver - 5.12-0ubuntu2

---------------
xscreensaver (5.12-0ubuntu2) natty; urgency=low

  * debian/patches/60_sequential_glslideshow.patch,
    debian/patches/series: fix LP: #671514, enable xscreensaver-getimage-file
    to run sequentially
 -- Dustin Kirkland <email address hidden> Thu, 25 Nov 2010 16:39:27 -0600

Please see the man page for xscreensaver-getimage for an explication of the chooseRandomImages option. Setting it to false does not mean images should be selected sequentially. So the "bug report" here is invalid.

However, a feature to have a sequential slide show sounds like a good idea. I would encourage you to make an "upstreamable" patch. I don't see why Ubuntu should carry such a delta in form of a undocumented "hack". There is also a couple of issues in your patch (which seems to have been released in Natty without any review) which I have tried to address in the attached patch:
1) there is no checking for index overflow once the image list has run out
2) the hard-coded index counter file name is not portable
3) the counter is incremented, then decremented in a conditional clause (confusing)

I have omitted the check for chooseRandomImages in the configuration file, and just rely on the existence of an index file. It might make sense to check for a "chooseSequentialImages" option instead, which also needs to be honoured in other code. But the upstream developer might have other suggestions for how to implement this.

BTW, is this part of a bigger plan for something in Ubuntu, or just a private "itch"?

On Thu, Jan 6, 2011 at 4:44 PM, Tormod Volden <email address hidden> wrote:
> Please see the man page for xscreensaver-getimage for an explication of
> the chooseRandomImages option. Setting it to false does not mean images
> should be selected sequentially. So the "bug report" here is invalid.

Thanks for the pointer.

> However, a feature to have a sequential slide show sounds like a good idea. I would encourage you to make an "upstreamable" patch. I don't see why Ubuntu should carry such a delta in form of a undocumented "hack". There is also a couple of issues in your patch (which seems to have been released in Natty without any review) which I have tried to address in the attached patch:

Well, sorry about that. I've been working on this locally, trying to
get something more upstreamable but I've hit a few roadblocks, and
then got distracted by real work. This is a spare time hack, trying
to scratch a personal itch. The current "hack" doesn't break any
existing functionality, and I was still working on it, with the
intention on submitting it upstream as soon as it was ready.

> 1) there is no checking for index overflow once the image list has run out
> 2) the hard-coded index counter file name is not portable
> 3) the counter is incremented, then decremented in a conditional clause (confusing)

Agreed on all 3 accounts.

> I have omitted the check for chooseRandomImages in the configuration
> file, and just rely on the existence of an index file. It might make
> sense to check for a "chooseSequentialImages" option instead, which also
> needs to be honoured in other code. But the upstream developer might
> have other suggestions for how to implement this.
>
> BTW, is this part of a bigger plan for something in Ubuntu, or just a
> private "itch"?

Definitely not part of any larger plan, more a personal itch.

I've installed dozens of applications from the archive, trying to do this:
 * Cycle sequentially through a directory of ordered images, with
smooth fading, panning, and zooming (aka "the Ken Burns effect), such
that I can "watch" an album of my pictures in a professional,
documentary-like fashion.

Most image viewers have a "slideshow" mode. Some even have (really
cheesy looking) wipes between images. But when I found this
gl-accelerated screensaver, it did 90% of what I needed. Getting
images cycled in order was the first problem and easiest to hack.

Next, I'd like to be able to run this in full screen mode, on command.
 If I run from the command line, it runs with "window decorations".
But if I launch as a real screen saver, it seems to work full screen.
I suspect it has something to do with the application being able to
write on the root window. For now, I'm okay with configuring it, and
then running as a screensaver.

Finally, and most importantly, I would really, really, really like to
render the output to a file (mpg, or the like), such that I could
compress and share the slideshow as a video, shared on YouTube, or
something. In the mean time, I can capture it with xvidcap, which,
again, is hacky. Ideally, though, there would be a way to write the
output straight to disk.

I haven't worked at all on the latter tw...

You can run a xscreensaver hack on the command line with the -root option and it will draw on the root window. However the root window is normally hidden by desktop backgrounds. If you log into a failsafe xterm session you can see it working. It should be possible to write a small wrapper that does the same as the xscreensaver in this regard: make a full screen on-top root window and call an application to draw on it.

For rendering directly to file, usually the drawing is heavily accelerated by the graphics card. So if you don't want to see it you may be able to render to off-screen buffers in the graphics card, or do the slower pure software rendering. OTOH maybe there are flash applications around to make and distribute such slideshows in a more bandwidth and storage friendly manner than to record a movie out of still pictures?

The upstream, mainly sole developer is jwz, see http://www.jwz.org/xscreensaver/ You may send patches to him directly. He also reacts to Debian bug reports from time to time, so that is another possibility.