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).
We need 2 lines in the PDB for it to be an empty line in the C file,
which in turn will be interpreted as markdown-like lists for the
gi-docgen generated HTML docs.
Pango shows all fonts in the family as "Skia Bold", unless the psname is not matched
so we make an exception for skia and don't match on psname in the custom fontconfig xml.
see issue 14659.
- Consistently add the text about inserting items into the image after
creation, with correct function links/references.
- Consistent grammar for function blurb.
- Make @name argument nullable for gimp_path_new().
… "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.
New libgimpwidgets icon macros: GIMP_ICON_LAYER_LINK_LAYER and
GIMP_ICON_LAYER_VECTOR_LAYER. Note that the actual icons still need to
be done so I use temporary actual icon designs for now.
Also adding some TODOs for these.
Fix run warning:
> WARNING: icon theme has no icon 'gimp-vector-layer'.
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.
While "gimp-vectors-list" migration to newer name "gimp-path-list" was
correctly happening from GIMP 3.0 to 3.2, there is a different code path
from 2.x to 3.2 (because the scale factor update can only happen in this
latter codepath). So this part of the migration needs to be duplicated
in both update functions.
While the migration code did exist from 3.0 shortcutsrc, we need to
duplicate this for the menurc migration, in case someone were to migrate
from 2.10, 2.8 or older (i.e. installing 3.2 after GIMP 2 without having
ever installed 3.0 in-between).
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.
A GLogLevelFlags fatal_mask variable was
created inside an #if defined (G_OS_WIN32)
block, below a function call to
gimp_test_utils_set_gimp3_directory (). This
resulted in build warnings on Windows:
"ISO C90 forbids mixing declarations and code"
This patch adds another #if defined (G_OS_WIN32)
at the top and moves the variable declaration there.
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.
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().
This patch moves the enums for GimpTextOutline
and GimpTextOutlineDirection so that they are
accessible to plug-ins/scripts. This will allow
for us to add PDB functions to get/set text outline
properties.
… pass-through group layer.
Because of the strength-reduce pass-through to normal mode, we had case
when the effective layer mode of a pass-through group ended up to
Normal, which may shrink the effective bounding box.
Note that getting rid of the GimpGroupLayer's get_effective_mode()
(gimp_group_layer_get_effective_mode()) implementation was also fixing
this issue. I did hesitate a lot because it is also simplifying the code
a lot. But I was also wary about getting rid of the optimization
previously made by Ell (see commit fa9a023c270; note that I haven't
actually tested how efficient this optimization is).
This seems like a good compromise.
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.
… impossible to use them like adjustment layers without additional step.
Even without the "adjustment layer" look-alike use case, this is wrong,
because an effect on an adjustment layer will be only applied on the
area contained in child layers, whereas by definition, a pass-through
layer would use the below render as input, and therefore its output
could be bigger than its child layers box.
I could find commit aa9ae1c65c as a culprit commit, and reverting it
would in fact also fix this issue, though by doing this, we'd regress on
the issue #4634 (I tested with one of the contributed XCF and can indeed
reproduce the bug).
Instead I return the unioned bounding box of the node, and of the
computed one. I do not feel like it's optimal, but this feels like a
complicated issue. It looks to me like there might be another deeper
issue in how both these bounding boxes are computed (not optimally!).
In any case, it also makes empty pass-through groups now usable to apply
directly an effect on the whole below render, as a side effect.
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.
This fixes 46d9a09698. There was a reason why this was not implemented
as an assert-type error nor as a user-facing error: network problems
happen.
We cannot pop an error up every time:
* The computer is offline! 😱 GIMP is not made to be run as a connected
software and working on GIMP with a non-connected computer is a
perfectly valid way of using GIMP.
* gimp.org is down (it's rare, but it happens and it should not have any
impact to creators with GIMP).
* You are behind some kind of proxy or other complicated network
configuration which GIO is not able to pass through.
* And any other reason which could make your GIMP not able to read the
remote json file…
Instead let's check the more particular domain and error code, though
even this I hesitated between doing this change or simply reverting
commit 46d9a09698.
Indeed it's still quite a generic G_IO_ERROR_NOT_SUPPORTED error, so I
do hope we cannot get it in other normal conditions where reading a
remote link may fail. The last thing we want is GIMP popping up errors
which are neither bugs in our code, nor environment issues for which
anyone can do anything about.
… gimp_file_load().
We make sure that the load procedure associated to the file is the one
used for the inner-file (in case of imbricated files into container
formats).
Also let's set the imported file unless it's a XCF inner format.
… determine if a file is XCF.
This was kinda already working for files loaded through the GUI. Yet the
code in file_open_file_proc_is_import() was assuming a file loaded
through the file-compressor plug-in is necessarily XCF.
Even though it is the original use, the code in file-compressor is
actually generic and is able to load any supported format additionally
compressed with gz, bz2 or xz.
Furthermore, we will soon support zip-ped imaged, explicitly to support
the format .hgt.zip which is quite common (see !2483). So remove any
logic of a file loaded by file-compressor as meaning it's a compressed
XCF.
Users were thinking the tutorials are some kind of official docs,
but they are not maintained as the official GIMP help website,
they are more like informal documentation about GIMP made public.
Let's clarify this reordering the buttons.
Closes#13553
Such issue tends to affect only AppImage users (e.g. when running it in
KDE installations). This is because AppImage files are not ran by
any host helper (e.g. snapd or flatpak) to connect to GVFSd and is
not possible to bundle GVFSd due to its own nature (it is daemon).
Since GVFS is listed in the INSTALL file as a required dependency, it is
fair enough to be more clear when it is not present, otherwise users will
have outdated GIMP without knowing (like happened in macOS in the past).
We are already doing this with GIMP help plug-in by the way. The
difference is that, at GIMP start, such techinical error message can
be surprising, but even so it is needed as feedback for fail on the
update check button in the end of day. Let's follow GIMP help on this.
The rgba variable would be used uninitialized. This needs to be moved
one loop level up so that the color extracted at each cell start
position is properly reused (and also so that the full transparent color
at no-entry position is properly set and reused too).
