Hi, On 2015-Apr-19, Torsten Bronger wrote with possible deletions: > Stefan Klinger writes: > > Thus I'd like to propose the following for the short term: > > > > * Leave the group mechanics (with image_id and group_id) as it is > > for now. > > > > * Selecting a collapsed group selects all group members. > > That's the change Tobias has suggested. > > But which image operation should affect which images? In paticular, > does removing, deleting, colour-labeling, and tagging affect all > group members when collapsed?
Yes, as far as possible, I'd say so: Selecting a collapsed group is equivalent to selecting each individual member in expanded view. It's the only way the user does not have to remember which operations “hit through”, and which don't. For a more fine-grained selection, one would have to expand the group. It has already be proposed to viusally emphasize a collapsed group somehow. And it probably makes sense to ask the user before doing something dangerous (e.g., geeqie shows a list of all images before deleting them. Same for emacs on files in dired-mode). > > For the long run: Allow the user to see the FS hierarchy. > > But RAW+JPEG is not expressed using subdirs on the FS level. Yes, you are right. I just got the impression that some users might think of groups as directories. What I've tried to say before was that if hierarchies are desired, they should not be implemented via the groups mechanism, but rather be implemented on the FS level, because there we have a well-implemented, time-tested and matured system, that is also accessible to other programs without further ado. I was not trying to suggest to model the raw/jpeg relationship via directories. That would create quite a deep forest, making access through external tools a little awkward. Oh, and the rest was just a very long-term suggestion only. My two cents in what I think might be possible. Not more... > > Maybe one can allow tags to carry (primitive) information (maybe it's > > possible already, but I did not see this), or, allow the user to add > > image properties just as tags can be added. Via this, grouping could > > be implemented as a special case of tagging: > > > > * On Importing, tag `grouping|shot` should be set to the same value > > for all images recognised as coming from the same shot (maybe, > > just as now, the image_id of the raw). That's what the default > > grouping is doing right now for raw and jpeg. > > > > * It would also be possible to have different groups in parallel. > > The tag `grouping|burst` might be set to a common value for all > > images shot within a very short timespan. > > > > Then the “collapse groups” switch would turn into “collapse by > > tag”. Collapsing by the tag `grouping|shot` would do what happens > > now > > > > Is that a feasible perspective? > > It is rather complex and convoluted. What is convoluted? Is it making tags carry values? Apart from that, that's jus what's going on right now with grouping. Sunny greetings Stefan -- http://stefan-klinger.de o/X /\/ \ ------------------------------------------------------------------------------ BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT Develop your own process in accordance with the BPMN 2 standard Learn Process modeling best practices with Bonita BPM through live exercises http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_ source=Sourceforge_BPM_Camp_5_6_15&utm_medium=email&utm_campaign=VA_SF _______________________________________________ Darktable-users mailing list Darktable-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/darktable-users
