* Use target_include_directories to specify include paths
* Specify project root (parent of rtgui and rtengine) as include path
* Replace relative includes with normal includes
* 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>
Note: This commit has only been tested on MacOS
Changes:
- Icons now use the native hidpi support from Gtk (through Icon Theme)
- Icons are now directly generated from scalable file (i.e. SVG file)
- Widget sizes are scaled based on DPI and scale factor
- Font size is scaled based on DPI and scale factor
Replaces the following deprecated Gtk classes throughout the codebase by their non-deprecated counterparts. Style, HBox, VBox, HPaned, VPaned, HScrollbar, VScrollbar, VSeparator, HSeparator, Stock, Table, VScale and HScale.
The Quartz backend emits adjusted GdkEventScroll delta values.
This is why the RT thumb browser scrolls several hundred times too fast
if the deltas are additionally multiplied by thumb size under macOS.
See use of scroll_unit and GDK_WINDOWING_QUARTZ for Gtk scrollbars:
https://gitlab.gnome.org/GNOME/gtk/blob/gtk-3-24/gtk/gtkrange.c#L3080
Devices such as trackpads will emit smooth scrolling (GDK_SMOOTH_SCROLL) events with
deltas smaller than +/-1.0 at high frequency.
Quantizing these to +/-1.0 leads to significant amplification of scroll speed to the point
of unusability
Scroll by delta instead of +/-1.0 in these cases, permitting smooth scrolling through thumbnails
Some mice emit GDK_SMOOTH_SCROLL with deltas of +/-1.0 per detent. This patch will not change behavior
with such devices. However, if any mice emit deltas of smaller magnitude, the per-detent behavior will
change.
When hovering over a thumb which has characters in its filename which
are used in markup, such as '&', the tooltip was missing, due to the
ampersand being parsed as markup. Now the filename is treated as plain
text.
When scrolling with the mouse scroll-wheel while hovering over a
thumbnail in the Filmstrip, now it scrolls by an amount equal to
the first thumb's width. Previously it used the height.
Spotted by Ingo.
This works really well in the browser. Horizontal scrolling has the same speed, which works reasonably well too (unless you have images with abnormal aspect ratio's).
