Opened 10 years ago

Closed 10 years ago

#4668 closed bug (fixed)

ShowImage Slide Show behaviour

Reported by: Malthus Owned by: leavengood
Priority: normal Milestone: R1
Component: Applications/ShowImage Version: R1/alpha1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by aldeck)

Try this: use Find to construct a query which returns several jpeg pictures, preferably from more than one folder. Double-click one of the entries in the query results window to open it in ShowImage. Now run ShowImage's Slide Show feature and see what range of pictures you get. (Alternatively use Previous and Next to scroll through them.)

It *almost* works. That is, the slide show scrolls through the files in the query results window as though it were a regular Tracker folder and regardless of the files' real locations - until it has displayed the last file, when it jumps into that file's real location, and displays any pictures in that folder which follow it alphabetically. If I haven't explained that very well, the attached screenshot should make it clear: I've got two folders containing jpegs; also a query results window picking three particular files from those two folders. Now if I double-click on one of the entries in the query results window then start a slideshow, it should rotate through Lily00029.jpg, MrPink and R0012584.JPG. In fact it gives me those three plus Shrub00019.jpg and SPACE_SHUTTLE_O_20090901.jpg - ie the pictures following R0012584.JPG in the /boot/home/Pictures folder.

I don't know if the developers were even thinking of queries as a means of choosing pictures for a slide show, so I don't know whether this behaviour, imperfect as it is, is by accident or design but, working well, this would be a useful feature. I'm particularly interested because I've catalogued my jpegs with indexed custom attributes - captions etc. It would be great to be able to bore dinner guests with themed slide shows, without the show suddenly going off-topic :-) This is long-standing behaviour, of course; I've been using ShowImage in BeOS for some time, and I've always realised query-based slideshows don't quite work as I think they should. But I've only recently figured out exactly where the extra pictures come from.

Attachments (1)

Slideshow.png (236.4 KB) - added by Malthus 10 years ago.

Download all attachments as: .zip

Change History (6)

Changed 10 years ago by Malthus

Attachment: Slideshow.png added

comment:1 Changed 10 years ago by aldeck

Description: modified (diff)

having a look

comment:2 Changed 10 years ago by aldeck

I tried different scenarios, i couldn't reproduce the problem unless i modified the query while the slideshow was running. Is it the same for you or does it happen also when not editing the query.
Also, for reference, what haiku revision are you using?

comment:3 Changed 10 years ago by Malthus

Well I'm surprised. Happens every time here. I'm in R1/Alpha1 Revision 33109 but as I say, ShowImage has always done this in BeOS R5 too. In R5, I have a swag of saved queries as my virtual photo albums, and have long known that the behaviour was not what I expected. I'm certainly not modifying them while the slide show's running.

I've just tried again with that ~/Pictures/test folder you can see in the screenshot: If I go Find> Jpeg Image> By Name "Harbour" then the only result of the query is that first file - but the Slide show rotates through all three.

And if I go find by name "Lily" then Lily00029.jpg is the only result but the Slide Show rotates through that and the Lyndon1.00016.jpg picture. ie the extra files are everything alphabetically following the last file, in its "real" folder.

And on the hypothesis that it's something to do with my jpeg file type having custom attributes, I've just created four tiff files in a folder, made a query that finds the third, opened it from within the query result window and run a slideshow - same thing: the slideshow displays it and the fourth.

comment:4 Changed 10 years ago by idefix

Could you test again with Haiku hrev34103 or greater? That changeset should also have fixed this bug.

comment:5 Changed 10 years ago by axeld

Resolution: fixed
Status: newclosed

Indeed, thanks for the note, I knew there was another ticket out there.

Note: See TracTickets for help on using tickets.