[digikam] [Bug 320663] New: Virtual folders / arbitrary sets in Digikam

[Niels]

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

            Bug ID: 320663
           Summary: Virtual folders / arbitrary sets in Digikam
    Classification: Unclassified
           Product: digikam
           Version: 3.1.0
          Platform: Other
                OS: Linux
            Status: UNCONFIRMED
          Severity: wishlist
          Priority: NOR
         Component: general
          Assignee: [hidden email]
          Reporter: [hidden email]

It would be convenient to be able to make a virtual folder, and throw some
images in it. For example, I have 1.000 images from a convention. I'd like to
make a "Important"-folder with 5 of them. I could use tags, but that's not
necessarily exactly the same thing.

This should be a virtual folder or album, no files should be copied. Like how a
saved search works, I think.

Reproducible: Always

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]
          Component|general                     |Tags

--- Comment #1 from Gilles Caulier <[hidden email]> ---
Use Pick Label or Color Label to define important shoot, as under Aperture or
LR

Gilles Caulier

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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

--- Comment #2 from Marcel Wiesweg <[hidden email]> ---
What's the difference to a tag?

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Shaav-2]

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

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #3 from [hidden email] ---
As described, I don't see any difference between tags / labels HOWEVER my
intuition (and what I would find extremely useful) is that Niels means that the
"virtual album" would have an actual presence on the file system. I.e. it would
be a real folder with only symbolic links in it.  This is what I do manually to
assemble albums for a variety of purposes (including choosing what syncs to my
iPad).

I have seen allusions to being able to this manually by dragging and dropping
to the file manager with ctrl-shift to create links rather than move/copy.
However, (I'm on Linux Mint/Gnome) that doesn't work on my setup either with
Nautilus or Dolphin. Not sure why...

Creating the symlinks manually, isn't that big of a deal when it's 5 of 1000
pictures like Niels suggested, but when it's 250 of a 1000 pictures from your
recent holiday... it's more of a pain if there's no way to filter the selection
in the file system rather than digiKam.

The more exciting possibility is creating "smart" virtual albums that
automatically update (something like dynamic playlists); You create the album,
set the criteria (like an advanced search) like "Pictures rated 5 stars taken
in the last year" or "Pictures in this album rated >=3" or "All pictures tagged
with TagA and TagB" and it is automatically updated as images are
added/removed.

Perhaps a simple implementation would be a "Saved Search" with two additional
options: write  the results as symlinks in a selected folder and run search on
start-up/shut-down.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Marcel Wiesweg]

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

--- Comment #4 from Marcel Wiesweg <[hidden email]> ---
Two remarks: One general problem with symlinks is that they are not available
cross-platform.
Searches should always be automatically updated when anything changes. The
result is not "stored", they are always run freshly.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Niels]

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

--- Comment #5 from Niels <[hidden email]> ---
Making Digikam folders available in KDE and / or the generel file system would
be very nice indeed. But difficult. Making Digikam talk to Nepomuk would get us
some of the way. This is not what I'm talking about.

I can see how tags and virtual folders are almost the same, but not quite. For
example: Tagging 5 files with "show these to X" will change the tags in those
files, which may well be inconvenient.

Also I can see that having both tags and virtual folders can be confusing.
Using symlinks has the same problem.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[drch]

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

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #6 from [hidden email] ---
Virtual albums:
there should be a "virtual albums" concept as in darktable's "collect images"
as follows:
1. there should be a "virtual album" hierarchy in the same manner as the "album
hierarchy". Every virtual album is defined by a (set of) searchs
2. a "virtual sub-album" is defined as an "additional search group".  This
additional search group can be combined with and/or/xor. The logical operation
can be visualized as in darktable. Another form of visualization is provide by
JabRef.
===
One example are " virtual EXIF-albums" - refining different EXIF-items (like
date, size)
===
the main difference to tags is that "virtual search albums" are calculated by
search, while tags are "assigned" - therefore, the complement each other but do
not replace each other (as sometimes proposed). However, from a user interface
point of view, there should be no different between tag hierarchies and search
hierarchies.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[drch]

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

