| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
| |
Closes #51.
|
|
|
|
|
|
|
| |
The "X-Tumbler Settings" group is searched in each desktop file with the
same keys as in `tumbler.rc`, where the default configuration is now.
Closes #52.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The request thumbnailer array no longer contains one thumbnailer per
URI, but the list of available thumbnailers for this URI (after applying
the filters of the configuration file), sorted by priority.
For a given URI, we browse the thumbnailer list until we succeed in
generating a thumbnail. An error signal is only issued if the last
thumbnailer has failed. Intermediate errors are only displayed if debug
logging is enabled.
Closes #50.
|
|
|
|
|
|
|
|
| |
FFmpegthumbnailer is known to be really verbose, and we don't have a
priori control on the messages that can be displayed by external
thumbnailers (it can be in particular FFmpegthumbnailer).
Fixes #10, related to #29.
|
|
|
|
| |
Closes #23.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A parameter is added to Tumbler's internal error signals to account for
the error domain, and the error code `TUMBLER_ERROR_OTHER_ERROR_DOMAIN`
is added to indicate that the error originated from a third-party API.
When sending the error signal via D-Bus, cancelling errors are filtered
out, and when the error originates from a third-party API, the error
message is prefixed with the domain and code of that error, in a
possibly parsable format.
Fixes #49.
|
| |
|
|
|
|
|
|
|
| |
This is more convenient for both the developer and the user, especially
when it comes to providing logs in a bug report. As for the loss in
terms of performance, it is minimal, and this is normally not an issue
where these functions are used.
|
|
|
|
| |
I took the exception for the rule: let's hope this time it's good.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When the file system allows it, this prevents Tumbler from believing
that the original file has not been modified since the last time the
thumbnail was created, when in fact modifications have taken place in
the second that the thumbnail was created.
The time of last modification is stored internally in a `gdouble`, and
written to the PNG thumbnail in `%.6f` format. This complies well with
the Freedesktop specification [1], as the stat command returns this
format when invoked as `stat -c%.6Y file`, although it is likely that
the specification was written with the idea that this value be an
integer.
The extraction of the thumbnail information is done via
`g_ascii_strtod()`, so an integer or less precision is not a problem. As
for a code expecting to find an integer, it is likely to simply ignore
the decimal part, as Tumbler used to do by extracting the information
via `atol()`. It is possible, however, that an error will be found if a
more complete extractor is used, such as `strtol()`.
The changes this causes to the exposed Tumbler APIs should also be
inconsequential, as it is a conversion to a higher type. This should
therefore result in implicit conversions, except perhaps for
`tumbler_file_info_get_mtime()`, if its return value is explicitly
stored in a `gint64`.
[1] https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html#CREATION
Fixes #15, see !20 for more details.
|
|
|
|
| |
Completes d6aeb7d65acf6e41738c78b9d137fab3502d1c58.
|
| |
|
|
|
|
| |
G_IMPLEMENT_INTERFACE_DYNAMIC does the job since GLib 2.24.
|
| |
|
|
|
|
|
| |
Any path found in a plugin Excludes will be ignored,
code contributed by Markus Kolb xfce@tower-net.de Bug #16130.
|
| |
|
|
|
|
| |
Move the sparse video files check to ffmpeg and gstreamer plugins.
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
Settings that allow to change the plugin priority, max file
size to act on, white-listed locations or completely disable
them.
|
| |
|
|
|
|
|
| |
Skip schemes that cannot be used to generate thumbs. This
removes a load of combinations in the various tables.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is implemented via two new classes:
TumblerLifecycleManager schedules a 300s timeout when tumblerd is
started. When the timeout handler is executed, it emits a "shutdown"
signal which is caught in main.c and asks the main loop to quit. The
timeout is rescheduled whenever another component calls
tumbler_lifecycle_manager_keep_alive() or when the timeout handler is
called and one of the components is still busy processing requests from
client applications.
TumblerComponent is introduced as a new base class for the D-Bus service
classes. Whenever a D-Bus method call is being processed, service
objects increment the component use count by one and decrement it when
the request is finished. They also call the keep alive method after a
D-Bus method call is received to reschedule the timeout.
A component use count of greather than 0 means that components are busy
and the lifecycle manager needs to reschedule the shutdown timeout.
|
|
|
|
| |
This breaks the API but it is not finalized anyway yet.
|
|
|
|
|
|
|
|
|
|
|
| |
The thumbnail management D-Bus specification was updated accordingly.
This change makes sense due to the following reason: when trashing a
directory we cannot simply call org.freedesktop.thumbnails.Cache1.Delete
as this will only remove the thumbnail of the directory itself, not of
its descendants. But we can use the Cleanup method for this. With
Cleanup taking an array of base URIs instead of just one we can avoid
hundreds of Cleanup calls when trashing a large number of files.
|
| |
|
|
|
|
|
|
|
| |
This commit introduces a simple PDF/PS thumbnailer based on
poppler-glib. It also adds a new error code TUMBLER_ERROR_NO_CONTENT for
documents that are not empty files but do not contain thumbnailable
content.
|
|
|
|
|
|
|
|
|
| |
This is done to avoid warnings when someone forgets to send a MIME type
along with a thumbnail request etc. For empty URIs/MIME types, tumbler
will not find a thumbnailer and the broken elements will be reported
back to the client via the "Error" signal.
The original idea came from Philip Van Hoof <philip@codeminded.be>.
|
| |
|
| |
|
|
|
|
| |
Thanks to Philip for the original commit.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This required some major changes, most of which are documented in the
source code. It still needs to be tested but it should be fine. The
mutex locks in TumblerManager could probably be optimized and some other
parts are not optimal with regards to speed and memory usage yet.
All in all, what's done now is:
- overrides files are parsed into override info structs and kept in
a (hashkey -> override info list) hash table
- each of these override info lists is sorted in the order of the
directories the overrides files are located in (with higher priority
directories coming first)
- the first override info in each list determines which specialized
thumbnailer is set as preferred for the corresponding hash key in
the registry
- thumbnailer service files are parsed into thumbnailer info structs
and kept in a (basename -> thumbnailer info list) hash table
- each of these thumbnailer info lists is sorted in the order of
the directories the thumbnailer service infos come from
- the first thumbnailers in each list are added to the registry
- whenever something changes on the disk, this internal representation
is updated
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Refactor the entire code to use TumblerFileInfo instead of separate
URI/MIME/flavor arrays. We now support flavors which means that
applications can request "normal" and "large" thumbnails and thus have
more control over what is created. This simplifies the code in a lot of
places. We now use a real GObject class called TumblerThumbnailFlavor
instead of a fixed-size enum. Cache backends can return as many flavors
as they want, each consisting of a name, a width and a height. As a
consequence, we can also get rid of the configure flags to
enable/disable normal, large and cropped thumbnails. The default cache
plugin shipped with Tumbler only supports "normal" (128x128px) and
"large" (256x256px).
Optimize the code a little bit. We now load the TunarFileInfo and
ThunarThumbnail only *once* for each URI instead of loading them once in
the scheduler and again in thumbnailer plugins.
This needs careful testing. I might have introduced a few memory leaks
here and there, plus new bugs... you never know.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Tumbler will now only check for the file
$(libdir)/tumbler-1/plugins/cache/tumbler-cache-plugin.so
which is supposed to link to the cache backend that is being used. If
the XDG cache is built, tumbler-cache-plugin.so is set up to link to
this plugin.
The fact that we only have a singleton cache makes things much less
ambiguous.
|