Age | Commit message (Collapse) | Author | Files | Lines |
|
Apply https://gitlab.gnome.org/GNOME/eog/commit/8032c8a0c6700966afbe77632c03a00ae9a878d0
|
|
Of course those values aren't editable,
but this allowed to copy/paste gps data.
|
|
This should solve conflicts with Exif values that have the same number
but are stored in different IFD blocks (e.g GPS and Interoperability).
https://bugzilla.gnome.org/show_bug.cgi?id=670700
origin commit:
https://gitlab.gnome.org/GNOME/eog/commit/38f49dc
|
|
origin commit:
https://gitlab.gnome.org/GNOME/eog/commit/e046f81
|
|
libexif's formatting of these tags is not nice to read.
Reformatted are latitude and longitude values and their reference points.
https://bugzilla.gnome.org/show_bug.cgi?id=627185
origin commit:
https://gitlab.gnome.org/GNOME/eog/commit/3e4bc1a
|
|
Some GPS tag IDs overlap with IDs from other IFDs.
Specifically check for the GPS IFD and order the entries accordingly.
Also respect the IFD when determining the tag's title.
https://bugzilla.gnome.org/show_bug.cgi?id=627185
origin commit:
https://gitlab.gnome.org/GNOME/eog/commit/8574b4b
Fixes https://github.com/mate-desktop/eom/issues/125
|
|
Otherwise it would only be large enough for roughly one line.
origin commit:
https://gitlab.gnome.org/GNOME/eog/commit/c4a025e
|
|
Show the filtered image only after a short time.
This should improve the UI's responsiveness quite a bit.
https://bugzilla.gnome.org/show_bug.cgi?id=665897
origin commit:
https://gitlab.gnome.org/GNOME/eog/commit/88c4f54
https://gitlab.gnome.org/GNOME/eog/commit/8169e0a
|
|
Replace all instances of CAIRO_FILTER_BILINEAR with CAIRO_FILTER_GOOD.
This produces much less aliasing on downscaled images. CAIRO_FILTER_GOOD
uses the same method as CAIRO_FILTER_BILINEAR for scale factors greater
than 0.75, according to https://bugs.webkit.org/show_bug.cgi?id=147826.
Comparison screenshots made with eog 3.18.1: http://imgur.com/a/NaoOs
CAIRO_FILTER_BEST is better still, but the the visual difference is
almost imperceptible and the performance impact is severe.
https://bugzilla.gnome.org/show_bug.cgi?id=665897
origin commit: https://gitlab.gnome.org/GNOME/eog/commit/fbc1128
fixes https://github.com/mate-desktop/eom/issues/96
|
|
|
|
|
|
|
|
and drop additional checks for min/max GLib versions, it's not needed
|
|
|
|
taken from:
https://git.gnome.org/browse/eog/commit/?id=c1ac983bf3bdbd7d8ab4ab34208f1f399bdacbfc
|
|
avoid deprecated:
gdk_screen_get_monitor_geometry
gdk_screen_get_monitor_at_window
|
|
|
|
|
|
|
|
|
|
|
|
taken from:
https://git.gnome.org/browse/eog/commit/?id=1b22c52
|
|
Do the necessary background drawing in draw callback.
taken from:
https://git.gnome.org/browse/eog/commit/?id=aea6404
|
|
Implementation as suggested in the GTK+ documentation.
taken from:
https://git.gnome.org/browse/eog/commit/?id=a57e788
|
|
Just call the callback function directly as that's why
the signal was manually triggered in the first place.
taken from:
https://git.gnome.org/browse/eog/commit/?id=4c86268
|
|
|
|
taken from:
https://git.gnome.org/browse/eog/commit/?id=3de58ce
|
|
|
|
|
|
taken from:
https://git.gnome.org/browse/eog/commit/?id=a54b3a8
|
|
|
|
This reduce the width of the confirmation dialog
|
|
Change the size request of the encasing ScrolledWindow instead of the
TreeView itself. Otherwise the list would hardly show one row.
https://bugzilla.gnome.org/show_bug.cgi?id=679505
taken from:
https://git.gnome.org/browse/eog/commit/?id=46fb713
|
|
Now, the default paper orientation in print settings is based on image
dimensions.
https://bugzilla.gnome.org/show_bug.cgi?id=531898
taken from:
https://git.gnome.org/browse/eog/commit/?id=5aebb88
|
|
Use cairo's feature to simply attach the source file data to
the printing surface. This reduces the file size of the resulting
PDF file pretty much to the source file size.
https://bugzilla.gnome.org/show_bug.cgi?id=394260
taken from:
https://git.gnome.org/browse/eog/commit/?id=7029dfe
|
|
Do this if no thumbnail exists yet. Avoids displaying too large thumbs
for images that have yet to be thumbnailed, breaking the file open dialog.
https://bugzilla.gnome.org/show_bug.cgi?id=671944
taken from:
https://git.gnome.org/browse/eog/commit/?id=57116d5
|
|
Now that it is supported in EomScrollView there's no reason not
to allow setting an alpha value for the color.
taken from:
https://git.gnome.org/browse/eog/commit/?id=7d2cf4d
|
|
This allows passing the colors more or less directly to cairo
without having to convert it from and to the GdkColor format.
taken from:
https://git.gnome.org/browse/eog/commit/?id=823a4cd
|
|
The RGB values of black and white are known and thus can be set directly
without parsing them with GdkRGBA first.
taken from:
https://git.gnome.org/browse/eog/commit/?id=b06f858
|
|
|
|
|
|
|
|
|
|
https://git.gnome.org/browse/eog/commit/?id=04859efbcde4ae38f9f35818dc586a9088b09cb0
|
|
it stopped working at some point...
fixes https://github.com/mate-desktop/eom/issues/137
ported from:
https://git.gnome.org/browse/eog/commit/?id=7e32c42ef40a2fd19227b397913c063bd33f831b
|
|
|
|
ported from:
https://git.gnome.org/browse/eog/commit/?id=55036c6d55b06e82a480b559d59f5effae26399d
|
|
|
|
|
|
|