Resolves#16019
The Edit -> Fill with... options did not respect if
layers could not be filled (such as linked layers or
multiple selected layers with some layers being
pixel locked). This patch adds checks instead of
unconditionally filling those layers.
It also adds the text & vector specific fills from 916cf84e
to keep this action consistent.
Resolves#153494812fddc adds the ability to delete multiple items
at once. However, the limit to delete was accidentally
set to greater than 1, rather than 0. This patch fixes
this mistake.
As of 443947c6, we no longer require passing
the selected drawables to the export plug-ins
(as each plug-in now grabs those from the
image itself).
Therefore, we can remove the restriction that
there must be a selected layer before you
can export or save an image.
Instead of deleting all selected paths except
for those attached to vector layers, we
stop the action and notify the user that
they can not delete paths attached to
vector layers.
Resolves#9285
In images_delete_image_cmd_callback (), we dereference
images which we want to delete. This works for images created
via the GUI. However, images created via PDB scripts are not
automatically connected to the display if created with no layers.
If you try to delete them, they will be dereferenced but will still
in the ImageView dockable. This can cause a crash if you try to
access the container again, since it will point to an unreferenced
variable.
This patch removes the image from the container first before
dereferencing it, to prevent the crash.
When the user chooses "Raise or Open Image" in the
Document History, we first try to raise an image in
documents_raise_display (). This calls gimp_display_get_image ()
to get the active image from the current display, and raise it
if it already exists.
However, if you call this when the canvas is empty, it will throw a
CRITICAL since the "image" parameter for gimp_image_get_file ()
and gimp_image_get_imported_file () calls will be NULL.
This patch adds a check if the image received from
gimp_display_get_image () is NULL, and if so, we stop the function
before trying to raise it.
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.
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.
New action "Last Tool" ("context-tools-swap"), defaulted to <shift>X.
Thanks to Damien de Lemeny for the original patch and Alexander Hämmerle
for the test case in test-ui.c.
This patch enables multiple selections in
the GimpDocumentView widget and dockable.
It also updates the "documents-open" and
"documents-remove" actions to check if the
GimpContainerView has more than
one selection, and if so, tries to load/remove
all of those images. The action wording is
slightly edited to indicate multiple
images can now be opened/removed.
Though I did fix the render bugs with commit 833e5858a3, merging
pass-through groups is still quite confusing. Furthermore, it feels like
whoever would use such group mode would not want to merge it because the
whole point of this mode is having a group which doesn't act like a
group!
So let's just forbid merging these, display a status error and blink the
pass-through group to attract attention to the problem.
Note that it doesn't prevent flattening the whole image, or merging the
visible layers (even if there may be pass-through groups in there).
These will work fine, even with pass-through groups, now. And this is a
case where we don't expect any layer to stay around anyway, so it's not
confusing anymore.
- Merging down a pass-through group onto a layer below does not make any
sense, considering how the below layer is the input to the
pass-through.
- Adding ability to blink problematic items when merge down fails. This
will help people to figure out what is the problem.
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.
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).
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?
Based on the label, and also "retrieve" was just too generic. It made
sense in the context of rasterizable items, but with the more generic
"layers" context, it would raise uncertainty.
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).
Per discussions with Alx, this wording would increase connection with
the "Rasterize" action. Also, even though it feels slightly improper
English, if we treat "Rasterize" like an action name, then it does make
sense in English too.
The following actions are removed: layers-link-discard,
layers-text-discard and layers-vector-discard. The new action
"layers-rasterize" introduced previously will handle all of these.
Since layers-text-discard is the only one which existed until GIMP 3.0,
we are migrating any custom shortcut which may have been set to
layers-rasterize (both from 3.0 shortcutsrc or older menurc).
Action layers-link-monitor is also removed (in favor of layers-retrieve)
but no migration code is added, since this didn't exist in 3.0.
These 2 new actions are meant to be usable on all 3 types of non-raster
(and non-group) layers, i.e. link, text and vector layers, to
respectively rasterize and un-rasterize them.
This will also work with multiple selected layers, and is not specific
to one type of layers.
I also change how gimp_text_layer_discard() used to work, by marking the
text layer as modified instead of actually discarding all text
information. The main consequence of this was that a layer rasterized
this way was forever lost. Now it can actually be revived as a text
layer, not only through the new layers-retrieve action, but also by
trying to edit it with the Text tool, which will trigger the same dialog
as when a text layer had been rasterized by editing it with a paint
tool.
Whereas the label of "layers-rasterize" seem to be quite straightforward
(simply "Rasterize" per discussions in gimp-ux#252), I am really unsure
of the label for "layers-retrieve". Further UX discussions should help
on this front.
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.
While there are cases when you want to edit the mask straight away (this is
often the case when starting with a white or black mask), in many other cases,
the mask may be already as you want it per its initialization (e.g. when
initializing with a channel, selection, the alpha channel, etc.).
Until now, the Add Mask dialog was always switching to the "Edit Layer Mask"
mode by default, which forced an additional unneeded click each time you created
a mask (and were in a case where you initialize the mask as you want it
directly).
Now adding "Edit mask immediately" feature in the "Add Layer Mask dialog":
* It's checked by default to keep historical behavior.
* As most other dialogs, the last value is remembered, allowing people with
repetitive workflow not to have to repeatedly set the settings each and every
time.
* This default is also visible and settable in Preferences > Interface > Dialog
Defaults.
As reported by Liam, apparently for someone with a lot of filters, these
node creations just to check the aux input may add up noticeable time on
boot (it may also depend on the OS too? I didn't have any noticeable
delay personally).
Unfortunately we cannot know the presence of an aux input just with
class introspection because they can be registered by the op at runtime.
This optimization is therefore twofold:
* Since we know which filters have an aux input among all the ones with
hardcoded actions, we also hardcode this data. It means we only do the
actual check on non-hardcoded operations (third-party filters but also
GEGL operations which are not specifically listed in our code).
* I only do these checks once, stored by name in a hash table, because
filters_actions_setup() is actually run several times (for different
menus).
This should improve startup time a lot for people who experienced this
delay.
Though I can't reproduce on Linux, the performance log seems to show we
spend too much time inside filters_actions_update(). Instead of creating
nodes at each update, let's just store the information about which
filter action has pad, since this should not change within the timespan
of a given session.
Remove most of the per-action special-casing. This won't scale, and in
fact it already doesn't work well with all generated actions from GEGL
operations. Considering that any third-party operation will generate an
action too, this just can't work.
Instead we know that:
- Filters on group, vector and link layers must always be run
non-destructively.
- Non-interactive filters are always run destructively and therefore
cannot be run on group, vector or link layers.
- GEGL graph as well, unless a specific environment is set.
- All operations with auxiliary inputs cannot be run non-destructively
(yet) either and therefore must also be deactivated on these layer
types.
A few more actions are still special-cased (in particular regarding
being used on grayscale drawable or on formats with an alpha channel),
though it would be nice if we could generalize these somehow eventually
too.
… the whole canvas while keeping aspect ratio of the source image.
The previous dimensions were not entirely "out of the blue" since they
were taken from the file, but very often dimensions from vector images
are kinda bogus (apart from aspect ratio, they don't mean much) anyway.
Now we will just fill the canvas box by default.
When changing the source file of an existing link layer though (through
Link Layer properties), the dimensions will be within the current layer
bounding box.
Also I realized that we need to also store the link width/height in the
XCF because the buffer width/height may not be right (in case a
transform matrix was applied). This commit therefore breaks XCF file
with link layers made in the last 2 days. Since we have not made even a
dev release, it's probably fine to do this and not bump the XCF version.
...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
Revert the logic of opening all files as link layers back into loading
their current content as normal layers.
Instead just add a new action dedicated to open images as link layers
and add it to the File menu.
Per UX discussions with Aryeom.
Instead of keeping a "modified" property in GimpLinkLayer, we just check
if the link is being monitored. It's also a better wording because we
may "discard the link information" without actually modifying the layer
pixels.
Also I now actually shut down the file monitoring process. This can be a
bit expensive so when we don't need it, let's really free the
GFileMonitor.
This commit also fixes scaling of link layer (which got broken along the
way) and improves the undo code.
Note: I'll probably want to modify the XCF flags, but let's do this in
the end, depending on further changes too.
This commit changes the following:
- It's now possible to set whether to store an absolute or relative path
when editing link layer properties.
- New layer dialog doesn't propose an "Image link" fill type anymore.
Link layers won't be created this way (see in a future commit).
This commit was edited after GIMP 3.0, now that we have dedicated
support for loading vector images with GimpVectorLoadProcedure.
- By default, when loaded as GimpLinkLayer, vector images are loaded at
a size so that they are exactly contained in the image.
- When scaled with Scale Layer dialog, link layers of type vector are
re-loaded from the source file to always stay perfectly crisp.
