saulgreenberg
commented
8 years ago Clarification. Yes, this is by design. While it is possible to automatically reapply the filter after every edit, that could be even more confusing (and computationally expensive) as an image being edited could then disappear.
Possible solutions:
1 Leave it as is. We can document this behavior in tooltips and in the manual, and explain it at the top of the custom filter. I suspect people will figure it out anyways.
2 Change the name of the operation. Instead of 'filter' we could call it 'Search... or 'Search for subset...' or 'Select a subset of images ... '. I think people would expect searches and selections to apply only when the operation is invoked (vs the term filter which, as you noticed, could be interpretted as applying over time)
3 As described above, we could test each image to see if it fits the filter, but I am not sure its worth the extra computational cost (e.g., it could slow down going through images in sequence (arrow, scrollbar) unless we put a timer on it.
twest820
When a filter other than all is selected editing a file's properties can remove the file from the set the filter would select. For example,
This behaviour seems both a feature and a bug. It allows a user to trivially undo accidental or erroneous edits. But it's also confusing in that the status bar continues to indicate the image matches the filter and when the user might be thinking enough about the filter behaviour to be expecting Timelapse to figure out the edit and move on to another image in response.
As an initial response I'm tempted to say the core behaviour here is by design and that if the user wants the currently viewed file to drop out of the selected set they need to reapply the filter. In that context some type of indicator might be appropriate, perhaps along the lines of "Image Number: foo of bar files matching filter when it was applied, file no longer matches filter" in the status bar.