Hmmm, the more I think about groups, the more awkward they appear to
me. As I've pointed out the mechanics might allow for nested groups,
and also the idea of directories is showing up in this discussion:
On 2015-Apr-19, Romano Giannetti wrote with possible deletions:
> On a second thought, I think that I agree with Torsten. The group =
> directory idea is quite intuitive.
I think currently Darktable's grouping is a fragile concept when used
to express more than the most primitive rlationship between images. I
fear that operating system operations on the underlying filesystem
(`rm` the group leader) are likely to break such conventions.
Also, the group information is rather attached to the image like any
other property, it's not the case that the image would be inside a
container. Presenting this as a directory to the user would make the
UI divert significantly from what's actually happening.
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.
For the long run: Allow the user to see the FS hierarchy. Yes, I
know, Darktable's FAQ is quite explicit about to not implement a file
manager. But right now a bunch of filesystem operations (remove,
delete, copy, duplicate) are replicated in DT anyways, with slightly
different semantics than what a filemanager would do. So the user
actually has to master both concepts, *and* understand how they
ineract.
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?
Kind regards
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
