[digikam] [Bug 375703] Moving grouped images into another album removes groups

[Mario Frank]

https://bugs.kde.org/show_bug.cgi?id=375703

--- Comment #15 from Mario Frank <mario.frank at uni-potsdam.de> ---
Okay,

I thought about the problems for some time.

I try to resume the expected behaviour:
1) Moving a group of items should preserve the grouping relation on the moved
items (Bug description by Jens) - This works in garbage collection branch
without workaround.
2) Moving an item that is grouped should preserve its grouping relation - This
also works in garbage collection branch without the workaround.
3) Copying a group within digiKam should also copy the grouping relation for
the newly generated items - This is not done.
4) Copying an item of a group within digiKam - This is not clear. Should the
new item belong to the group?
5) Importing images into digiKam that are identical to grouped items - Should
the imported images be grouped automatically?
6) What do you mean with
> Also externally copied grouped images with the file manager makes problems.
   I assume that you mean that some user copies grouped images that are
imported in digiKam with a file manager.
   But this then also makes problems when grouped images are moved with a file
manager.

I give here my opinion to 3-6 and I am open for discussion. I will try to make
my arguments as precise and founded as possible.

I would state the following for 3 and 4: Copy means copy and we should give the
user what can be expected by the terms we use. Since we copy all image
properties, the grouping relation should be copied in principle, too. But the
problem here is: What does the user expect? Should the copies have a grouping
relation with the source group leader or should the copied group be a new group
with the copy of the old group leader being the new group leader? I cannot
answer this question. Only the users can. So the default would be for me to not
set group relations for copied items and (potentially) give the user an option
to decide about the relations to established.

I would state the following for 5: If a user imports some images into digiKam,
we cannot know whether he wants to establish a group or add the images to a
group. Also, the grouping relation is existent in digiKam but not in file
managers - at least not that I know. Thus, the imported images should not be
grouped automatically. We could ask the user or give an option as import. But I
would not take the decision from the user.

I would state the following for 6: I like good user experience. But this case
is a clear misuse for me. One cannot expect some complex software to work
properly when tampering with the resources managed by the software. If you just
copy an image tag relation in our database, you will also have unexpected
behaviour if our constraints do prohibit that. And this also holds for other
software projects. If you copy some bundles from a OSGI container, he will
probably yell at you to stop tampering with his internal resources. Probably
with a crash. But we cannot prohibit changes in the file system level. We
cannot even detect them if digiKam is not started. This is - at least for me -
something that should be stated in the documentation.

To conclude: 
cases 3 to 5 are no bugs for me. I think they are usability issues and we could
try to give the user the control about what is done with the group
1) establish a new group with copy of group leader being new group leader
2) link to existent group leader
3) do nothing (default)
case 6 is misuse and should be documented.

Opinions?

All the best
Mario

-- 
You are receiving this mail because:
You are the assignee for the bug.