It is actually available in the SDK but was removed from the runtime (relatively
recently, it would seem). As a more general rule, it seems that GNOME is phasing
it out slowly in favor of libappstream. So probably we should do the same
eventually.
Yet for now, to at least have a working nightly flatpak, let's add it to our
package.
The flatpak_ci_initiative.yml template we include got changed 2 days ago,
replacing the "only" by a "rules", which broke our CI file.
Cf. commit 193f63c20f87d38868c05beee6446b387b73e140 in repository citemplates.
The present commit should (hopefully) fix this error:
> Unable to create pipeline
> jobs:flatpak-nightly config key may not be used with `rules`: only
(even though the error is a bit cryptic, the problem is apparently that both
rules: and only: keys cannot be used together)
… clean-exiting on all dev code (whether stable or unstable branches).
This is because the dirty exit prevents the on-exit crashes which seem to happen
somewhere in the memory cleanup (which apparently corrupts memory but all crash
traces don't show the proper area where the issue actually hapened). So let's
have release exit the process without issue (at least all important user-facing
data is saved properly by then), while not hiding the issue to developers.
Also on dev code, the GIMP_DIRTY_EXIT will allow to go anyway for the quick
exit() path, so that for instance one can work on other pieces of code without
feeling bothered by the constant crashes on exit.
For the record, the crashes we are talking about appear when you update to a
recent GLib, after the removal of GSlice implementation (which is basically now
just a malloc/free alias). There may be issues in our usage of GSlice though we
also experience crashes even just with commit 69e9ba80e on GLib which hints at
issues in our GObject/GType code.
xcf_save_prop() starts with va_start(), hence must end with va_end(). Yet any of
the xcf_write*_check_error() macros could end this function abruptly. Therefore
I'm adding a "cleanup" argument to the macros, allowing to add any code
necessary to clean the current function before returning.
- Missed a necessary autotools change: forgot to remove ui/Makefile
from configure.ac
- Not all compilers allow declaring variables in a case statement without
putting them in a block, so we add a block now.
Instead of loading the GtkBuilder .ui file we now create all widgets in
code.
Added several support functions to reduce code copy/pasting and making
additional widgets and supporting more metadata easier.
The overall layout should still look the same, with a few exceptions:
- Each notebook page only uses one grid. This makes it possible to align
all data entry widgets.
- Featured Organization and it's code were two treeviews next to each
other. These are now organized below each other to make automatic code
generation easier.
- Since we needed to touch this code anyway, I also fixed Xmp.dc.creator
and Xmp.iptcExt.ModelAge to be multiline. This closes#7286.
- The old icons used for the date button, add, and remove row buttons
were replaced by gimp-grid, list-add and list-remove.
Since this was the last .ui file used in GIMP plug-ins, we remove all
files from the .ui subdirectory and references to that.
Note that there are several more places where GtkBuilder is used, but
those cases uses strings defined in code instead of .ui files.
We had a lot of duplicate code using gexiv2_metadata_try_set_tag_string
and then checking for errors.
Simplify this by re-using the existing set_tag_string function by
introducing an extra parameter that tells us whether or not to clear
the tag first.
It was a temporary code added before relevant code landed in babl. The necessary merge request landed in Babl some time ago, and Gimp now requires Babl version 0.1.98, which includes the needed commit.
Related to merge_requests/509
In the master branch we depend on gexiv2 0.14, so we can remove the
deprecated functions and replace them with the "try_" versions.
We can't backport this, since our stable branch has a lower dependency
for gexiv2.
This ports the Import and export dialogs to use GimpProcedureConfig.
It covers all properties except GUI-only options
(which were still ported to libgimpui rather than direct GTK calls)
Additionally, a warning was fixed and mnemonics were added to the
property titles.
The metadata-viewer uses a GtkBuilder .ui file to create the interface.
In GIMP we prefer our interfaces to be created in code and these builder
files are also not available anymore in GTK4.
This commit removes the .ui file and support code, and creates the
interface from code in our plug-in.
Five icons in the Layer dockable were being replaced by GTK defaults at
runtime. A "gimp-" prefix was added so that GIMP's version would always
be used. A few dialogues were fixed to use constants rather than
hardcoding the filename, to make it easier to update the icon in the
future.
In 2.10, print_temp_proc_name () took in the image id. When it was
updated to take in GimpImage, it still assumed the g_strdup_printf
parameter was an integer.
This is fixed by calling `gimp_image_get_id ()` on the image parameter.
While testing the DCX import MR I saw that one image (abaddon.dcx) was not
recognized. This image uses 4 planes with 8 bpp while we only support
3 planes. The 4 planes type includes an alpha channel.
A few small changes allow us to also load 4 planes by allowing 3 or 4
planes instead of only 3.
Photoshop can save metadata when exporting to tiff or jpeg, including
a thumbnail that we can't update. This can contain sensitive data, so we
should not export it. See issue #8383.
To do this, we add the two Photoshop specific tags that we know of to the
list of tags that should not be exported, so they won't be saved.
This allows file-psd-load-metadata to show a warning message like the
PSD plug-in does when unsupported features are loaded.
As PSD metadata does not store rasterized versions of fill layers,
a new option is added to show these layers are dropped entirely unlike
with PSDs.
The dialog title changes based on which plug-in called it.
This adds the PSD metadata plug-in procedure call to the JPEG
plug-in, as part of implementing issue #7549.
Also implements the import half of issue #1842.
JPEGs only store image-level metadata like paths.
This adds the PSD metadata plug-in procedure call to the TIFF
plug-ins, as part of implementing issue #7549.
Also implements the import part of issue #2921.
TIFFs can have both image and layer-level metadata.
The load_paths() function was removed, as the PSD plug-in should
handle this now.
Creates a new public procedure that can be used by JPEG/TIFF files to
load any PSD-formatted metadata they have. This consolidates code
to the PSD plug-in, and lets JPEG/TIFF get immediate updates as the
PSD plug-in improves its own metadata support.
Note that only Macintosh formatted metadata is currently supported
by the PSD plug-in; IBM PC formatted metadata is reversed and not
yet interpreted.
Alx Sa