Resolves#12755
gimp_edit_selection_tool_active_modifier_key () assumed
that if you press a modifier key while a selection/move tool
is active, we should move the selected item to the last place
recorded. However, it's possible to run this function before
we've moved anything, thus defaulting the "original position"
to 0, 0.
This is most noticeable in the Move Tool, where pressing Ctrl
or Shift after clicking a layer but before moving it will cause
the layer to "jump" based on where the cursor is placed on the
item.
This patch adds an additional condition to the motion function
in gimp_edit_selection_tool_active_modifier_key (), so that
we only do it if we've already moved the cursor at least once.
This patch swaps out the GtkBox in
gimp_enum_icon_box_new_with_toggle ()
with a GtkButtonBox and sets it to EXPAND
so that the buttons are pressed together.
It also adds some CSS style to complete
the effect.
This patch ensures that the text style editor is destroyed whenever a text layer
is selected, even switching between them clicking on different textboxes.
This is necessary to ensure that the on-canvas editor is positioned
correctly according to the coordinates of the selected text layer.
This commit prevents the on-canvas text editor from being dragged outside
the image bounds by checking the overlay's position and adjusting the
coordinates to keep it within the canvas. Additionally, it checks whether
the overlay is entirely outside the canvas and, if so, pushes it back inside.
This commit adds a button inside the on-canvas text editor
that restores the editor to its original position after it has
been moved. The button is only visible when the editor has been
moved, and disappears when it returns to its default position.
... to reset its position via right-click menu
This commit adds the ability to restore the original position of the
on-canvas text editor after it has been moved, by accessing the option
from the context menu opened with a right-click on the text box.
Once the on-canvas text editor has been moved, its position should be
preserved across editing sessions. This commit stores the editor's
position per text layer and restores it when the layer is activated again.
After the on-canvas text editor has been moved, it should remain fixed
on the screen when zooming or panning the canvas. This commit preserves
the current behavior when the editor is in its original position, and
fixes its position on-screen after it has been moved.
This implies both when canceling or committing a filter.
Part of the fix is that we don't store filter tools as part of the tool
history, which means that when we swap back to the previous tool, the
filter tool info is dropped as though we never went through it. This
way, filter tools don't actually look as other tools (even though they
technically still are, since this is how we can implement canvas
interaction for some of the filters).
Per review, let's avoid having all the tools history in every
GimpContext.
Also a further commit will work on special-casing filter tools, which is
why we are storing up to 3 tool infos, instead of only 2.
Rasterizable objects are all created from some side data and can be
renamed automatically based on this data (from the link file for link
layers; from the path for vector layers; from the text for text layers).
So let's share code.
- Getting rid of the dedicated vector layer options dialog (with fill
and stroke settings) which appeared when double-clicking on a vector
layer. This is a duplicated with the Path tool options.
- Double-clicking a vector layer instead will simply start the Path tool
(same as double-clicking a text layer starts the Text tool).
- The path choice settings only is missing from the Path tool options.
Instead of moving it there, I move it to the generic layer options
dialog. I don't think it's the kind of setting you really change often
(most of the time, you likely just make a new vector layer).
- Offsets are ignored too and hidden for vector layers.
- Also making sure that the path changes shows live when editing the
setting in dialog, but it is properly reverted if canceling the
attributes edition.
- Also make sure the undo step changes the path back.
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.
- 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).
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.
Share the whole rasterize logic of the text, link and vector layer into
an interface. I didn't write it as an abstract parent class, because we
might have more rasterizable items in the future, which may not be
layers (e.g. there were discussions of vector masks).
… "Confirm Text Editing" one on Text tool.
When selecting a rasterized vector layer, this will suggest to edit it
anyway (hence losing any modification since rasterization), create a new
layer based off the same path, or cancel.
Instead of blocking various drawable-editing tools to work on vector or
link layers, per tool (as in commits 38c379cd92 or 36330a271a), let's
have a more generic logic in GimpTool. We will now block the tool
initialization early when it's destructive and tries to work on link or
vector layers.
By default, all tools are set as being destructive, but we can override
this per-class by setting the class' is_destructive flag. For instance,
text and path tools, or the Zoom or Color picker tools, etc. are
non-destructive.
Filter tools also are non-destructive (they may be destructive, but have
their internal code to disable this path on these types of layers).
Source tools are special-cased because we may allow them to be
initialized on a link/vector layer as sources. For this special-case, I
make a second check on gimp_tool_button_press().
On empty pass-through groups, it was returning a 1×1 area, which
triggered effects with X/Y distance arguments to have no set min/max
values. For instance, a gaussian blue's X/Y scale widgets end up showing
a [0, 1.5] range, making it very impractical to set higher values.
Resolves#15001
In the MyPaint Brushes v2 port (ea8b9dc1),
I implemented a cursor_update () function from the
parent class. However, I did not call the parent's
version of the function afterwards, so the MyPaint
Brush cursor was not being redrawn. This patch
adds the call to fix the cursor display issue.
Our build files were relying 'sysroot' to find gexiv2.h but this is
not possible with Apple Clang om which sysroot points to macOS SDK.
So, exotic environments like Homebrew were failing. Let's fix this.
The Filter Tool is a "hidden" tool that we switch to
when applying a filter. Like other tools, it commits when
we save our image. However, we may no longer have an
active filter in the tool when we do so (like, after applying
an NDE filter). Because we check the drawable from the
filter to confirm whether we should force NDE or not,
this can cause a CRITICAL when we try to access a now
non-existent filter.
This patch extends the "if (filter_tool->filter)" check to
cover the full commit check process, to prevent the bug.
Resolves#14993
We currently prevent paint tools from painting on
link or vector layers. However, we had not added this
protection to the bucket fill tool. This patch copies over
the relevant if statements to prevent this.
...for toggle bold/italic/underline.
This commit adds support for common formatting shortcuts in the Text Tool:
- Ctrl+B: Toggle bold
- Ctrl+I: Toggle italic
- Ctrl+U: Toggle underline
This commit will make all transform tools run on a link layer cumulate
their transform matrix on top of the previous transform steps. It means
that as long as you don't edit the pixels another way (e.g. with a paint
tool), all your transformations will apply as a single transformation.
For instance it means that applying several transform tool steps on a
monitored link layer will be less destructive than applying the exact
same transformations on the exact same "normal" layer contents.
Even scaling an image to 1x1 then back to a big size will work very
fine!
Note nevertheless the following limitations in current implementation:
* The link layer with transformations will still show as a standard link
layer. Nothing says it has transformation applied on it right now.
* To drop transformations applied on a link layer, you have to discard
the link info, then monitor the link again. A specific action in the
contextual menu could be worth it.
* This should work with all transform tools (scale, rotation, unified,
perspective, 3D, even Warp…) but it won't work for the Flip tool, nor
will it work for the Transform actions. I will need to implement
GimpItem's rotate(), flip() and resize() methods next.
* The layer mask would still be destructively transformed (I have not
made any tests with layer masks yet, but this should be done next
too).
* I think that the "scaled-only" property is now meaningless. It is now
being replaced by the presence of the GimpMatrix3. Nevertheless I have
still not removed this property.
* The load/save code has not been redone yet to include all these
changes.
The kind of caveats we'd have to know about (and which are not planned
for change, because it's just how it is):
* Any intermediate interpolation methods are dropped when cumulating
transform steps. Only the last interpolation is stored. This is
because anyway the interpolation is only there as the best algorithm
where we visually see the less quality loss. Applying several
transformations as a single matrix will always be visually better than
applying several matrices (whatever the intermediate interpolation
methods chosen).
* This only works with the "Adjust" clipping method (basically no
clipping) because 2 transform steps with clipping won't produce the
same result as the multiplied matrix with clipping. It means that
applying a transform with clipping will downgrade your link layer to
being a normal layer.
The only issue I have with this is how to best convey that clipping is
a major setting setting here, which disables our less-destructive
abilities. Right now, people will just have to "know" it.
* Vector link layers in particular will have 2 levels of
non/less-destructivity transforms. In particular any scaling (both
through "Scale Image", "Scale Layers" and transform tools — since I
added code to detect a matrix doing only scaling and optionally
translation) done **first** will be completely non-destructive since
we will simply reload the original vector source at the right
dimensions. Any other kind of transforms will be appended through the
cumulative matrix, as raster link layers. This also includes scaling
done **after** other transforms, since we cannot easily move the
scaling first (matrix multiplication is not commutative). This second
level of scaling will therefore be *less* destructive, but still
destructive.
It is possible eventually to improve the whole thing if we add some
day the ability to request loading a vector image with a transform
matrix (it will then be up to each vector format plug-in to support
this feature or not).
Note: it could be argued that this whole implementation could in fact be
moved over to base layers, since it would allow also less-destructivity
when applying multiple transformations in a row. We would only merge
results once we edit pixels more directly.
But I think that it's not a bad idea to experiment with this new code in
the link layer. Eventually I may likely move this to the parent
GimpLayer if no blocking issues are found.
Resolves#14705
The path tool prevents creating a vector layer from an empty path.
However, the menu option "Path to Vector Layers" does not have this check.
This patch updates the check to constrain it to just one path.
Additionally, it adds a check for the path being NULL before trying to use
it in g_set_object ().
This patch improves vector layer UX based on feedback.
In summary:
* Makes vector layer editable from the Path tool
* Adds initial PDB for creating vector layers in scripts
* Size vector layers to the path size, rather than image
* Transform tools utilize the path for resizing
* Path tool automatically selects vector layer path
Resolves#13087
We use gimp_layer_get_effective_mode () to retrieve
a simplified layer mode for optimization purposes
(e.g. if it's effectively NORMAL, we can do less processing).
GimpTransformGridTool used this function when the user
requests Composited Preview to only apply transforms to
individual layers in a group if absolutely necessary.
This means that sometimes, it returns NORMAL instead of
PASS_THROUGH depending on the number and types of
layers in the group.
Since 71aff497, when we remove a filter we also update the
effective mode of the group layer. However, this leads to an
infinite loop scenario where the effective mode change causes
the TransformGridTool to repeatedly remove and add a filter
until GIMP crashes.
This patch changes the gimp_transform_grid_tool_add_filter ()
check to always get the actual mode rather than the effective mode.
This prevents the effective mode change from causing an infinite loop,
but does mean that we now always apply transforms to all layers of the
group even if the composite preview would work fine.
In an upcoming commit a new user of gimp_gegl_get_op_classes will expect
a list of all operations supported/allowed in GIMP and not just the ones
that are not exposed in the GUI.
In an upcoming commit a new user of gimp_gegl_get_op_classes will expect
a list of all operations supported/allowed in GIMP and not just the ones
that are not exposed in the GUI.
With the same change, this switches from maintaining a list of
operations exposed as an action, this now uses the actions themselves
for the filtering. During this I found some operations that were in the
"exposed in GUI sub-list" were in-fact not exposed but were straight up
blocked. I moved them to the appropriate sub-list along with the
justifications I found in the commit history.
The old API to select stuff and its signals was doing unexpected
stuff and was very confusing. Change things to be "normal":
The selection API is now set_selected() and get_selected(), with no
internal data exposed, and set_selected() emitting the expected
signal.
The signals are now "selection-changed" and "item-activated".
"selection-changed" is always emitted in response to changing the
selection, be it via the API, or by changes in the model (the internal
callbacks in from e.g. GimpContext or GimpImage simply call set_selected()
and don't do any unxpected magic).
The experimental Seamless Clone tool assumes
that all pasted objects are GimpBuffers. With multi-select,
it's now likely that the pasted object is an image containing
layers instead. Thus, the tool would report there was no pasted
data to work with, even though there was.
This patch updates the check so that it retrieves the first selected
layer from the pasted image if it's not a GimpBuffer, allowing the
tool to function again.
Note that this patch does not improve the speed of the Seamless Clone
GEGL operation, just enables the tool to work again in GIMP.
Resolves#13589
When selecting multiple layers to transform, the boundaries
would only consider the first layer selected - leaving the other
items invisible.
This patch reuses code from gimp_edit_paste_get_viewport_offset ()
to loop through all selected layers and update the transform
boundaries to consider the total offset and dimensions of the selected
layers.
