Resolves#15113
There is code in the Gradient Flare plug-in to prevent deleting
gradients when there is only one left. However, the flare count
was not being properly updated. Due to a stray unbounded IF
statement, "if (tmp->next == NULL)", the num_gflares variable
was only decremented if you deleted from the bottom of the list.
As a result, you could delete all the flares and cause the plug-in
to crash when it tried to render a non-existent flare.
This patch removes the stray IF statement and adds additional checks
to make sure dlg->gflare exists before trying to get a pointer from it.
See: Infrastructure/gimp-web-devel#9
gitlab-mr.md was removed without replacement since the
package generation info is now on the MR template for
everyone's benefit (6245e4ee) and the test of the
text was mainly personal annotations.
See: Infrastructure/gimp-web-devel#9
Except API-for-resources.md, which is ugly and
not linked in the README. And GIMP3-API-Changes,
which seems to be just a personal annotation.
Resolves#14752
Our previous logic only worked for single-page PDFs.
If a multi-page PDF was exported, only the first layer
would have the background color set - the rest would
always be transparent regardless of user choice.
This patch moves the "fill background" logic deeper into
the layer drawing code, so that it is considered for each
layer rather than once at the beginning. It is also adjusted
for different situations, such as when the user wants group
layers to be combined.
Per Reju, NDE filters are not factored into the selection
created when turning off the Quick Mask.
This patch adds a call to gimp_drawable_merge_filters ()
on exit so that all active filters are merged down before
the selection is made.
- The "Create New Vector Layer" button is now always active, as long as
there is an image.
- When a path is selected with no matching vector layer, the button's
label will be "Create Vector Layer from Path", indicating that it will
create a new vector layer from the current path.
- When selecting a path while the Path tool is active, let's update the
selected layers to all the layers (it may be several layers!) tied to
this path. Otherwise, this can be quite confusing, showing a path
while another layer is selected, or worse, showing a path while the
selected layer is a vector layer (but not tied to this path).
Cf. discussions on IRC with Alx.
Since this is editable directly in the Path tool options, we likely
don't need to have the separate action for it. It feels redundant.
It is still available on a double-click, though I am not sure if it's a
good idea. Maybe the double-click should rather activate the path tool,
from which you can edit all these (just as what happens with the text
tool). To be continued after more UX discussions?
This is the result of a UX session with Aryeom. Just showing a message
forbidding editing of non-rasterized text/link/vector layers is
problematic, because it doesn't help people understand how to unblock
their situation (if they really want to just edit directly the layer).
Additionally we are now blinking the layer.
A possible alternative could have been to pop a dialog up, with the
same message but also with a quick-action button to allow rasterize in a
click (similar to how we are popping a dialog up to revert the
rasterization when clicking on a text layer with the text tool or a
vector layer with the path tool). The problem is that even though the
need to edit directly a non-raster layer arises from time to time, most
of the time, when you use such layers, you don't intend to edit these
(unlike editing text/path with matching tools, you more often wanted to
edit the relevant data).
Therefore it is more often than not just a mistake when you try to paint
directly on such a layer. I.e. that very often, you were intending to
paint on another layer, or add a new layer above your non-raster layer.
Therefore a dialog popping up every time you made such a mistake would
be annoying and workflow-breaking. A simple error message and some
blinking leave for a fluid process.
The previous code was preventing initializing, but some succession of
actions could go round this check: Rasterize then Revert Rasterize. In
this state, the next click would not try to initialize again, which
first is not very good if the initialization was necessary, and second
would allow drawing on a non-rasterized text/link/vector layer.
So let's just have all the code blocking drawing on rasterizable
drawables in the generic gimp_tool_button_press() code only.
When non-interactive mode is requested (the -i command-line flag),
_and_ we've compiled the app with UI support enabled, allow `gimp`
to branch into the console-based version of the app -- equivalent to
running it using `gimp-console`.
This avoids GTK-related failures open a display when one is not
not available (for example, when running `gimp` within a container
or a VM without a graphical display).
- Some useless space cleanups.
- Properly free a string.
- Localize procedure documentation strings, except the help text for the
load procedure as it focuses on rendering to raster, which is true
now, but soon should not be! Let's not give useless work to
translators if we soon plan to change this. Also I don't think that
naming the library we use has much interest in a creator-facing
string.
- Fix export documentation strings (we don't export only vector
layers!).
Fixes:
> (file-svg:125356): Gtk-CRITICAL **: 22:11:43.459: gtk_entry_buffer_set_text: assertion 'chars != NULL' failed
… when running file-svg-export because the default of the "title" string
argument is NULL.
I did hesitate considering this was a bug in file-svg code on the
premises that a NULL value was not valid (hence replacing it as ""), but
in the end, I went with the more flexible solution, which is that NULL
is considered equivalent to "". So GimpLabelEntry code will just
transform the NULL pointer internally to an empty string.
There were 3 bugs which were kinda countering each other and
participating to some confusion regarding actual layer types to export.
First the previous commit as we were looking whether a layer had been
rasterized to determine the object type on libgimp side. Secondly this
commit as the plug-in was using the previously wrong procedures. Lastly
with the upcoming commit, when we were duplicating an image, we were
disregarding any rasterization.
Without this, libgimp was creating raster GimpLayer objects when these
had been rasterized, which only made kinda sense when the old "discard"
procedures were not reversible. Yet even this was not entirely true,
since it was still possible to undo, but unfortunately these objects are
long lived. Once you get a GimpLayer, it won't ever change into a
GimpTextLayer (or others)!
So we need to have an object of the correct child type then we'll use
gimp_rasterizable_is_rasterized() to decide how to make use of the
object.
Commit 6874c47544 was not correct as we generate some type/values
description, extensively using Pango markup.
This additional fix does not change the logic from the aforementionned
commit, which is that the blurb still is just plain text (nor markup),
which we properly escape to display as-is, mixed with Pango markup.
