1) If I desire to preview a set of files in sequence, this allows me to specifically mark which files I want processed...whether they be contiguous in list or scattered, like #2, #7, #9-#12, #23, etc.
although, i can see the utility of this, i would much rather implement this ability using dropstacks rather than the multi-select method because it would cater to both needs. although i agree, that without a dropstack, it would provide challenges for trying to play a group of files. my needs are less for playing multiple files (which i use a media player for) and more oriented for manipulating the currently playing file. i realize these two different intentions will see this feature a little differently so i understand your position.
2) When a file is being previewed, it (by design) must be one which is currently selected, thus blocking the ability to do any other operation (like delete, rename, etc) on any other file, as when one selects THAT file, the preview stops on the prior file...which is somewhat a restatement of my contention that one can essentially only do one function at a time in a given list...either manipulate files -or- play/preview them.
you can move/copy/rename the *current* file being previewed in xy. xy preview will release it for the operation. because i am generally attempting to manipulate the current file being previewed, this makes the single selection preview ideal for sorting through and organizing files. as i mentioned above, by having a multiple selection preview system, files must be deselected, the operation performed, and then files reselected.
3) If the abililty to preview files one after another were done simply by how they appear in list, how would I then be able to select a subset, as in reason 1 above? Often files have no common criteria that would lend itself to a filtering, and picking from list allows most flexability in choice.
you are right, this would not be possible using my method without using a drop stack. my method is designed for sorting though files not for making a playlist. in my mind, there are plenty of players that are well suited for playing a selection of files but there are none (that i have found) that help you sort through a collection of files like this. to me, the latter seems more consistent with the purpose of a file manager.
Believe it or not, I'm somewhat in favor if this basic idea, so don't think I'm being too negative...just attempting to find any possible defects in design ideas before any coding is done...it's part of my background/training!
discussion is never a bad thing! i just think our expectations of function are different. i also have to design for coders so, as you can probably tell, i am painfully thorough.
I'd also insist that this 'autoplay of next' be easily toggled on/off...and... yes, this would lend itself into morphing into a primitive slideshow if applied to graphic files, via minimal extras (with addition of a setable delay factor between images).
yes, there would have to be radio options for 3 different modes for what happens after a file finishes playing:
- loop (probably better termed repeat using media player terminology)
- play once (the default behavior)
- play next (the behavior we are discussing above)
Just FYI: there is a (nonauto)-next already implemented in XY: full screen preview PageUp/Down will search the next image file in the desired direction (up or down), select it, and preview it.
yeah, i currently manually focus the next file when i sort audio and when i find that i need to edit/move/delete a file, i can access what i need from the context menu. this feature would just cut down on the mind-numbing repetitive nature of it because i could just listen for necessary changes - might save a few years on my insane-o-meter
anyway, i appreciate everyone's response! this is good stuff!
