This patch connects GimpImageWindow's notebook
header to respond to external file/URI drag-n-drop.
If you drag files onto the image tab bar, it will create a
new image for each file.
Code based on a similar feature in gimpdisplayshell-dnd.c.
The analogue of Control key on macOS is the Command key, this means that
`GDK_CONTROL_MASK` has not the expected behavior on macOS. This commit
changes the modifier for unformatted paste in text tool from Control to
Primary, which maps to Command on macOS and Control on other platforms.
This patch adds a Paste Unformatted Text item inside the
right-click menu of Text Tool, which allows user to paste
previously copied, possibly formatted (marked) text as plain
text with no markup.
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!).
