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.
… PDB type.
This is a first step for #7369. Clearly our GimpObjectArray was meant to
be used with C arrays, hence the wrapper function
gimp_value_set_object_array() which was taking a C array and actually
creating and setting a GimpObjectArray.
This is why our new type is actually a C array aliased as a boxed type
and containing its own size (thanks to NULL-termination).
Eventually GimpCoreObjectArray is meant to replace GimpObjectArray.
The only issue is that such a type does not allow NULL as a valid
element in such an array, but fact is that I don't think we currently
have any use case where this matters. If ever such a case arise in the
future, we may introduce back GimpObjectArray.
In this first commit, I replaced all itemarray PDB types with a new
drawablearray using this new boxed type when relevant.
For some symbols defined or deprecated in GIMP 2 and obsolete in GIMP 3.
ScriptFu automatically loaded these definitions
during development of GIMP 3 (from 2.99 to 3.0rc1).
That is no longer the case.
A third-party script CAN load them explicitly.
We discourage that, for scripts to be shared,
but it is convenient for private use.
PDB-compat-v2.scm is also an executable definition of renamings,
useful as a cross check of published documents re porting plugins
from v2 to v3.
So an editor recognizes them.
Renames script-fu.init to init.scm since that is a Scheme convention.
Scheme interpreter maintainers expect that name.
The same name as upstream TinyScheme.
When mingled with plugin scripts, they needed a non-standard suffix .init.
Which makes an editor not recognize them.
Which deviates from Scheme convention for the main init script: init.scm.
The separate directory is also a place for script authors
to put Scheme scripts they don't want loaded automatically,
but when a script calls Scheme load function.
No change to observable behavior in the app or ScriptFu tools.
This is rarely done.
Most script plugins call PDB functions that are GIMP INTERNAL (gimp-foo)
or filter plugins that wrap Gegl filters (plug-in-foo).
But a Scheme script plugin can call other script plugins (script-fu-foo).
When a script does call another script,
it can be within the interpreter (purely in Scheme),
or to an interpreter in another process (via the PDB, with binding.)
It can get complicated using the optional v3 binding of return values.
This tests and illustrates different cases.
Mostly one word substitutions.
A few function definitions were moved to the scope of
a single script that used them.
Those functions won't be available to third party scripts
except now by cut and paste.
For major release 3.0.
