Age | Commit message (Collapse) | Author | Files | Lines |
|
|
|
It is not possible to use the `list` pointer after it has been deleted,
so the "cleanup" this commit made lead to using freed memory if any
item actually got clean up.
This "cleanup" also don't seem meaningful to me, as all it does
otherwise is trade an assignation for a redundant test -- either of
which the compiler might happily optimize out.
This reverts commit 47426c90d10e9f738ecf89f35db94ca8deff55e0.
|
|
The timestamp is compared with g_file_info_get_attribute_uint64
in mate_desktop_item_get_file_status (const MateDesktopItem *item)
|
|
The timestamp is retrieved with g_file_info_get_attribute_uint64
in get_mtime (const char *filename)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
find . \( -name '*.h' -o -name '*.c' \) -exec sed -i 's/[[:space:]]*$//' {} \;
find . \( -name '*.h' -o -name '*.c' \) -exec sed -i 's/\t*$//' {} \;
|
|
|
|
|
|
fixes https://github.com/mate-desktop/mate-desktop/issues/431
|
|
|
|
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=785198
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/8663695
|
|
https://bugzilla.gnome.org/show_bug.cgi?id=785198
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/2887d75
|
|
Instead of a shell-quoted string, to make it easier to add new elements
to this command-line.
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/483ea2e
|
|
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/a5188e5
|
|
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/1c9cabf
|
|
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/fdb6fd1
|
|
|
|
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/b025840
|
|
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/a63a558
|
|
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/a0702a2
|
|
- replace remaining tabs with spaces
- fixes some indents
|
|
As scaling down by huge factors is now fixed in gdk-pixbuf. Require the
newer gdk-pixbuf as well, to avoid running into a pre-fix version.
https://bugzilla.gnome.org/show_bug.cgi?id=775991
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/cb64228
|
|
If a preview exists for a particular file, in particular a preview icon
for videos and images on external devices, prefer those to running a
script.
https://bugzilla.gnome.org/show_bug.cgi?id=738503
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/370b985
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/e629e46
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/a15db1d
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/fc19c94
|
|
Instead of special-casing gdk-pixbuf-supported image formats, use an
external thumbnailer. This will give us the ability to:
- cancel running thumbnail operations
- avoid memory leaks, buffer overflows, double-frees, etc. in the
image loaders having an impact on the application
- limit resource usage when thumbnailing
https://bugzilla.gnome.org/show_bug.cgi?id=768064
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/b69fde6
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/dba6d95
|
|
Failure to create a GdkPixbufLoader for a specific MIME type doesn't
necessarily indicate an error. It is possible that the fallback code
would still be able to parse the image data. For example, Canon CR2 RAW
files have the MIME type image/x-canon-cr2. While we don't have a
loader for that specific MIME type, the TIFF loader can still parse the
data.
In case the fallback code failed to parse the image data, we get a
WARNING anyway:
MateDesktop-WARNING **: Error creating thumbnail for ...
Having a log message to indicate that we are using the fallback code is
useful for debugging, but there is no need for the WARNING. It can be
extra noise and needlessly interferes with things like
G_DEBUG=fatal-warnings.
https://bugzilla.gnome.org/show_bug.cgi?id=762504
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/7507254
|
|
We are seeing crashes in Fedora that point at the settings signal
handlers getting run after the thumbnail factory is finalized.
Explicitly disconnecting the handlers in finalize is the right
thing to do, anyway.
While we are at it, replace some of the cleanup code in finalize
with g_clear_pointer and g_clear_object, as suggested by Colin.
https://bugzilla.gnome.org/show_bug.cgi?id=761049
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/f32c389
|
|
functions
Another cleanup in preparation for a new "simple" thumbnail API.
https://bugzilla.gnome.org/show_bug.cgi?id=684026
https://bugzilla.gnome.org/show_bug.cgi?id=784915
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/97f6f77
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/ef4734f
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/911091d
|
|
Put the path calculation code in one spot.
https://bugzilla.gnome.org/show_bug.cgi?id=684026
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/57c18b8
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/ef0f02e
|
|
If a failed thumbnail is created because the pixbuf fail to save
(for instance if user is over quota) we should still try to rename
the temporary file that might have been created.
If not, the thumbnail will not be marked as failed, and thumbnailing
will be reattempted.
https://bugzilla.gnome.org/show_bug.cgi?id=728775
origin commit:
https://gitlab.gnome.org/GNOME/gnome-desktop/commit/54f68ab
|