Add capture month to collection and collection filters#20697
Add capture month to collection and collection filters#20697da-phil wants to merge 3 commits intodarktable-org:masterfrom
Conversation
This commit adds a new field to the collection structure to capture the month of photo capture. It also updates the collection filters to allow filtering based on the capture month. This will enable users to better organize and analyze their photos based on the time of capture.
|
You need to add DT_COLLECTION_MONTH_PROP to the Lua enums at the end of src/collect.c |
ralfbrown
added
feature: enhancement
src/common/collection.h
Outdated
| DT_COLLECTION_PROP_ISO, | ||
|
|
||
| DT_COLLECTION_PROP_DAY, | ||
| DT_COLLECTION_PROP_MONTH, |
There was a problem hiding this comment.
Have you tested against collection presets created before this PR? Adding an enum in the middle of the list is likely to mess up any which have rules with properties below this point.
There was a problem hiding this comment.
@ralfbrown : As I see there is the necessary circuitry in legacy_params() for a proper migration.
There was a problem hiding this comment.
I think it is more elegant to add the new enum entry just at the end instead of adding a migration rule in legacy_params()? Or what is your take on that?
src/libs/collect.c
Outdated
|
|
||
| for(int r = 0; r < old->rules; r++) | ||
| { | ||
| new->rule[r].item = table[old->rule[r].item]; |
There was a problem hiding this comment.
I don't think this works, old->rule[r].item is just an int and it will map to the same int using table[old->rule[r].item].
There was a problem hiding this comment.
I would think that the migration here is to add 1 to every items AFTER old DT_COLLECTION_PROP_DAY.
There was a problem hiding this comment.
Or just getting rid of the migration rule by adding the new enum value at the end of the enum declaration?
There was a problem hiding this comment.
Maybe could work too, to be tested. The order in the GUI for selecting the filters are not dependent on the position of the enum IIRC. (this was not always the case, to be checked).
| typedef struct _widgets_month_t | ||
| { | ||
| dt_lib_filtering_rule_t *rule; | ||
| GtkWidget *toggles[12]; |
There was a problem hiding this comment.
I might want to try to keep gtk widgets out of this
|
Thanks for the initial review @wpferguson @ralfbrown @TurboGit. Will address them once I'm getting back to the code. Until then I have the following general question to you: |
I think it is fine to have the months name here. Those could be reused anyway in other contexts. |
da-phil
force-pushed
the
add_capture_month_to_collection_and_collection_filters
branch
from
9e75167 to
ed1c869
Compare
4 participants
This PR adds the photo capture month to the "collections" and "collection filters" widgets.
This will enable users to better filter and analyze their photos based on the time of capture.
My typical use-case for this is finding suitable calendar pictures, given that I want them being taken in the same month as they should appear in the calendar.
A typical example for me is finding winter pictures, where I just want to filter for photos taken in December, January and February:
I have the following question to reviewers and other users:
Do you think we need the names of the months in there, or would numbers 00-12 be sufficient, given the necessity to translate those month names and their 3 character abbreviations?
Disclaimer: this code was co-created with Claude.