--- Comment #7 from buggy <[hidden email]> ---
Arbitrary sets / virtual albums / views onto a data base

Currently, digiKam is based on the physical file system hierarchy. However, it
would be advantageous to see, conceptually, the images as a "flat set", where
all hierarchies are (virtual) views onto this set. The "file system hierarchy"
would be just one view, while "virtual albums" could define any arbitrary
views. This would also lead to a more consistent handling of images in the user
interface.
Examples:
- View/group images/by albums: could be used for any view, not just for the
file system hierarchy, especially for "search hierarchies"
- currently, the "group images/by Album" is based on the (physical) file system
hierarchy. "Thumbnails" delivers views onto these albums. It would be helpful
to view according to any search results. As an example, searching for images in
the width range 800-900px, it would be helpful to display all images with the
same width (say: 850), in a single "virtual width-album".
As a generalization, one could sort all images "by width", leading to a list of
albums with equal width… this would be equivalent to albums virtually named
"width=815", "width=822" and so on (sorting these albums by name, date, size
etc. is then strait forward

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[xchardon]

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

[hidden email] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #8 from [hidden email] ---
From my perspective it would be great to have a plugin that maps search results
to "virtual folders" in the file system containing symbolic links to the
results.
So for each search you saved, you would have a folder with the same name as
your search, containing symbolics to the images returned by the search (option:
store the links in a subfolders structure identical to the actual albums, so as
for example to filter only the pictures with 5 stars rating but keep the albums
structure).
It doesn't have to be updated in real time, it can be a fully separate plugin
that is run only on demand. That way portability issues can be managed.
There are numerous applications: have a wallpapers folders with my best
pictures, put the pictures of my daughter (and only those) in my dropbox or
whatever, browse on my media center the pictures with 4 stars or more, by
album, create an "albums" folder that will be published on my website with
photofloat, etc...

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Shaav-2]

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

--- Comment #9 from [hidden email] ---
(In reply to comment #8)
> From my perspective it would be great to have a plugin that maps search
> results to "virtual folders" in the file system containing symbolic links to
> the results.

I totally agree --- in fact I've been planning to come back and say exactly
that. An export plugin that exported symbolic links to a folder on the hard
drive would suit my needs perfectly. Perhaps "symbolic" could even be a toggle
and it could copy the pictures as well... for instance one might want to export
a set of photos to be zipped and dropped on a file server.

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[drch]

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

--- Comment #10 from bugs bunny <[hidden email]> ---
(In reply to comment #8)
> So for each search you saved, you would have a folder with the same name as
> your search, containing symbolics to the images returned by the search
> (option: store the links in a subfolders structure identical to the actual
> albums, so as for example to filter only the pictures with 5 stars rating
> but keep the albums structure).
...
> There are numerous applications: have a wallpapers folders with my best
> pictures, put the pictures of my daughter (and only those) in my dropbox or
> whatever, browse on my media center the pictures with 4 stars or more, by
> album, create an "albums" folder that will be published on my website with
> photofloat, etc...

I agree - that's my point. Moreover, I propose to use the "standard tree
navigator panel" because I do not see any semantic difference between the
different views. "Sub-Albums" could be used for refined searches

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[drch]

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

--- Comment #11 from bugs bunny <[hidden email]> ---
(In reply to comment #9)

> drive would suit my needs perfectly. Perhaps "symbolic" could even be a
> toggle and it could copy the pictures as well... for instance one might want
> to export a set of photos to be zipped and dropped on a file server.

I agree - however, maybe one should give up the strong relation between an
album and a "physical folder". Conceptually thinking of images as stored in a
databsed (with un-known internal structure), the export "any" kind of (virtual)
album in a consistent/equal manner

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel

[Gilles Caulier-4]

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

Gilles Caulier <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |DUPLICATE
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #12 from Gilles Caulier <[hidden email]> ---


*** This bug has been marked as a duplicate of bug 120945 ***

--
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Digikam-devel mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-devel