[Digikam-devel] [Bug 91562] Change order of pictures in the virtual album manually

[b3nmore at googlemail.com]

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

b3nmore at googlemail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |b3nmore at googlemail.com

--- Comment #31 from b3nmore at googlemail.com ---
I would really like to see this feature implemented in the near future. So I'm
throwing in some comments to keep at least the discussion alive.

In my opinion, a manual sort order makes only sense, if it's linked to a
reference set of pictures. This may be defined by an album or by tags (or by a
time interval, but I'm not sure about this yet).
Why? Because
0) it meets the most frequent usage case: people choose a certain set of
pictures and then start arranging them
1) it allows different subsets with common pictures to have their own order
without influencing each other
2) all other views and search results can be mapped into an album or tag and
than arranged
3) it probably makes implementing it much easier

Another question is what happens when items are added to the reference set? We
need a way to incorporate them into our manual order. Probably the most natural
way would be to follow the original order of the set (date, filename,size ...).
That means use the pictures which weren't moved as a frame and place the new
ones accordingly.

This gives us three attributes for our order identifier: reference set,
original sort order and the picture position. A possible identifier could be
constructed as follows (although their may be more SQLish ways to organize it):
As soon as a picture is moved manually it gets an order identifier like
<ref set type><ref set id>_(orig sort key(+1)-orig sort key (-1))/2

I guess this needs some explanations. For example, we start with an album
(album id=17) which is sorted by date. We move a picture between two pictures
with dates "15.09.11 15:00" and "15.09.11 16:00" then the identifier would be
a17_"15.09.11 15:30". Manually sorting goes then by date or the pseudo date of
the identifier if the prefix matches the current view.

This approach has following advantages: Moving an images requires only to adapt
the identifier of this particular image. When we add pictures to our reference
set they get automatically incorporated in a natural order like discussed
above. We can store the order identifier in the meta data of the image and
restore the manual sort order by parsing the meta data (in the case we lose the
db or we just copy a picture folder).

Some further thoughts: What happens when the reference set doesn't exist
anymore (e.g. a deleted tag)? The order identifier to this reference set would
become obsolete and should be deleted.

Hopefully it contains some useful thoughts, feel free to take it apart.

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