The whole multi-threading changes in the help plug-in seem to badly
break on macOS. See discussion in reopened#12898.
We decided to get rid of it for now and see later if we need to
reimplement this (after understanding what is going on).
Revert "plug-ins: fix#13049 Calling help on unknown help-id causes..."
This reverts commit 7d153bcc6d.
Revert "plug-ins/help: fix thread unnecessarily waiting when locale_parse failed"
This reverts commit fd0ccfa16c.
Revert "plug-ins/help: fix crash when locale is NULL"
This reverts commit 4075add5b4.
Revert "plug-ins: fix failing to access help from within GIMP"
This reverts commit 38f0527ebc.
Revert "plug-ins: add some better error handling when the docs XML request/parsing fails."
This reverts commit 543bb374a8.
Revert "plug-ins: try to load the gimp-help.xml file in a thread."
This reverts commit f2d47e910b.
Resolves#13124
In 3f3b29ba we bumped XCF version to 23 due to
new blending spaces. However, we did not update
the version check switch statement to accept this
version. This patch adds a new case to handle version
23.
Resolves#12880
Since ICNS stores full PNGs for some icon types, it's
possible for them to have a color profile stored in
their iCCP chunk. This patch enables the existing
metadata option to save color profiles, then passes
that choice to the PNG procedure when exporting. Since the new widget affects the existing flowbox,
we also define a minimum height to prevent cutting
off the first row.
Loading is trickier since other software could
potentially combine PNGs with different color profiles
in the ICNS. GIMP does not yet support per-layer
profiles, so for now we'll follow the way the TIFF
importer does it and just attach the first color profile
we come across while loading.
Resolves#13122
The HTML table code expects RGB or Grayscale pixels
when creating a "BGCOLOR" attribute in the table.
This patch defines the capabilities of the exporter
in GimpExportOptions and retrieves a suitable image
with gimp_export_options_get_image ().
Exporting ORA images involves first creating PNGs of
the layers. To do this, we create separate images for
each layer with Gimp.Image.new ().
However, if the original image was indexed, we lose
the palette when passing the temporary image to
the PDB call. This caused us to try saving a NULL
palette, which resulted in the crash.
This patch adds a check if the image is indexed, and
copies over the palette to the temporary image.
When exporting a grayscale image with alpha channel as DDS while
choosing "default" format, we did not set the DDPF_LUMINANCE flag,
but instead used DDPF_RGB, on loading in the 3.0 branch this caused
a failure to read this format due to unrecognized combination of
settings.
First we make sure that on exporting to also set DDPF_LUMINANCE for
grayscale with alpha.
Second we also make sure to zero the blue and green mask fields,
since that is the expected value when these fields are not used.
To support this type of older exported DDS images, we add an extra
format definition for this unusual combination of DDS settings,
that way we recognize them when opening and are able to load them.
Resolves#13092
GIMP crashed when converting an image to indexed mode,
if the user first changed the color in the Configure Grid
Dialogue. This was because signals were not being
properly disconnected from GimpColorMapSelection
after the dialogue was closed.
Jehan found the solution, to replace
g_signal_connect_swapped () calls with
g_signal_connect_object () and flags set to
G_CONNECT_SWAPPED to retain the original
behavior. This ensures the signals are disconnected
after the widget is destroyed on dialogue close.
So the problem was that the duplicated image (as returned by
gimp_export_options_get_image()) was not fully rendered. I think it is
related to the computed size of pass-through group layers (whose borders
may show actually smaller than their actual render which is in fact
composited with below layers).
I am not perfectly happy with my solution as I'd have prefered fixing
the source issue, but it is good enough, just a few before GIMP 3.0
release.
The call to gimp_drawable_merge_filters() on a group set a buffer to the
group layer (a bit like when we rasterize text layer) which was why it
worked fine. But when the group had no filter, we didn't have this side
effect.
So let's make sure we use the mode node output as our merged layer's
buffer in such case.
Also when the bottom layer (to merge) is a pass-through group, we don't
want to disconnect its input.
Resolves#13104
print_preview_get_thumbnail () crashes when trying
to display thumbnails where the image's precision is
higher than 8 BPC. While the plan is to rewrite/replace
this plug-in, for now, we'll duplicate the drawable's
image and convert to 8BPC to prevent issues.
Resolves#13099
For indexed ICO images, we get the palette from a
temporary image during export. Since the palette is
tied to the image, when we convert the temp image to
RGB and then delete it, the GimpPalette is lost and
the image is exported as pure black.
This patch resolves the issue by calling
gimp_palette_get_colors () to get the actual GeglColors,
then adding them to a new palette with
gimp_palette_new (). As this is separate from the
temporary image, it is retained after the call to
ico_image_get_reduced_buf ().
Resolves#13096
In 5a43a464, some debug output was added to help
diagnosis a problem when Snap to Active Path was
turned on. The issue seemed mostly resolved in e57ad0f8,
but the print statements were left in. This leads to
slowdown when moving layers while Snap is enabled
(due to the continuous print statements).
As it's been 19 years since the original commit, it
should be fine to remove these debug statements
to boost performance.
Previously, we did not check if the clipping path name
was properly converted to ISO-8859-1 from UTF-8
before saving. g_convert can return NULL if it fails,
which means we wrote NULL (causing a crash on load).
To resolve, this patch adds a check if the clipping path
name is NULL on load, warns the user, and then
stops loading the clipping path resource.
On export, we fall back to ASCII instead if the conversion
to ISO-8859-1 fails.
Just using the output of the group is not enough since the pass-through
mode cannot be reused for the normal layer (and anyway all below layers
will have been removed). This still works out with a full-opacity
pass-through, but for lesser opacity, what we want is to replace with
not just the group's render, but in fact the render after the
compositing node.
As far as my tests go, we should now have exactly the same render before
and after merging a pass-through group, whatever the group opacity.
...and GimpPatternClipboard
Resolves#10046
After 1b64fdf5, gimp_get_clipboard_object () no longer
returns a merged version of the selected area.
This affected the Clipboard Brush, Clipboard Mask,
and Clipboard Pattern, causing them to always use the
entire image instead.
To restore the 2.10 behavior, we check if the pasted
image has a selection. If so, then we call
gimp_selection_extract () to get the buffer of the
selected area. We also need to unreference this
buffer afterwards, so a boolean check is added once
the buffer has been copied over to the brush and
pattern.
Existing logic to merge a pass-through group layer was wrong because it
was changing the global rendering of the image as though the group was
in fact in Normal mode.
Instead a pass-through group can be kinda considered as a Normal group
which would contain not only its children, but also all visible sister
layers below it. Therefore the new pass-through group merging will be
taking the real pass-through group render into the new layer (we don't
change the original group's mode before copying the render anymore), set
to Normal mode, then we remove not only the pass-through group but all
its big sister layers below it on same level.
Organizational-wise, it may seem unexpected because "merging" this group
leaks outside it (getting rid of not only the children but also the big
sisters and cousins). Nevertheless this is exactly how this group mode
works after all. So let's go full-in.
After discussing on IRC with Wormnest and NikcDC, we decided that it was
worth doing this specific merge the technically proper way, and we would
just educate people through the docs on why this group mode is very
particular this way.
After all, if someone absolutely wants the old-style merge, they can
always manually change the group to Normal mode first before merging.
But if they let to "Pass-Through", we should assume this is the render
they want.
Some data in a GimpContext may have a reference to a GimpImage. In
particular there may be a GimpLineArt when the bucket fill tool is ON
when exiting GIMP.
In such a case, gimp_exit_idle_cleanup_stray_images() would see a
remaining GimpImage, would believe it's a stray image left by a plug-in,
output an INFO message and free it, which would in turn produce various
CRITICALs when actually finalizing the GimpContext.
Therefore we move gimp_contexts_exit() into gimp_exit(), and not when
disposing of the Gimp object (which happens too late).
