Since libgimpui also use GIMP_ as prefix in C, we won't ever have name
clashing with libgimp, so I also remove this prefix in Script-Fu.
E.g. GIMP_ASPECT_SQUARE is ASPECT-SQUARE in Script-Fu.
The code was mistakenly calling gimp_ui_init to init gegl,
and then gtk_init was aborting in headless gimp-console.
Now require GimpPlugin class to init gegl/babl.
See next commit.
Call gimp_ui_init only when run mode INTERACTIVE.
When interacting with a layer/channel
widget in a plug-in GUI, a temporary
procedure is spawned. Script-fu plug-ins
run a check for translation whenever a new
procedure is run, but there's none available
for "temp-procedure-number-?" which is
spawned by the layer/channel pop-up.
This causes a crash because
script_fu_script_get_i18n () assumes the
script object it receives is always valid.
This patch adds a g_return_if_fail () call
to script_fu_script_get_i18n () to prevent
future crashes, and makes sure the script
object is not NULL after
script_fu_find_script () is called in
script_fu_get_i18n_for_proc () to prevent
the initial call for temporary procedures.
GIMP 3.0 enforces stricter parameter range checks
compared to GIMP 2.10. As a result, scripts that are the
right datatype but go outside the parameter range will
fail. In GimpProcedure, we have checks if a no-validate
flag is set to bypass these constraints.
This patch adds those checks to Script-fu so it also knows
to not check ranges if no-validate is set.
While all other resources are supposed to be already loaded, this is not
the case of fonts which are loaded in a thread, and whose loading may
end after plug-ins are initialized. So ignore unknown font name as an
exception (because we can't know if it is really unknown or just not
loaded yet).
This fixes such WARNINGs:
> (script-fu:33006): scriptfu-WARNING **: 14:35:28.259: script_fu_add_resource_arg declared resource name is invalid Serif
In particular, we want the new Script-Fu plug-in to be able to handle
their progress status themselves, which is possible with
(gimp-progress-set-text) except that it is far too quickly overriden
because each procedure call generates a new progress message.
I hesitated to make (gimp-pdb-proc-exists) public but I don't think it's
a good idea as it would be redundant with gimp_pdb_procedure_exists() in
the C API.
Instead, just implement (gimp-pdb-procedure-exists) specifically for
Script-Fu, with a name mapped to the C function.
… gimp_procedure_is_internal().
I realized we were already naming these "internal procedures" in the
Procedure Browser and this is in fact a better naming than "core
procedure".
First of all, let's init with the main procedure label (stripped of
leading/traling spaces, of mnemonic underscore and of ellipsis) as
progress status for gimp_progress_init().
Then reuse this main label for all subsequent progress updates by the
same top procedure.
Finally "pulse" the progress at each update to make it more like
progression actually happens.
This is a first experiment to see if not having progress API in
Script-Fu is fine (#12948), by having better progression defaults.
Since the move of GimpUnit from some weird int/enum mixed type into a
proper object type, this was not usable anymore in Script-Fu.
Functions like (gimp-text-layer-new) were therefore broken. It now works
again.
Cleanup cruft, unused files.
script-fu/scripts/init/init.scm
is the only copy that GIMP uses.
It is more or less upstream TinyScheme init.scm v1.42,
that K. Cozens occasionally patches with upstream changes.
But upstream has been at 1.42 for several years.
/scripts/script-fu.init is an unused copy of upstream TinyScheme init.scm v1.40
It should have been deleted on the earlier commit
that moved the file in the repo to /scripts/init/init.scm
and the installed init files to /scripts/scriptfu-init.
/tinyscheme/init.scm is an unused copy of upstream TinySche init.scm 1.41
Deleting it means that the tinyscheme dir can no longer be built by itself
into TinyScheme standalone binary, but we don't support that anyway.
The array of strings representing the Scheme types wasn't updated
after adding named parameters. This caused a crash when trying to
use named parameters where that isn't possible.
This new widget is much nicer, with proper label to document the GUI and
also with support to save files or create folders. It also has mnemonic
support and the label is put into the same size group as other so that
it's nicely aligned.
As a consequence, I remove bad support of object arguments with a GFile
value. People should just create proper GimpParamSpecFile arguments
(also GimpProcedure API now has a function only for such type of file
argument).
I also remove gimp_procedure_dialog_get_file_chooser() which was only
useful when we didn't know what action a file argument was for. Now it's
part of the param spec definition.
libscriptfu was updated too because SF-DIRNAME arguments don't need
special casing anymore.
Finally I change gradients-save-as-css to just make use of the new
automatic widget creation (more than 60 lines of plug-in code replaced
by… 0 lines because it's automatic!).
This whole commit is mostly a lot of code removal now that we have
proper automatization for file arguments! \o/
libgimpbase:
- Mew GimpFileChooserAction enum type: basically a near-mapping of
GtkFileChooserAction (GTK is not accessible from libgimpbase) with
an added GIMP_FILE_CHOOSER_ACTION_ANY.
- New GimpParamSpecFile param spec type: based off
GimpParamSpecObject, it has a default value, but also a none_ok and
action argument. This way, we can also know from the argument type
if this is a file argument meant for selecting a normal file or a
folder, or for saving into a file, or for creating a directory.
libgimp, plug-ins:
- All existing file arguments (until now using a standard
GParamSpecObject param with GFile value type) were moved to the new
GimpParamSpecFile.
- Script-Fu in particular will now generate the appropriate param type
depending on whether it is an SF-FILENAME or SF-DIRNAME.
- File arguments are now stored between runs as a URI rather than as a
path. As far as I can tell, a GFile always has a URI, but not always
a path (in particular remote file won't have a path).
After the few specific args (drawable/filter ID, opacity, blend mode, op
name…), the op argument names can be passed either as string or with the
new argument name syntax. The error message though focus on argument
name type.
Also fix the argument count for the various possible cases (when
configuring with (gimp-drawable-filter-configure) or
(gimp-drawable-merge|append-new-filter), the start arg count is
different).
This syntax is now the official syntax for non-core PDB procedures.
I.e. that while core procedures will still use ordered arguments (e.g.:
`(gimp-image-get-layers 1)`), plug-in PDB procedures called from
Script-Fu will have named arguments in any order.
Say for instance that you want to call python-fu-foggify from Script-Fu.
Whereas we used to run:
> (python-fu-foggify RUN-NONINTERACTIVE 1 (car (gimp-image-get-layers 1)) "Clouds" '(50 4 4) 1.0 50.0)
Now we should call:
> (python-fu-foggify #:image 1 #:drawables (car (gimp-image-get-layers 1)) #:opacity 50.0 #:color '(50 4 4))
Now we can note:
* Every argument is preceded by a #:label which is the argument name.
This makes these calls much more readable (some plug-in procedures can
have dozen of arguments and these end up as list of integers, floats
and strings, which are hard to read and hard to debug) and semantic.
* Order doesn't matter anymore. For instance here, I put #:opacity
before #:color.
* As a direct consequence, we can drop any argument which we wish to
keep with default value. E.g. in the old style, we had to put the
#:run-mode, #:name ("Clouds") and #:turbulence (1.0) because we were
changing the last argument #:opacity (50.0). Now we can drop all 3
default arguments.
Having non-ordered argument is in fact the starter of this feature,
because it is already the case for calling PDB procedures in the libgimp
API (and therefore in all GIR bindings). By saying that the order of PDB
procedures is not part of the API, we actually allow to add arguments
and even to reorder them in the future without breaking existing scripts
in the 3.0 series.
This became even more serious when I was considering to make the generic
metadata arguments public. Since they are appended to the end, after all
plug-in-specific arguments, if I do this, adding any argument in an
export plug-in would break order. It won't matter anymore!
Note that it doesn't matter for core PDB procedures (where this syntax
is not used) because these are also C functions and therefore order and
number of arguments matter anyway. Also these don't have dozens of
arguments.
As a helper for Script-Fu developer, in particular as we already
released 2 RCs and therefore some people already started to port their
scripts, the old syntax will still work yet will produce a warning
showing how to call the same thing with the new syntax. For instance,
with the above first call, the warning will be:
> (script-fu:2059912): scriptfu-WARNING **: 22:54:47.507: Calling Plug-In PDB procedures with arguments as an ordered list is deprecated.
> Please use named arguments: (python-fu-foggify #:run-mode 1 #:image 1 #:drawables (2) #:name "Clouds" #:color '(50 4 4) #:turbulence 1.000000 #:opacity 50.000000)
Note that the argument name syntax is coming from the Racket scheme
variant: https://docs.racket-lang.org/arguments/index.html
Common Lisp has a similar syntax, either with just a colon, or also a
sharp + colon (it's unclear to me the difference, something about
interned vs. uninterned symbols).
After discussion with Liam on IRC, we decided to go with the #: syntax
of Racket.
We validate arguments for a reason. This special flag must only be used
in special cases (when it's harder/not possible or not implemented yet
to validate properly).
In fact #12039 would have been much simpler to diagnose and debug if
this flag had not been there from the start, because we would have had
an error earlier, on core side, which we could have traced back much
more simply!
In particular (gimp-drawable-filter-configure),
(gimp-drawable-merge-filter) and (gimp-drawable-append-filter) are
proper Script-fu methods.
I had to rename the PDB procedures for the 2 latter because they were
clashing with these wrapper. I had not realized that private PDB
procedures are still visible by Script-fu. This is not so glop. :-/
Right now, it doesn't look so useful compared to the -new- one-liner
variant procedures. But it will make sense when I will add aux input C
procedure wrappers.
Marshalled PDB procedures into script-fu can now convert a filter ID
into the proper object. For instance, here would be the code to append a
new gaussian blur filter to the drawable with ID 2 (with specific
settings), then making invisible:
```script-fu
(define filter (gimp-drawable-append-new-filter 2 "gegl:gaussian-blur" "hello" LAYER-MODE-COLOR-ERASE 1.0 "std-dev-x" 20 "abyss-policy" "none"))
(gimp-drawable-filter-set-visible filter FALSE)
(gimp-drawable-update 2 0 0 -1 -1)
```
I moved the code to transform scheme values into GValues depending on a
GParamSpec out of script_fu_marshal_procedure_call() into a shared
function script_fu_marshal_arg_to_value().
Makes the Dock icon only appear when a script plugin has a dialog.
Unfortunately, on MacOS where "transient for" doesn't work,
we need a Dock icon for the separate process so user can "Show window."
See #12150
Done at runtime.
A build-time alternative is: package script-fu binary in a bundle, and set properties.
Fixes both the new-style dialog (GimpProcedureDialog) and the old-style dialog (deprecated.)
The gimp app and extension-script-fu (long-running)
are separate processes and "apps."
An app can be "active": in front and receiving GUI events.
As reported, on MacOS, when an extension-script-fu plugin yields,
the gimp app did not become active.
Also, on the second invocation of a plugin served by extension-script-fu,
the dialog could be hidden or require an extra click
because extension-script-fu was not active.
(Independently interpreted plugins did become active,
because it was a new process and gimpui_init activates on MacOS.)
On MacOS:
1. after the first dialog shown by extension-script-fu,
ensure subsequent calls to plugin make extension-script-fu active.
2. After a plugin yields, plugin manager ensure the Gimp app is active.
Note that this is done whenever a TEMPORARY procedure returns.
Most are calls to extension-script-fu plugins.
But some are also callbacks from Resource choosers running in the gimp app.
When they return, the gimp app remains active, and user must first click in
the plugin dialog to continue working.
Especially when the user clicks OK in a Resource Chooser, closing the chooser,
it would be nice if the plugin dialog became active.
That requires more, FUTURE development.
Special to MacOS: on Linux, "transient for foreign window" ensures this,
but that doesn't work on MacOS.
The fix is somewhat brute force and as simple as possible.
There is a more cooperative API for app activation on MacOS.
An app yields, and apps request, not force, self or other app be activated.
The fix does not use the cooperative API.
To do so would require a platform abstraction layer, in GIMP or Gtk.
The fix also sprinkles the code with #ifdefs.
That could be hidden if there were a platform abstraction layer PAL
The layer would be the greatest common denominator across platforms.
PAL methods would always be called in GIMP code,
but not do anything when the effect was accomplished another way.
For example "gimp_platform_request_app_active"
would request the app was active,
but do nothing on Linux where that is ensured by "transient for."
It is like a compiler warning, and should not be a full g_warning,
which should mean something will probably fail.
Passing fewer args is a feature since 3.0: the PDB will use defaults.
Elide the underscore char from the blurb of the GParamSpec.
The tooltip remains redundant with the menu label.
We can't use an empty string (omit the tooltip)
because the blurb is also the description in the PDB Browser,
and the generated name of the arg is not descriptive.
FUTURE: let script author also declare a tooltip,
and a non-generated but unique name of the arg.
Several types functions were using the wording "float" historically to
mean double-precision, e.g. the float array type (which was in fact a
double array). Or the scanner function gimp_scanner_parse_float() was in
fact returning a double value. What if we wanted someday to actually add
float (usually this naming means in C the single-precision IEEE 754
floating point representation) support? How would we name this?
Now technically it's not entirely wrong (a double is still a floating
point). So I've been wondering if that is because maybe we never planned
to have float and double precision may be good enough for all usage in a
plug-in API (which doesn't have to be as generic so the higher precision
is enough)? But how can we be sure? Also we already had some functions
using the wording double (e.g. gimp_procedure_add_double_argument()), so
let's just go the safe route and use the accurate wording.
The additional change in PDB is internal, but there too, I was also
finding very confusing that we were naming double-precision float as
'float' type. So I took the opportunity to update this. It doesn't
change any signature.
In fact the whole commit doesn't change any type or code logic, only
naming, except for one bug fix in the middle which I encountered while
renaming: in gimp_scanner_parse_deprecated_color(), I discovered a
hidden bug in scanning (color-hsv*) values, which was mistakenly using a
double type for an array of float.
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.
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.
