Checking the log, it looks like this code has not been touched since
2007, so whatever this various was used for, it's clearly not been used
for a long time.
Fixes warning:
> libgimpwidgets/gimpcairo-utils.c:80:16: warning: variable 'total_length' set but not used [-Wunused-but-set-variable]
Fix warning:
> plug-ins/file-dds/dxt.c:113:1: warning: unused function 'pack_rgb565'
I don't just remove it as I guess it may be of use at some point for a
not-yet fully implemented feature yet?
Avoid the stack smashing bug from yesterday in other functions.
Additionally to fixing other functions, do not cast the pointer to size
in the PDB generation scripts so that we can quickly spot such bugs in
the future, through compilation time warnings, instead of hiding them.
Currently there are 5 separate plug-in-gauss
functions. IIR2 and RLE2 are not used, and
IIR and RLE are identical to each other.
Additionally, they all call a separate
gaussian_blur () function which multiples
two parameters by 0.32 to convert to the
actual GEGL operation.
This patch removes all functions except
for plug-in-gauss. It converts each
existing script that used one of the other
variants to use plug-in-gauss, and
multiples the coefficients by 0.32 so that
plug-in-gauss behaves the same as calling
gegl:gaussian-blur with a C plug-in.
There also exists a plug_in_pixelize2 ()
function in the PDB which allows the user to set
both the pixel width and height.
This patch converts this to become
plug_in_pixelize (), and removes the older
function which used a single width
parameter for both values.
When linking with clang/lld, I had the following linking error:
> ld.lld: error: undefined symbol: pow
As a side change, also adding math.h header include, even though it
didn't seem to break compilation. Just to be thorough.
Additionally to fixing a deprecation, I also ensure that we don't limit
pointer source to what the system considers the "Core Pointer" on
Wayland.
It is another bug similar to #8016 and possibly what !924 was trying to
fix, even though it turned out this was not the same problem which I
initially reported. In this other variant, when you were hitting Space,
it would originate from the "Core Keyboard" which was associated to a
"Core Pointer". On a laptop, this Core Pointer could be the trackpoint
for instance (in my case) so you could pan with Space + trackpoint move.
Yet say you add a graphics tablet, which is a separate pointer: you
could not pan with Space + stylus move!
Now you can, because when we are pan-spacing, events from all pointer
sources are accepted. Only when the panning comes from a pointer source
(middle click) do we listen only events from this same pointer device.
This reverts commit 413cf9ad85.
As discussed with mitch during last Wilber Week, and commented in !924,
the fix was creating new problem and was not right. We definitely want
to grab pointer events when panning (or other similar interactions).
Also I think I had not tested under Wayland back then, only verified I
didn't see any huge issue on X11, but the commit did not in fact fix the
original issue #8016 (this time, I verified!). The problem I was
encountering seem to be more in how Wayland works + libinput, not giving
full control on input devices to applications and trying to be "smart"
with an option ("Disable Touchpad While Typing") which is often useful,
but other times counter-productive (e.g. in GIMP when we want to
space-panning — which should not be considered typing —, or again
shortcuts in video games, and so on).
When the passed code had a bug, the plug-in was crashing along with the
code given in argument. Instead, we must catch all exceptions and pass
the error message raised by exec() to the core application.
Since commit 4e499810, GIMP could crash on switching to
multi-window mode on X11 Linux systems.
As suggested by Alx Sa it is enough to add a NULL check for
shell to avoid the crash.
From now, Windows contributors can use the default shell provided by the OS
(which is PS since Windows build 10.0.14971.0), like Linux and macOS users do.
We still use MSYS2 but not the POSIX shell. This change adds these features:
'1_build-deps-msys2.sh' is now '1_build-deps-msys2.ps1'
- Faster clonning by using 'git-scm' (the MSYS2 one had performance problems)
- Easier to use non-MSYS2 binaries, not only 'git-scm' but also official meson,
deps from vckpg etc. This is a needed step towards the future use of MSVC.
'2_build-gimp-msys2.sh' is now '2_build-gimp-msys2.ps1'
- By default, vanilla builds (normally triggered on PS) will create a bundle,
dropping the need of 'gimp.cmd' (that adressed .typelib and .interp limits),
which is inline with other (Cmake-based) projects like Darktable and Inkscape.
This change is important because even Windows devs more experienced than me
get confused with the relocatibility stuff, which is the default on Windows.
'2_bundle-gimp-uni_base.sh'
- As a result of the change above, bundling code was changed to be a bit faster.
It still is, however, painfully slow, since meson doesn't have a 'install()'
function like Cmake to prepend targets in Ninja's 'install_manifest.txt'.
Since we are not using a POSIX shell (nor 'mintty') anymore:
- GIMP can be built from every path easily with R. Click "Open Terminal", with
IDE integrations etc, without needing to manual tweak MSYS2 .ini files etc.
We could tweak MSYS2 to get the features above but not top-tier integration.
- Developers can be more aware of Windows native vars, paths etc, and avoid bugs
Some build files were improved to support the 'Windows way of doing things'.
- No need to close and reopen terminal anymore after running 'pacman -Suy'!
---
REGRESSION: Vala plug-ins are temporarely gone due to 'vapigen' bugs, a small
regression since this is a gnomeish language but I will investigate how to fix.
In 41894be7, GIMP_COLOR_PROFILE_POLICY_KEEP was accidentally
used instead of GIMP_METADATA_ROTATION_POLICY_KEEP as the
possible output of gimp_image_metadata_rotate_dialog ().
Fortunately they are currently the same value, but it would be best to
return the right enum type.
GimpControllerEditor's "Select Controller Event Action" dialogue has
a border around the standard icon. This is because it uses a GimpViewableDialog,
which normally shows the current image or layer as the right side icon (and thus
needs a border to potentially distinguish).
Since this is a special case, this patch retrieves the GimpViewRenderer for the icon
and then sets the border color to transparent.
After we converted most scripts in the repo to use new registration functions,
there are no *filters* left from version 2.
But version 2 filters are still supported, with a warning
to the console like "image procedures ... only one drawable ... are deprecated."
A version 2 filter uses
the deprecated registration function script-fu-register
and declares args img and drawable (singular) explicitly
(contrary to encouraged multi-layer capable.)
Until we actually obsolete scripts of this ilk,
we need this test plugin for testing.
Resolves#12226.
GimpGradientEditor's saved_color array was
converted to GeglColor as part of the color
space invasion. However, we were still
treating it as if it was a GimpRGB array, so
we'd use gegl_color_set_pixel () to convert
it for gimp_action_group_set_action_color ().
This resulted in the menu displaying empty colors.
This patch removes the unnecessary conversions
and passed the saved_color values directly so that
they show up in the menu.
Per Lloyd Konneker, all Python plug-ins except
histogram-export and gradients-save-as-css
have "python-fu-" in front of their name.
In fact, gradients-save-as-css does have
this prefix in some places already.
Since this is also how it was written in 2.10,
let's rename them now to be consistent.
As reported by Anders in !1919. This is because
gimp_pdb_execute_procedure_by_name() now expects a proper GimpArray for
float and int arrays, not a C array preceded by a size value.
Generated libgimp functions' arguments are normally tested through the
PDB, so that you get proper error messages when trying to call a
function with invalid arguments.
This is not true anymore for array arguments since the size argument is
not a PDB arg, only in the C function. Therefore I'm adding an
infrastructure asserting on invalid size, using the same PDB type
annotations as other args. It is important to assert valid input on
plug-in side (i.e. libgimp) so that the core doesn't make any assumption
on having received valid input when it has not.
Also changing size argument of gimppainttools PDB-generated functions to
proper gsize.
Yet they still are generated libgimp functions' arguments.
For instance gimp_context_get_line_dash_pattern() still has a num_dashes
integer argument and a dashes C array, but when calling the PDB
procedure "gimp-context-get-line-dash-pattern", we only set the
GimpArray.
This will allow simpler direct PDB calls too, included in script-fu,
where the size argument is really redundant.
GimpArray (and therefore the int32 array typedef) contains its own size.
We don't need to store the array size in a preceding argument.
Also adding gimp_int32_array_get_values() and gimp_int32_array_set_values()
to edit an existing GimpArray.
This comes with the fact we should start making the GimpArray type more
explicit, because clearly by trying to hide this type so much, it was
too much looking like the int32 array param spec was expecting a C array
(as was visible in the file-ico plug-in where we were getting a C array,
which was a bug only made invisible by the fact we were not setting the
C array back in the config object in the end).
Last but not least, I finally implemented int32 array (de)serialization.
As a side fix, the "images" arg in file-pdf-export-multi procedure is
now a proper image array (not an int32 array), and of course the "count"
arg was removed.
PDB code is now looking directly into the GimpArray length for
determining the data length.
Also adding a 'size' argument (number of elements, not bytes) to
gimp_value_(get|dup)_int32_array() to make it actually introspectable.
Until now, it was somehow introspected but was segfaulting on run.
I.e. that, e.g. in Python, calling Gimp.value_set_int32_array(v, [1, 2, 3])
followed by Gimp.value_get_int32_array(v) would actually make a
segmentation fault. Now the binding works flawlessly.
This will also make these functions much more usable in general.
Jehan