MR glib!4901, backported as glib!4912, will be available in version
2.86.3. Let's keep the workaround so that link layers work without
having to bump the minimum requirement, but add a GLIB_CHECK_VERSION
test. This way, it will be clear that we have to get rid of this part of
the code even if we bump the GLib requirements years ago, when we'll
have completely forgotten about this issue.
As of GLib 2.86.1-1, GFileMonitors created with the
G_FILE_MONITOR_WATCH_HARD_LINKS
flag are not monitored on Windows.
This means that link layers will not
automatically update when the external
source is edited.
We will temporarily use the
G_FILE_MONITOR_NONE flag on Windows
until this is resolved
As discussed with NikcDC, this will be useful, for instance for the SVG
export to know the mime type of the linked file. If not PNG, JPG or SVG,
we may want to output a small warning that some viewers may not be able
to read such files, since the SVG spec makes the support of these 3
formats only as mandatory.
… the whole canvas while keeping aspect ratio of the source image.
The previous dimensions were not entirely "out of the blue" since they
were taken from the file, but very often dimensions from vector images
are kinda bogus (apart from aspect ratio, they don't mean much) anyway.
Now we will just fill the canvas box by default.
When changing the source file of an existing link layer though (through
Link Layer properties), the dimensions will be within the current layer
bounding box.
Also I realized that we need to also store the link width/height in the
XCF because the buffer width/height may not be right (in case a
transform matrix was applied). This commit therefore breaks XCF file
with link layers made in the last 2 days. Since we have not made even a
dev release, it's probably fine to do this and not bump the XCF version.
Instead of keeping a "modified" property in GimpLinkLayer, we just check
if the link is being monitored. It's also a better wording because we
may "discard the link information" without actually modifying the layer
pixels.
Also I now actually shut down the file monitoring process. This can be a
bit expensive so when we don't need it, let's really free the
GFileMonitor.
This commit also fixes scaling of link layer (which got broken along the
way) and improves the undo code.
Note: I'll probably want to modify the XCF flags, but let's do this in
the end, depending on further changes too.
We now re-render a link (by loading its file) immediately upon setting
the new file, i.e. during the calls of gimp_link_new() or
gimp_link_set_file(). As part of this change:
* A GimpLink now stores a GeglBuffer. And this is changed each time a
file change happens (per the GFileMonitor). In particular that also
means that gimp_link_get_buffer() does not reload the image file at
each call for no reasons, and gimp_link_is_broken() does not have a
`recheck` argument either. This is much more efficient.
* These 2 functions also have a GimpProgress and GError now. We use this
among other things to pass on a specific GimpProgress object. In
particular, the image file dialogs now show correct loading
progression again.
* As a general rule, the code is less confusing as we don't have to
wonder whether a GimpLink is ready. We can assume it always is, from
now on.
Note that gimp_link_duplicate() does not trigger a reload of the image
file. Since we assume that the source GimpLink is supposed to be
up-to-date already, we just copy its buffer as-is as an optimization.
This is still mostly a test of workflow. It is based on the idea that
link layers are normal yet enhanced layers: eventually we should be able
to have some improved less-destructive scaling/rotation (even without
NDE transform effects); you can manually drop the link anytime anyway
(hence getting back to the good old fully destructive workflow); any
pixel editing automatically drops the link too.
Now this still raises quite a lot of questions:
* The link can be confusing to people used to the old way and they may
not realize that editing the original file separately would also
update the render in this file (which may not be what they wanted;
maybe they just wanted to grab a snapshot of this file at a given
time).
* You could also want to link XCF files.
* You could also want to link remote files (especially in a controlled
network environment).
* Linked images are currently taken as a whole; we definitely want layer
support to handle multi-layer image formats (so that you could link
only a single layer, or a collection of layers; do we want to be able
to edit visibility of linked layers separately too? Would be neat). So
how would we handle automatic linking when opening a file? Maybe we
just reproduce the layer structure as link layers (one link layer
monitoring only one layer from the linked file)?
Anyway this is work-in-progress, UX-wise.
This commit changes the following:
- It's now possible to set whether to store an absolute or relative path
when editing link layer properties.
- New layer dialog doesn't propose an "Image link" fill type anymore.
Link layers won't be created this way (see in a future commit).
By default, we set them as relative paths. This seems like the more
practical and allows for relocatable folders when one work with project
folders containing all their assets.
We don't have yet a way to set this to being absolute path, but it will
come in a further commit.
This commit was edited after GIMP 3.0, now that we have dedicated
support for loading vector images with GimpVectorLoadProcedure.
- By default, when loaded as GimpLinkLayer, vector images are loaded at
a size so that they are exactly contained in the image.
- When scaled with Scale Layer dialog, link layers of type vector are
re-loaded from the source file to always stay perfectly crisp.
Even though G_FILE_MONITOR_EVENT_CHANGES_DONE_HINT should normally
happen when we are *probably* at the last change of a set of changes,
the keyword is clearly *probably* as I had 5 or 6 of these events when
saving a single image.
There is no need for our link layer to reload a same image that many
times in under a second. Instead, just emit our "changed" signal in an
idly source to avoid uselessly duplicating events.
A GimpLink is just a class monitoring an image file and sending a
"changed" signal when it changes. This will be used to implement link
layers, whose contents is based on an external file.
This is only a simple first version. Future versions may also allow to
monitor specific layers in an image file, or a layer in the same XCF
image which you'd want to link instead of duplicating it.
