Hi Mke & Vlad,
reading your comments I am getting a bit worried that this "auto-cascade" feature request is getting a bit to complex. If we are asking for too much, it likely will never become reality...
For now I would vote to keep it simple. Color labels are already and always were assigned to all images. I would already be very happy if "auto-cascade" simply means this applies to all other data too.
Here my concerns:
Yes, you're right - labels should be included too. I'll update the mock-up at some point. I'm thinking that there may be other things missing too - like the contents of the Details panel...
Although it would be useful to have that option it would make the way large catalogs very complex. Imagine you have a deeply nested hierarchy. Would you have to select each label in that hierarchy and decide if it should be auto-cascaded? Or: would you select the parent not to be auto-cascaded and that setting applies to all children?
Also: if you have auto-cascading enabled in general preferences, would you then have to disable the labels that should not cascade?
I am not saying the feature is not useful, but it is asking a bit much. It adds a lot of complexity to what otherwise would be a relatively simple feature request. Given Hert's reluctance to overwhelm PSU with too much complexity it is likely auto-cascading will never be implemented if we ask for too many "bells & whistles"...
I think it would perhaps be wise to split this off into a separate feature request, asking for it once the general auto-cascading has been implemented.
For the same reason I would actually per default not include face or area tagging to be auto-cascades. This request again adds an significant challenge: in cropped or otherwise edited versions areas do not necessarily overlap with the main version (I read the thread about that topic and know there may be ways to circumvent this problem, but again: I am not against it, I am only cautious. If we want auto-cascading being implemented fairly soon, we should keep the request fairly simple).
I was thinking that everything should be cascaded from the main version, for simplicity.
I agree. For simplicity this makes the most sense.
[However, one could also a different implementation: combine auto-cascade it with auto-sync. In that case: you assign a label, xmp, GPS data, color labes etc. etc. and the info is automatically synced to all versions not only the one the data has been assigned too. This essentially would not be a true auto-cascade, but an enhancement how syncing works.
I am not sure though if this would work also with using a sync-queue, i.e., if auto-sync is switched off. In that case assigning labels to different versions and then sync that information could perhaps cause a conflict (the same label assigned twice to different versions and thus being removed, when it is assigned the second time). But then, these conflicts can possibly avoided if syncing keeps track of the sequence that labels/metadata are assigned.]
...would the cascading checkmarks be combined via OR via AND?
Thinking about this again I probably need to revise my last, very enthusiastic comments about the screenshot mockup. Coming from IDI, where assigning multiple images to one placeholder is not possible I had not thought properly about the complexity that deciding this option might cause. It would not be a problem with a brand new catalog, but it could wreck havoc if enabled in a catalog where information that is already present in different images is quite different...
So this is again turning into a more complex feature request if we are asking for auto-cascade with the option to select for which particular the placeholders this feature should apply.
For the sake of simplicity things would be much easier if there are two options only:
(1) auto-cascade "off" (default, the way how PSU currently works)
(2) auto-cascade "on" (all data except area/face tags cascaded to ALL versions)
Perhaps permitting a choice to selectively enable auto-cascade individually for the different categories of data still make sense. So, perhaps a user would want that his ratings are not automatically assigned to all versions, but prefer that all keywords/labels and XMP metadata are. That user would have the choice to not enable auto-cascade for ratings, but enable it for keywords/labels and XMP...
Again: all these ideas are relevant and it would be fantastic if they were implemented, but my personal order of priority would be:
(1) auto-cascade everything
(2) add an option to select which data is auto-cascaded
(3) add an option to select which to version data is auto-cascaded
(4) add an option to select to configure labels individually for auto-cascading
One and two could probably added fairly soon, three and four add a lot of complexity - with the chance that users will be overwhelmed, this Hert might want to avoid.
Currently, Catalog -> By Category displays only the main version...
Yes the ramifications of this are indeed a "can of worms". Again, implementing "auto-cascade" step by step might have the advantage that the feature could be introduced, tested and improved; issues that arise thus more easily be resolved.
Perhaps we should, at this stage not ask for too much?