| Summary: | Virtual folders / arbitrary sets in Digikam | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Niels <niels.misc> |
| Component: | Tags-Engine | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | wishlist | CC: | caulier.gilles, drch, shaav, xchardon |
| Priority: | NOR | ||
| Version: | 3.1.0 | ||
| Target Milestone: | --- | ||
| Platform: | Other | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Niels
2013-06-03 15:42:59 UTC
Use Pick Label or Color Label to define important shoot, as under Aperture or LR Gilles Caulier What's the difference to a tag? 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. 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. 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. 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. 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 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... (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. (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 (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 *** This bug has been marked as a duplicate of bug 120945 *** |