Allow (script-fu-use-v3) in script, or in SF Console.
Definitive description is in script-fu/docs/using-v3-binding.md
Makes SF interpret v3 of SF dialect.
- marshals single return value from PDB without wrapping in list
- marshals boolean return value from PDB as #t #f instead of integers
- marshals boolean to PDB from #t and #f or TRUE and FALSE
- marshals void return from PDB as () instead of (#t), but that is moot.
The version of SF dialect is distinct from the version of the PDB API.
Dialect v3 is opt-in: the initial dialect of all SF tools remains v2.
Commit also allows #t,#f for defaults of SF-TOGGLE instead of TRUE, FALSE
but that is an independent enhancement (but closely related.)
Affects interpreter state of the current process.
Not an attribute per se of a plugin.
While in this state, a plugin should not call PDB procedures
which are themselves v2 script plugins,
or a few utility scripts in script-fu-util.scm,
but that is rarely needed.
Does not remove symbols TRUE and FALSE from dialect.
A script can also call (script-fu-use-v2) to revert.
That is also discouraged but useful e.g. for testing.
At script create time, create a GimpRGB i.e. pixel from the declared name of default color.
At plugin procedure registration time, convert that pixel to GeglColor,
and use that color to declare the color arg using GeglParamSpecColor(default=color)
Fixes a faulty fix a few commits back where we lost the declared color name.
The proper dataflow is name->color->paramspec-with-default-color.
Extract methods related to color into new file.
So method names document what is being done.
So related code is together.
Ditto for resource.
No functional change.
Preparing for changes to reset/default and changes to representation of pixels
in lists of differing lengths rgb vs rgba.
Fixes errors introduced by my prior commit c0ca0b74
1. SF is storing colors in GimpRGB, not GeglColor.
Storing using wrong pointer type seemed to work, but would not build on newer compilers.
2. spurious error message "CRITICAL....Two different plugins tried to register..."
Due to calling gimp_ui_init too early, in the class instance init.
Since PDB now traffics in GeglColor instead of GimpRGB.
Change GimpParamSpecRGB to GeglParamSpecColor when declaring args to procedure.
Declared default is temporarily "black".
Change conversion of gvalue to scheme representation, now from GeglColor.
Incidental change to interpreter to init gegl early,
since now needed during registration phase.
Right now, I just transform any GeglColor return value into a RGB u8 triplet,
because that's also how we were supporting GimpRGB anyway, though it's seriously
limited.
Ideally we'd add some real concept of generic color abstraction in Script-fu
too, which could support any color model, space and precision.
For the time being, only the same format as GimpRGB params is supported, which
means creating a color either as CSS strings or as RGBA list values, which means
that we can only input sRGB values right now in ScriptFu (even when calling
GeglColor-using API).
This is the second part to fix issue #10811.
The invasion extended to some core widgets too, in particular GimpColorPanel (a
subclass of GimpColorButton). There was quite a lot of code depending on these
widgets.
For version 3 scripts, using script-fu-register-filter
Widgets for SF-OPTION and SF-DIRNAME
Fixes#9992
Test case is Sphere v3.
Note that SF-VECTORS is still not supported,
until there is a VectorsChooser widget in libgimp.
A step towards deprecating old-style scripts using script-fu-register,
and deleting script-fu-interface, the duplicate dialog for SF.
But we still need to change or replace script-fu-register (for non-filter plugins)
to use GimpProcedureDialog.
Magic number 1 changed to 2 in one place. Missed in earlier fix for #10127.
Changed magic number to a defined macro constant so it might not happen again,
should GimpConfig change again.
Substantive change is call gimp_item_get_by_id instead of gimp_drawable...
And a few type changes from GimpDrawable* to GObject*.
Lots of renaming of functions, substituting "item" for "drawable."
Update comments.
Made one function static that was already private.
Fix the test case gimp_vectors_set_selected
Recently some extra input validation was added, which caused the
gimp-image-set-selected-layers command in script-fu to fail with an
invalid value for argument 2.
This is caused by the object array contents always being set as
GIMP_TYPE_DRAWABLE, while the actual type may be a layer, etc.
So, let's set the actual type of drawable being used here by using
G_OBJECT_TYPE on the first data element.
We remove two warnings:
1. warning: format '%ld' expects argument of type 'long int', but
argument 5 has type 'GType' {aka 'long long unsigned int'}
Since GType is gsize, and this is not used in translations, use format
specifier G_GSIZE_FORMAT.
2. warning: enumeration value 'SF_IMAGE' not handled in switch (and more
similar ones).
Add a default block to let the compiler know we handle all values.
I added a few specific validations for range types (int, double…), and a
generic validation at the end, meant to catch all yet uncaught invalid
argument cases (yet with less details on the what and why).
Changes only to ScriptFu.
The third term (the default) of a SF-FONT etc. spec is now ignored.
Test case is SF>Test>Sphere. There are still crashing issues
related but separate.
The gimp_procedure_run() already existed, though it was with an ordered
GimpValueArray array of arguments. Its usage feels redundant to the series of
gimp_pdb_run_procedure*() functions (which is confusing), but
gimp_procedure_run() was actually a bit more generic, because it does not
necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a
local GimpProcedure, such as the case of one procedure which would want to call
another procedure in the same plug-in, but without having to go through PDB. Of
course, for local code, you may as well run relevant functions directly, yet it
makes sense that if one of the redundant-looking function is removed, it should
be the more specific one. Also gimp_procedure_run() feels a lot simpler and
logical, API wise.
A main difference in usage is that now, plug-in developers have to first
explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when
they wish to call PDB procedures on the wire. This was done anyway in the
gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name
directly).
Concretely:
* gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and
gimp_pdb_run_procedure_valist() are removed.
* gimp_procedure_run() API is modified to use a variable args list instead of a
GimpValueArray.
* gimp_procedure_run_config() and gimp_procedure_run_valist() are added.
* gimp_procedure_run_config() in particular will be the one used in bindings
which don't have variable args support through a (rename-to
gimp_procedure_run) annotation.
As far as plug-in API is concerned, at least the calling API, order of arguments
when calling PDB procedures doesn't matter anymore.
Order still matters for creating procedures with standard arguments (for
instance, "run-mode" is first, then image, or file, drawables or whatnot,
depending on the subtype of procedure), but not for calling with libgimp.
Concretely in this commit:
- gimp_pdb_run_procedure_argv() was removed as it's intrinsically order-based.
- gimp_pdb_run_procedure() and gimp_pdb_run_procedure_valist() stay but their
semantic changes. Instead of an ordered list of (type, value) couple, it's now
an unordered list of (name, type, value) triplets. This way, you can also
ignore as many args as you want if you intend to keep them default. For
instance, say you have a procedure with 20 args and you only want to change
the last one and keep the 19 first with default values: while you used to have
to write down all 20 args annoyingly, now you can just list the only arg you
care about.
There are 2 important consequences here:
1. Calling PDB procedures becomes much more semantic, which means scripts with
PDB calls are simpler (smaller list of arguments) and easier to read (when
you had 5 int arguments in a row, you couldn't know what they refer to,
except by always checking the PDB source; now you'll have associated names,
such as "width", "height" and so on) hence maintain.
2. We will have the ability to add arguments and even order the new arguments in
middle of existing arguments without breaking compatibility. The only thing
which will matter will be that default values of new arguments will have to
behave like when the arg didn't exist. This way, existing scripts will not be
broken. This will avoid us having to always create variants of PDB procedure
(like original "file-bla-save", then variant "file-bla-save-2" and so on)
each time we add arguments.
Note: gimp_pdb_run_procedure_array() was not removed yet because it's currently
used by the PDB. To be followed.
This goes with our planned change of not making GimpProcedure arguments order
relevant anymore regarding the PDB API. In particular, it means we don't want to
use GimpValueArray for various procedure arguments API, but directly
GimpProcedureConfig objects.
This change will allow to add or reorder arguments in the future, so that we
won't have to create new PDB procedures when adding new arguments, while still
keeping PDB API stability.
Improper counting of args declared by scripts versus pspecs in a ProcedureConfig.
Scripts don't declare run_mode, while pspecs have run_mode and an extra internal pspec
that is not an argument.
bootchk had the case in commit 6781a35668. I again had it with gfig. I think it
just makes sense to init GEGL, especially as the errors are not that explicit
and that the plug-in code may not even call GEGL code directly (so it makes it
harder to guess).
This name was really irking me because it's not a button (anymore? Maybe it used
to be just a button). Depending on the specific widget, it will have several
sub-widgets, including a label. And it can theoretically even be something else
than a button.
So let's just rename these widgets with the more generic "chooser" name.
- Move the property widget functions for GimpResource properties into a new
libgimp/gimppropwidgets.[ch] file. This mirrors the files
libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types.
- Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new().
- gimp_prop_chooser_factory() doesn't need to be public.
- Add a label to GimpResourceSelectButton, make so that the
gimp_prop_chooser_*_new() functions set the property nick to this label and
add this label to the size group in GimpProcedureDialog.
- Removing useless or redundant code.
- Simplifying various logics.
- Using GimpResource directly in temporary PDB procedures, not resource names.
- Better cleanup of the core resource chooser when the plug-in dialog quits (we
need it to ask core to close also any visible resource chooser dialog).
- Replace the "Close" button by more common OK/Cancel. In particular, the
GimpPdbDialog now properly keeps track of the initial object and when hitting
"Cancel" (or Escape key), this initial object is set back.
- Clean up some of the comments, especially when the code is self explanatory.
There is still much more to clean and improve, but it's a first welcome step.
Also in gimp_procedure_config_begin_run(), make sure we sync the arguments with
the config object first thing, even in interactive and with-last-vals case
(where the args may be further overridden). This was especially important for
Script-fu scripts as the image and drawable were not provided separately, so we
need to make sure that the config file has the right values.
Also refactoring: extract two functions
Add test case scripts/test/register-fail
Catches more registration errors.
Any errors not caught at least will not crash.
Remains to be ported to 2.10, but only a few lines, without the refactoring.
This is not the main reason for the specific output in #9994. These ones are
more probably because of similar usage in GTK (which updated its own calls to
g_file_info_get_is_hidden|backup() in version 3.24.38). But we should likely
also update the various calls we have to use the generic
g_file_info_get_attribute_*() variants.
To be fair, it is unclear to me when we can be sure that an attribute is set.
For instance, when we call g_file_enumerate_children() or g_file_query_info()
with specific attributes, docs say that it is still possible for these
attributes to not be set. So I assume it means we should never use direct
accessor functions.
The only exception is that I didn't remove usage of g_file_info_get_name(),
since its docs says:
> * Gets a display name for a file. This is guaranteed to always be set.
Even though it also says just after:
> * It is an error to call this if the #GFileInfo does not contain
> * %G_FILE_ATTRIBUTE_STANDARD_DISPLAY_NAME.
Which is very contradictory. But assuming that this error warning was
over-zealous documentation, I kept the direct accessors since they are supposed
to be slightly more optimized (still according to in-code documentation) so
let's priorize them when we know they are set for sure.
This commit and the ones prior are simple refactoring,
with no intended functional changes.
In anticipation of enhancements 9608 and 8404
which make returned values more scheme like.
Also makes code more readable.
For characters outside ASCII:
1. repr is wrong in REPL
2. sharp constant #\<codepoint> fails to evaluate
3. sharp constant hex #\x<hexdigits> accepts invalid UTF-8 codepoints
4. a call to error with such a character eats the output string
Also, changed the repr of ASCII control characters (was #\x7)
to their unicode repr (now a box glyph with hex)
Test framework and tests in Scheme, and portable.
Work in progress. Expect commits for more tests.
Testing framework is stable, more or less.
Add more tests
Add tests layer and layerMask.
test Item methods
More tests, selection
Test memory, vector in TS.
More tests char functions
sharp expr tests
This removes a bunch of inconsistencies we had from the before-2.99.16 version
because new items from plug-ins were all added at the bottom of their respective
submenu.
I noticed this in coverity. I couldn't find any actual script using
SF_DISPLAY, so the impact probably isn't very big.
Because the enums start at 0, the size of the array should be at least
one more than the value of the last enum, which was not the case here.
Increase the size of the array by 1, so that accessing SF_DISPLAY,
which is the enum with the highest value, is valid.
The order of GIMP_PROCEDURE_SENSITIVE_DRAWABLE |
GIMP_PROCEDURE_SENSITIVE_DRAWABLES was reversed in
gimp_procedure_set_sensitivity_mask (), which caused scripts using
SF_ONE_OR_MORE_DRAWABLE to crash.
