JPEG XL plug-in always imported all JXL images
in 32-bit float precision in the past.
Now it also supports direct import in 8-bit
and 16-bit integer precision too.
Also called "feature" option in meson, so that by default it depends on
auto-detection of the gi-docgen hence won't break the configuration when
the tool is missing (the feature is simply disabled).
Also move the program check into the root meson file, which is anyway
much better to have a better visibility of features, otherwise we'd end
up just having tests everywhere in any possible random directory of the
repo.
Finally add a line in the summary of the configuration step, displaying
the docs generation being enabled or disabled.
One is a patch for a GExiv2 version below the one we now require, the
second is a patch for GIMP which is now committed and pushed.
Cf. commit 7ed68556c7.
I was waiting for GExiv2 to merge a patch I submitted:
https://gitlab.gnome.org/GNOME/gexiv2/-/merge_requests/20
Then we waited for it to land in a released version then for this
version to be in Debian testing. It's all done now and we bumped the
GExiv2 dependency in the previous commit (which makes it a master-only
fix). So all good.
Part of the fix for #5863, which is to depend on newer version of GExiv2
where I contributed new APIs using GError-s instead of GLib warnings for
metadata tag issues.
Now Debian testing packages GExiv2 0.14.0 (and MSYS2 has 0.12.3) so
let's bump the dependency for our dev branch.
gtk-doc has been slowly dying for the past few years; with gi-docgen we
have a nice successor.
This also makes sure the C documentation also uses the GIR file, which
in turn means faster build times (since all the C code doesn't have to
be parsed and recompiled again), and has a clear dependency graph.
See the [gi-docgen tutorial] for more info on how the system works.
[gi-docgen tutorial]: https://gnome.pages.gitlab.gnome.org/gi-docgen/tutorial.html
Sometimes, you just want to quickly select layers, not necessarily save
the pattern. So you'd just type a few words, followed by Enter. Don't
save the search pattern everytime.
Only save it when you hit the "Save" button or on Shift-Enter.
We now save and load layer and channel item sets. Only missing set types
are path ones, but the whole path item is just its own exception in the
XCF format, and adding support for it, while keeping compatibility with
older XCF seem like a small headache. I could do it, but I actually
wonder if it is worth it. Would people really need to store sets of
paths?
Also this commit finally gets rid of any remnant of the old item "link"
concept (I think), so we are getting close to merging the branch.
I cleaned many remaining places where the concept of linked item still
survived.
On loading an XCF file with linked items, we are now going to create a
named sets for the linked items, allowing people to easily select these
back if the relation was still needed.
We don't remove gimp_item_get_linked() yet and in particular, we don't
save stored items into XCF files. This will come in an upcoming change.
- removing the GIMP_ITEM_SET_LINKED enum value.
- removing gimp_image_item_list_linked(). Now we should directly use
gimp_image_item_list_filter() instead.
- "preview-linked" option for transform tools is no more.
When double-clicking the non-selected layer, the function
gimp_view_renderer_set_border_color() was being called, which in turn
called gimp_view_renderer_update() after some idle time.
Unfortunately when this happened, the "update" handler
gimp_container_tree_store_renderer_update() would call
gtk_tree_model_row_changed() which triggers a focus out through GTK.
One way to handle this would be to call gimp_view_renderer_update()
directly when changing border color (no idle time), though it's actually
more efficient to just cancel the idle function when we start editing
the item name. It's just not necessary.
This got broken in commit 28f6b1b268 because you want to always throw
the signal. Yet the context must only be updated with a grid view in the
GimpContainerEditor. Now it should work correctly (hopefully!).
We must make sure to care about slight discrepancies between context
object and actually selected icon representing an object, which might be
slightly different at selection change time (just before everything
syncs up).
… for the case of data managed by the GimpContext.
Checking stable and dev builds, it looks this just never worked and used
to just show no selection. Now it is more annoying as it shows a
selected item, but not the right one. Just make sure it shows whatever
is currently selected.
The whole hack for types managed by context is not needed anymore. It
works fine with generic code. Also because of this hack, there was a bug
when clicking on some button raising a container popup (such as the
"Dynamics" button in tool options) would reset the context to default
value (e.g. reset to "Basic Dynamics") on the first click, without
raising the popup. Only the second click would raise a popup.
Jehan