* Use mtime as fallback timestamp for files without EXIF data
As suggested in #6449, with date-based sorting it can be useful to have
at least *some* sort of time-relevant information for EXIF-less files,
to prevent them from falling back to getting sorted alphabetically all
the time.
This commit simply defaults the file timestamp to the file's mtime as
returned by g_stat. For annoying reasons, it doesn't suffice to merely
forward the timestamp to the FileData structs - we also need to keep
track of it inside FilesData to cover the case of a file with 0 frames
in it.
* Add DateTime to Thumbnail
Putting it here facilitate easier sorting without having to re-construct
the DateTime on every comparison.
To simplify things moving forwards, use the Glib::DateTime struct right
away. This struct also contains timezone information, but we don't
currently care about timezone - so just use the local timezone as the
best approximation. (Nothing currently depends on getting the timezone
right, anyway)
In addition to the above, this commit also changes the logic to allow
generating datetime strings even for files with missing EXIF (which
makes sense as a result of the previous commit allowing the use of mtime
instead).
* Implement file sorting in thumbnail view
For simplicity, I decided to only implement the attributes that I could
verily easily reach from the existing metadata exported by Thumbnail.
Ideally, I would also like to be able to sort by "last modified" but I'm
not sure of the best way to reach this from this place in the code.
It's worth pointing out that, with the current implementation, the list
will not dynamically re-sort itself until you re-select the sorting
method - even if you make changes to the files that would otherwise
affect the sorting (e.g. changing the rank while sorting by rank). One
might even call this a feature, not a bug, since it prevents thumbnails
from moving around while you're trying to re-label them. You can always
re-select "sort by ..." from the context menu to force a re-sort.
Fixes#3317
Co-authored-by: Thanatomanic <6567747+Thanatomanic@users.noreply.github.com>
Valgrind report:
```
14,960 (11,544 direct, 3,416 indirect) bytes in 37 blocks are definitely lost in loss record 20,483 of 20,540
at 0x4837DEF: operator new(unsigned long) (vg_replace_malloc.c:334)
by 0xC06963: rtengine::FramesData::FramesData(Glib::ustring const&, std::unique_ptr<rtengine::RawMetaDataLocation, std::default_delete<rtengine::RawMetaDataLocation> >, bool) (imagedata.cc:1121)
by 0xBD774F: rtengine::DFManager::addFileInfo(Glib::ustring const&, bool) (dfmanager.cc:380)
by 0xBD6E90: rtengine::DFManager::init(Glib::ustring) (dfmanager.cc:303)
by 0xC3EC5D: rtengine::init(rtengine::Settings const*, Glib::ustring, Glib::ustring, bool) [clone ._omp_fn.0] (init.cc:93)
by 0x897CABD: gomp_thread_start (team.c:120)
by 0x89B7A9C: start_thread (in /usr/lib/libpthread-2.28.so)
by 0x8ACCB22: clone (in /usr/lib/libc-2.28.so)
```
- CIECam now gets the shot's setting of the selected frame
- 'UserComment' metadata now correctly handled
- RT prepared to handle XTrans multiframe
- SensorType now set in the cache/data files
- Exif of all frames are displayed in the Editor's Exif tab (without
separator)
- isHDR and isPixelShift is added to the data files stored in cache
- In the Editor panel, the QuickInfo frame display the HDR and
PixelShift information, as well as the number of frame and bit-depth for
HDR image
- the number of frame is provided by dcraw. If not set, it is provided
by the Exif's main IFD count
- the PixelShift information (for Pentax as of now) is provided by
looking at the Exif informations
- the HDR information is provided by the Exif information of the first
frame for Pentax raw files, or by the bitspersample, sampleformat and
compression tags for other files
TODO: add icons to the thumbnails to tag HDR and PixelShift files.
