… 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.
When the function is not trivially substituted with a call to a Scheme R5RS function.
In other words, compatibility definitions that are not just an alias from SIOD to R5RS
Scheme dialects.
The prior removal was based on comments in the code,
saying the functions could easily be removed.
It turns out the functions are used in the repo, and not easily replaced.
Third party scripts may suffer the same dilemma:
use SIOD functions that are not trivially replaced.
This commit only fixes the dilemma for the scripts in the GIMP repo.
Reverted and kept:
*pi* symbol for math constant
cons-array an obscure function of unknown origin
butlast a function in some Scheme dialects but apparently not in R5RS
These MIGHT be removed in the future, with more work.
Leaves the mechanism in place, but erases all rows of the alias map data.
Update devel-doc to say ScriptFu has its own mechanism for aliasing.
For major release 3.0
Resolves issue #12203.
Similar to d87c728f, dragging a layer over to a new image via
the tabs uses gimp_image_new_from_drawable () and only
copies a single layer. This patch adds the filter copy code
here as well.
This patch adds a pdb getter/setter for GimpStrokeOptions'
emulate-brush-dynamics property. This allows users to change
the "Direction" of strokes via Script-fu/Python API calls.
Resolves#12198.
When dragging a layer to the toolbox to create a new
image, we weren't copying over the filters. This is because
that action still uses gimp_image_new_from_drawable ()
rather than the multi-layer capable gimp_image_new_from_drawables ()
function.
For now, we'll fix the immediate problem by implementing the filter
copy code in this function. Long term, we should port that code to
use gimp_image_new_from_drawables () instead.
Per Anders Jonsson, the grid colors can have semi-transparency even
if the image itself has no alpha channel. This patch always sets the
GeglColor's babl format to contain an Alpha channel, rather than reusing
the image's color format. The index used for alpha is also updated to
adjust to the number of channels, since GimpRGB previously always used
index 3 for both RGB and Grayscale images.
Call them on different modes of image
and different sizes of image.
Motivated by faults discovered in denoise filter for small images.
No faults detected by new tests.
ScriptFu: tests: enhance testing of gegl wrapper plugins
Add tests on other image modes.
Add tests on small images.
No changes except to tests.
After changes to API:
Colormap=>Palette
Vectors=>Path
After changes to ScriptFu handling of color.
Misc upgrade of tests to use-v3 binding
Revise handling of GeglColor, formerly GimpRGB.
Marshall to/from Scheme lists of numeric.
Marshall from string CSS names and notations.
Conversion to/from GRAY, GRAYA, RGB, RGBA.
See color.scm test script.
Similar to previous commit. If we don't want people to use this function
yet need to export it, at least don't expose the declaration in shipped
headers and even less in the API docs.
Since we consider it private, yet it's still needed in libgimp and app,
let's at least put it in a private header because there is no need for
people to try it out.
I'm also editing a bit the annotations for gimp_main() and GIMP_MAIN().
