Group by filename
Locked
 
|
Hi all,
we would like to get some feedback on a patch we have been working on for quite some time now. It introduces a configurable "group by filename" action to the album view which lets you automatically combine files with matching name parts into a group. A filename based grouping feature is key for our workflow, and we could imagine lots of use cases for other people's workflows. In fact, we found the feature request we attached the patch to after implementing a first version for our own purpose, so it seems there is at least some demand for it. Find a short screencast of the current functionality here: https://plus.google.com/107260423308980038020/posts/GgpPK27Y3fq As you can see, there are three configuration options:
Technically, this feature is implemented as a patch against digiKam core. While we would have loved to implement it as a plugin, we didn't find a way to hook a plugin into the album view and the context menu. The flexible matching part is based on the popular regular expression syntax. Gilles, we know you are not a fan of regular expressions, but we couldn't think of another way to achieve a flexible matcher like this without overcomplicating things. We just hope that if you would totally hate regular expressions you would have closed the feature request #318357 before someone accepted the challenge to work on it. Of course, the offer I made in my comment to the G+ post above still holds. While we consider the patch ready for prime time now, we would like to hear:
Best regards, Ulf _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
On 26.01.2015 23:04, Ulf Rompe wrote:
> Hi all, > > we would like to get some feedback on a patch we have been working on > for quite some time now. It introduces a configurable "group by > filename" action to the album view which lets you automatically combine > files with matching name parts into a group. > A filename based grouping feature is key for our workflow, and we could > imagine lots of use cases for other people's workflows. In fact, we > found the feature request we attached the patch to after implementing a > first version for our own purpose, so it seems there is at least some > demand for it. > > Find a short screencast of the current functionality here: > https://plus.google.com/107260423308980038020/posts/GgpPK27Y3fq > > As you can see, there are three configuration options: > > 1. The default setting is set up to combine RAW and JPEG files. If you > have 123.nef and 123.jpg in your current selection, they will be > grouped, leaving 123.jpg on top. > 2. The second option configures grouping of files featuring common > appendices added by well known image editors. If you have, for > example, some of 123.jpg, 123_v1.jpg, 123-Edit.jpg, 123_shotwell.jpg > and "123 (edited).jpg" in your current selection, they will be grouped. > 3. The third option is for advanced users, giving you the option to > manually tweak the expression used for the matching. The editable > pulldown is already populated with the expressions used to realize > the two options described above as well as an example that > implements our very own grouping logic. Whatever you try here, the > previous state will always be remembered and accessible through the > pulldown. Just fool around and see what happens. > > > Technically, this feature is implemented as a patch against digiKam > core. While we would have loved to implement it as a plugin, we didn't > find a way to hook a plugin into the album view and the context menu. > The flexible matching part is based on the popular regular expression > syntax. Gilles, we know you are not a fan of regular expressions, but we > couldn't think of another way to achieve a flexible matcher like this > without overcomplicating things. We just hope that if you would totally > hate regular expressions you would have closed the feature request > #318357 before someone accepted the challenge to work on it. Of course, > the offer I made in my comment to the G+ post above still holds. > > While we consider the patch ready for prime time now, we would like to hear: > > 1. Is the UI intuitive enough, especially from a KDE point of view? > 2. Could you think of other predefined grouping options than the two > introduced above? Of course we would like to serve most users with > easy defaults, leaving the manual expression editing to power users. > 3. Would it be realistic to get the feature into digiKam in the near > future? > > > Best regards, Ulf > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > Hey Ulf! Thanks for working on that feature. It is one of the things I really miss in digikam. Are you going to implement group options like "Delete group" or "Add Tag to group" too, because for me grouping is not really useful if I can not apply actions to the group. Greetings, Flo _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Ulf Rompe
I have most of my pictures as .jog and .cr2 I have generally only
tagged the .jpg so it would be great if I could copy all metadata
from .jpg to the corresponding .cr2 Would this allow me to do that?
On 26/01/15 22:04, Ulf Rompe wrote:
Hi all, _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
This is an absolutely brilliant feature! It looks pretty intuitive and
straightforward in use. Great job, guys! Can't wait to see it rolled in to digiKam. Best, Dmitri On Tue, Jan 27, 2015 at 11:00 AM, Mick Sulley <[hidden email]> wrote: > I have most of my pictures as .jog and .cr2 I have generally only tagged > the .jpg so it would be great if I could copy all metadata from .jpg to the > corresponding .cr2 Would this allow me to do that? > > > > On 26/01/15 22:04, Ulf Rompe wrote: > > Hi all, > > we would like to get some feedback on a patch we have been working on for > quite some time now. It introduces a configurable "group by filename" action > to the album view which lets you automatically combine files with matching > name parts into a group. > A filename based grouping feature is key for our workflow, and we could > imagine lots of use cases for other people's workflows. In fact, we found > the feature request we attached the patch to after implementing a first > version for our own purpose, so it seems there is at least some demand for > it. > > Find a short screencast of the current functionality here: > https://plus.google.com/107260423308980038020/posts/GgpPK27Y3fq > > As you can see, there are three configuration options: > > The default setting is set up to combine RAW and JPEG files. If you have > 123.nef and 123.jpg in your current selection, they will be grouped, leaving > 123.jpg on top. > The second option configures grouping of files featuring common appendices > added by well known image editors. If you have, for example, some of > 123.jpg, 123_v1.jpg, 123-Edit.jpg, 123_shotwell.jpg and "123 (edited).jpg" > in your current selection, they will be grouped. > The third option is for advanced users, giving you the option to manually > tweak the expression used for the matching. The editable pulldown is already > populated with the expressions used to realize the two options described > above as well as an example that implements our very own grouping logic. > Whatever you try here, the previous state will always be remembered and > accessible through the pulldown. Just fool around and see what happens. > > > Technically, this feature is implemented as a patch against digiKam core. > While we would have loved to implement it as a plugin, we didn't find a way > to hook a plugin into the album view and the context menu. The flexible > matching part is based on the popular regular expression syntax. Gilles, we > know you are not a fan of regular expressions, but we couldn't think of > another way to achieve a flexible matcher like this without overcomplicating > things. We just hope that if you would totally hate regular expressions you > would have closed the feature request #318357 before someone accepted the > challenge to work on it. Of course, the offer I made in my comment to the G+ > post above still holds. > > While we consider the patch ready for prime time now, we would like to hear: > > Is the UI intuitive enough, especially from a KDE point of view? > Could you think of other predefined grouping options than the two introduced > above? Of course we would like to serve most users with easy defaults, > leaving the manual expression editing to power users. > Would it be realistic to get the feature into digiKam in the near future? > > > Best regards, Ulf > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Mick Sulley
No the patch only allows to group the images. For tagging my current
workaround is to tag all the .jpg files of the group and then copy the tags to the Raw file (nef in my case) using exivtool: exiftool -TagsFromFile ./%f.JPG -all:all -r -overwrite_original -ext NEF ./ (if the raw and jpg files are in the same folder, if not change the path at the end of the command to something like ../nef/) Back in digikam you have to select the updated images and select "Image->Reread Metadata from Image" to update the metadata. But there is one disadvantage in this method: the Raw images do not have the right orientation anymore. Maybe some exivtool gurus out here know what to do to avoid that. Greetings, Flo On 27.01.2015 11:00, Mick Sulley wrote: > I have most of my pictures as .jog and .cr2 I have generally only > tagged the .jpg so it would be great if I could copy all metadata from > .jpg to the corresponding .cr2 Would this allow me to do that? > > > On 26/01/15 22:04, Ulf Rompe wrote: >> Hi all, >> >> we would like to get some feedback on a patch we have been working on >> for quite some time now. It introduces a configurable "group by >> filename" action to the album view which lets you automatically >> combine files with matching name parts into a group. >> A filename based grouping feature is key for our workflow, and we >> could imagine lots of use cases for other people's workflows. In fact, >> we found the feature request we attached the patch to after >> implementing a first version for our own purpose, so it seems there is >> at least some demand for it. >> >> Find a short screencast of the current functionality here: >> https://plus.google.com/107260423308980038020/posts/GgpPK27Y3fq >> >> As you can see, there are three configuration options: >> >> 1. The default setting is set up to combine RAW and JPEG files. If >> you have 123.nef and 123.jpg in your current selection, they will >> be grouped, leaving 123.jpg on top. >> 2. The second option configures grouping of files featuring common >> appendices added by well known image editors. If you have, for >> example, some of 123.jpg, 123_v1.jpg, 123-Edit.jpg, >> 123_shotwell.jpg and "123 (edited).jpg" in your current selection, >> they will be grouped. >> 3. The third option is for advanced users, giving you the option to >> manually tweak the expression used for the matching. The editable >> pulldown is already populated with the expressions used to realize >> the two options described above as well as an example that >> implements our very own grouping logic. Whatever you try here, the >> previous state will always be remembered and accessible through >> the pulldown. Just fool around and see what happens. >> >> >> Technically, this feature is implemented as a patch against digiKam >> core. While we would have loved to implement it as a plugin, we didn't >> find a way to hook a plugin into the album view and the context menu. >> The flexible matching part is based on the popular regular expression >> syntax. Gilles, we know you are not a fan of regular expressions, but >> we couldn't think of another way to achieve a flexible matcher like >> this without overcomplicating things. We just hope that if you would >> totally hate regular expressions you would have closed the feature >> request #318357 before someone accepted the challenge to work on it. >> Of course, the offer I made in my comment to the G+ post above still >> holds. >> >> While we consider the patch ready for prime time now, we would like to >> hear: >> >> 1. Is the UI intuitive enough, especially from a KDE point of view? >> 2. Could you think of other predefined grouping options than the two >> introduced above? Of course we would like to serve most users with >> easy defaults, leaving the manual expression editing to power users. >> 3. Would it be realistic to get the feature into digiKam in the near >> future? >> >> >> Best regards, Ulf >> >> >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users > > > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Dmitri Popov-2
As explained into G+ post, the patch is attached to this entry in bugzilla :
https://bugs.kde.org/show_bug.cgi?id=318357 As i already said, I'm not favorable to include Regular Expression rules in digiKam GUI. It's not users friendly. For the rest, no problem... Note : - KDE4 is frozen for new features. Only bugfixes will be introduced in code. This want mean that patch must be adapted to "frameworks" branch from git repository, where new features can be introduced. Details about digiKam framework branch can be found here : https://techbase.kde.org/Projects/Digikam/CodingSprint2014 - Patch must be ported to pure Qt5. You must drop KDE API use. The plan is to limit KDE dependencies in digiKam later, in goal to make it more portable in the future. Gilles Caulier 2015-01-27 11:18 GMT+01:00 Dmitri Popov <[hidden email]>: > This is an absolutely brilliant feature! It looks pretty intuitive and > straightforward in use. Great job, guys! Can't wait to see it rolled > in to digiKam. > > Best, > Dmitri > > On Tue, Jan 27, 2015 at 11:00 AM, Mick Sulley <[hidden email]> wrote: >> I have most of my pictures as .jog and .cr2 I have generally only tagged >> the .jpg so it would be great if I could copy all metadata from .jpg to the >> corresponding .cr2 Would this allow me to do that? >> >> >> >> On 26/01/15 22:04, Ulf Rompe wrote: >> >> Hi all, >> >> we would like to get some feedback on a patch we have been working on for >> quite some time now. It introduces a configurable "group by filename" action >> to the album view which lets you automatically combine files with matching >> name parts into a group. >> A filename based grouping feature is key for our workflow, and we could >> imagine lots of use cases for other people's workflows. In fact, we found >> the feature request we attached the patch to after implementing a first >> version for our own purpose, so it seems there is at least some demand for >> it. >> >> Find a short screencast of the current functionality here: >> https://plus.google.com/107260423308980038020/posts/GgpPK27Y3fq >> >> As you can see, there are three configuration options: >> >> The default setting is set up to combine RAW and JPEG files. If you have >> 123.nef and 123.jpg in your current selection, they will be grouped, leaving >> 123.jpg on top. >> The second option configures grouping of files featuring common appendices >> added by well known image editors. If you have, for example, some of >> 123.jpg, 123_v1.jpg, 123-Edit.jpg, 123_shotwell.jpg and "123 (edited).jpg" >> in your current selection, they will be grouped. >> The third option is for advanced users, giving you the option to manually >> tweak the expression used for the matching. The editable pulldown is already >> populated with the expressions used to realize the two options described >> above as well as an example that implements our very own grouping logic. >> Whatever you try here, the previous state will always be remembered and >> accessible through the pulldown. Just fool around and see what happens. >> >> >> Technically, this feature is implemented as a patch against digiKam core. >> While we would have loved to implement it as a plugin, we didn't find a way >> to hook a plugin into the album view and the context menu. The flexible >> matching part is based on the popular regular expression syntax. Gilles, we >> know you are not a fan of regular expressions, but we couldn't think of >> another way to achieve a flexible matcher like this without overcomplicating >> things. We just hope that if you would totally hate regular expressions you >> would have closed the feature request #318357 before someone accepted the >> challenge to work on it. Of course, the offer I made in my comment to the G+ >> post above still holds. >> >> While we consider the patch ready for prime time now, we would like to hear: >> >> Is the UI intuitive enough, especially from a KDE point of view? >> Could you think of other predefined grouping options than the two introduced >> above? Of course we would like to serve most users with easy defaults, >> leaving the manual expression editing to power users. >> Would it be realistic to get the feature into digiKam in the near future? >> >> >> Best regards, Ulf >> >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users >> >> >> >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users >> > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Hi Gilles,
please excuse my delayed answer! I have to task-switch a lot, so anything related to digiKam mostly happens on monday. Am Dienstag, den 27.01.2015, 11:56 +0100 schrieb Gilles Caulier: > As explained into G+ post, the patch is attached to this entry in bugzilla : > > https://bugs.kde.org/show_bug.cgi?id=318357 > > As i already said, I'm not favorable to include Regular Expression > rules in digiKam GUI. It's not users friendly. Of course we are open to ideas how to let advanced users configure a customized matching without too much effort. For example, see our file naming scheme. It includes a revision counter, so that all these files must be grouped: 20150201-n024213-ur100.jpg 20150201-n024213-ur000.jpg 20150201-n024213-ur000.nef We could mix this scheme into the default RAW+JPG expression. That would satisfy our needs without destabilizing anything alse. But wouldn't it be better if any power user could configure his own scheme? Does anybody have an idea how to expose this functionality in another way? > - KDE4 is frozen for new features. Only bugfixes will be introduced in > code. This want mean that patch must be adapted to "frameworks" branch > from git repository, where new features can be introduced. Details about digiKam > framework branch can be found here : > > https://techbase.kde.org/Projects/Digikam/CodingSprint2014 OK, I didn't know that. BTW I think reducing dependencies to plain Qt is a great idea, even if I'm wondering what one would use to replace the brilliant KHistoryComboBox in plain Qt. > - Patch must be ported to pure Qt5. You must drop KDE API use. The > plan is to limit KDE dependencies in digiKam later, in goal to make it > more portable in the future. We will start working on that branch tomorrow. Monday nights are reserved for digiKam and beer. Best regards, Ulf _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
2015-02-01 11:46 GMT+01:00 Ulf Rompe <[hidden email]>:
> Hi Gilles, > > please excuse my delayed answer! I have to task-switch a lot, so > anything related to digiKam mostly happens on monday. > > Am Dienstag, den 27.01.2015, 11:56 +0100 schrieb Gilles Caulier: >> As explained into G+ post, the patch is attached to this entry in bugzilla : >> >> https://bugs.kde.org/show_bug.cgi?id=318357 >> >> As i already said, I'm not favorable to include Regular Expression >> rules in digiKam GUI. It's not users friendly. > > Of course we are open to ideas how to let advanced users configure a > customized matching without too much effort. For example, see our file > naming scheme. It includes a revision counter, so that all these files > must be grouped: > > 20150201-n024213-ur100.jpg > 20150201-n024213-ur000.jpg > 20150201-n024213-ur000.nef > > We could mix this scheme into the default RAW+JPG expression. That would > satisfy our needs without destabilizing anything alse. But wouldn't it > be better if any power user could configure his own scheme? Does anybody > have an idea how to expose this functionality in another way? > >> - KDE4 is frozen for new features. Only bugfixes will be introduced in >> code. This want mean that patch must be adapted to "frameworks" branch >> from git repository, where new features can be introduced. Details about digiKam >> framework branch can be found here : >> >> https://techbase.kde.org/Projects/Digikam/CodingSprint2014 > > OK, I didn't know that. BTW I think reducing dependencies to plain Qt is > a great idea, even if I'm wondering what one would use to replace the > brilliant KHistoryComboBox in plain Qt. KHistoryComboBox ? Not used in digiKam. Did use it in your patch ? completion used in this widget will be replace by a Qt5 API instead KCompletion class. In all case, we have already some Qt widget used in digiKam to perform this kind of feature. Look widgets used in Advanced search tool (hosted in libkdcraw if i remember). This can be easy to add history and completion based on Qt5 directly in digiKam core. I recommend to use in first use a combobox widget from libkdraw. > >> - Patch must be ported to pure Qt5. You must drop KDE API use. The >> plan is to limit KDE dependencies in digiKam later, in goal to make it >> more portable in the future. > > We will start working on that branch tomorrow. Monday nights are > reserved for digiKam and beer. Excelent. Did you have a developer account in KDE git repository ? Gilles _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Ulf Rompe
Ulf Rompe <[hidden email]> wrote:
> Hi Gilles, > > please excuse my delayed answer! I have to task-switch a lot, so > anything related to digiKam mostly happens on monday. > > Am Dienstag, den 27.01.2015, 11:56 +0100 schrieb Gilles Caulier: > > As explained into G+ post, the patch is attached to this entry in bugzilla : > > > > https://bugs.kde.org/show_bug.cgi?id=318357 > > > > As i already said, I'm not favorable to include Regular Expression > > rules in digiKam GUI. It's not users friendly. It depends which users! :-) I find non-RE searches confuse me because they tend to be all different so don't work in a way that I understand until I have learnt yet another syntax. > > Of course we are open to ideas how to let advanced users configure a > customized matching without too much effort. For example, see our file > naming scheme. It includes a revision counter, so that all these files > must be grouped: > > 20150201-n024213-ur100.jpg > 20150201-n024213-ur000.jpg > 20150201-n024213-ur000.nef > level folders for decades (possibly superfluous), then years, months and days, so a file with pictures taken today will be found at:- ~/2010s/2015/02/01/something.jpg Why reinvent the wheel? The operating system developers have been continuously improving file & directory management systems for far longer than digikam has been around. Plus I have already learnt the OS way of doing it, having to learn another is just wasted time. -- Chris Green · _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |