Commit a6aba929 deleted the old functions.
Misc drive-by fixes for gtk_adjustment step not < pages
Issue #8155 discusses alternative fixes, convenience functions for compatibility in ScriptFu.
There is one compat function defined already in ScriptFu, temporarily: gimp-image-get-active-drawable
which was written so that testing clothify-v3.scm could proceed.
Resolves#8382
Also v2 scripts infer and set sensitivity to drawables
Add two test plugins clothify-v3.scm and test-sphere-v3.scm.
Temporary, to be removed when 3.0 ships.
Some refactoring (extracting methods, moving functions to new files).
Some drive-by fixes to script-fu-arg.c revealed by using GimpProcedureDialog.
This is the consequence of previous commit. Plug-ins' label and
documentation are now localized before sending these data to GIMP core.
In other words, we replace N_() macros with basic gettext calls.
Why: puts most methods for SFArg (a struct) in one place, for ease of maintenance.
Prepares to fix issue 8328. Prepares to make SF use GimpProcedureDialog.
Mostly moving code, with no intended change in functionality,
except fixed an property.nick for an arg is now what a script author provided,
instead of generated.
All internal to libscriptfu. No changes to the exported API or to i18n.
Lightly tested, since more substantive changes coming for issue 8328.
ScriptFu>Test>Sphere is the test case.
Why:
1) users can install .scm scripts to plug-ins dir
2) Crashing scripts do not crash extension-script-fu
Scripts (.scm files) have a shebang and are executable
and in a same-named subdir of plugin dir.
Interpreter/scripts create PDB procs of type PLUGIN unlike extension-script-fu
which creates PDB procs of type TEMPORARY, owned by extension-script-fu.
Unlike other interpreters, the interpreter is-a plugin outright,
not by virtue of the script subclassing GimpPlugin and using GI.
More details in /plug-ins/script-fu/interpreter/README
Create new plugin file script-fu-server-plugin.c
with code extracted from script-fu.c, which is an omnibus plugin
implementing PDB proc extension-script-fu and other PDB procs.
Why:
1. extension-script-fu is smaller and doesn't doesn't link to socket libraries.
(GIMP always starts extension-script-fu and it stays running.)
2. packagers/admins can omit script-fu-server executable from an installation,
if they think letting users serve net ports is not secure.
3. crashing script-fu-server does not crash extension-script-fu,
which requires restart of GIMP
The changes are mostly a simple refactor, extracting code.
No functional change apparent to users.
Low risk of introduced bugs.
Extremely few users use script-fu-server anyway.
Added some logging.
While at it, use G_DECLARE_FINAL_TYPE
Changes are mostly to the dir structures and build system for ScriptFu.
Some changes to the outer plugin source to call the library.
Why: so that other executables (future gimp-scheme-interpreter,
or a future separated script-fu-server) can exist in separate directories,
and share the library in memory (when built shared.)
Whether the library is built shared and installed on its own
(versus static and not installed)
is a compile time option (both automake LibTool and meson abstract it away)
The default is shared and installed, say as libgimp-scriptfu-3.0.so.
Installed alongside other shared libraries (e.g. wherever libgimp is installed)
to simplify packaging.
A preliminary refactoring which helps enable MR gimp!647
Hence avoiding the stderr messages. These are going to be localized with
centrally installed catalogs "gimp*-std-plugins", "gimp*-script-fu" and
"gimp*-python".
We now handle core plug-in localizations differently and in particular,
with kind of a reverse logic:
- We don't consider "gimp*-std-plugins" to be the default catalog
anymore. It made sense in the old world where we would consider the
core plug-ins to be the most important and numerous ones. But we want
to push a world where people are even more encouraged to develop their
own plug-ins. These won't use the standard catalog anymore (because
there are nearly no reasons that the strings are the same, it's only a
confusing logic). So let's explicitly set the standard catalogs with
DEFINE_STD_SET_I18N macro (which maps to a different catalog for
script-fu plug-ins).
- Doing something similar for Python plug-ins which have again their own
catalog.
- Getting rid of the INIT_I18N macro since now all the locale domain
binding is done automatically by libgimp when using the set_i18n()
method infrastructure.
Also fixed quotient to only take two arguments. Applied minor
optimization in execution of quotient, remainder, and modulo.
From revision 122 of the TinyScheme repository in SourceForge.
Instead, make outer script-fu-server register callbacks with inner scheme-wrapper.
Why? the inner scheme-wrapper should not know about the outer script-fu-server.
The change will allow a future, smaller scriptfu shared library,
that does not contain networking code.
We want a scriptfu library shared by separate script-fu-server,
future gimp-scheme-interpreter (!647), and script-fu executables.
This change does not alter observable functioning of the script-fu-server.
Except that I also changing the logging by script-fu-server,
so that I could test the changes.
I put a test plan in the comments.
Removal of the snprintf define was also part of the UCRT Windows patch
in MINGW. Although it builds fine without this change, there is no need
anymore to redefine snprintf. In addition, I seem to remember that
_snprintf had a shortcoming.
So let's remove the Windows specific code, since it works fine without it.
Why: MR !389 changed the signature of PDB procedures to return GStrv instead of (int, GimpStringArray)
This changes handling of results from a call to such a changed signature, in a Scheme script.
The symptom was a cryptic TinyScheme "Error: car: argument 1 must be : pair"
Most changed procedures are named like "-list".
I did a cursory grep to look for other instances.
Updated porting guide doc.
Why: in v3 the signature for gimp-edit-foo PDB procedures changed to support multilayer selection.
This finishes the task for ScriptFu scripts in the GIMP repo.
This is not a complete list, since some calls were changed incidentally by prior commits.
You can grep for "edit-copy" etc. in script-fu/scripts to find instances.
This also makes incidental changes, to script calls to plug-in-tile,
which now also has a changed signature to support multilayer.
The changes are simple code transformations.
The changes to gimp-edit-paste calls are more complex,
a mixed bag of a few lines transformed to more lines.
I did not try to understand the larger logic of the changed plugins.
I did not test the changed plugins functionally.
I used a harness to call each changed plugin with improvised parameters,
only checking that the test plugin did not throw runtime errors,
not checking that they produced correct images.
As noted in the issue, this might be undone if the original signatures
for gimp-edit-foo are restored as convenience functions.
Why: this commit fixes PATTERN using code that commit 708f3228 fixed for BRUSH.
Importance:
There doesn't seem to be any issues it resolves.
No code in the GIMP repo seems to call this procedure.
I don't know whether third party plug-ins rely on this procedure.
Anyway, fix it so a brute force test works.
This change is part of multilayer select feature of v3.
Only fixes ScriptFu plugins, not Python or C.
Only fixes calls to file load/save procedures and other plugins already multilayer capable.
Any future PDB procedures changed to have multilayer signature will require changes to all callers.
The new code is verbose: "drawable" => "1 (vector drawable)"
Issue 5919 proposes a change to the PDB that would make this less verbose:
"drawable" => (vector drawable)" (without the number of drawables)
Tested that changed procedures will interpret without syntax errors, on one path.
Did not test each changed procedure for functional correctness.
… plug-in code.
In particular, we should not hardcode this in core code anymore. The
behavior is otherwise exactly the same, except that we made the core
code generic as it should be.
The CLI options now know which procedures are batch procedures or not.
First it means that it won't just randomly try any procedure name one
may pass and will properly output an error if you pass a non-existing
interpreter procedure.
Secondly, there is no default interpreter anymore (unless only one
interpreter exists). If you don't set an interpreter procedure with
--batch-interpreter or if you pass a wrong one, it will output the list
of available batch procedure, thus helping you understanding how to use
the --batch option.
GLib has a specific type of NULL-terminated string arrays:
`G_TYPE_STRV`, which is the `GType` of `char**` aka `GStrv`.
By using this type, we can avoid having a `GimpStringArray` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GStrv`, we allow other languages to pass on string lists as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with string arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
It was calling plug-in-gradmap with old single-layer API hence failing.
Also replacing all calls to (gimp-image-set-active-layer) and
(gimp-image-get-active-layer) in this file with
(gimp-image-set-selected-layers) and (gimp-image-get-selected-layers)
respectively.
The round corners script was assuming that the drawable always
was a layer, which is incorrect when a layer mask is selected.
We fix this by always requesting the active layer instead of
active drawable.
We also enable this script for RGB and GRAY with alpha
channel. Although it might not always make sense to
use this script when an alpha channel is present, there
can be use cases where it is perfectly fine.
So let the designer decide if this script is suited or not
instead of GIMP making that judgement.
This fixes the following error when building for Windows:
> error: too many arguments to function ‘mkdir’
On Windows, mkdir() is deprecated, it is an alias for _mkdir() which
doesn't have a mode parameter. The GLib version duplicates the POSIX
signature and is cross-platform (mode is simply ignored on Windows).
Closes: GNOME/gimp#541
Reviewer note: thanks to Stanislav Grinkov for cleaning up and reworking
a bit the patch, such as renaming the procedure to dir-make, as per
Kevin Cozens' review.
Fixes:
> Calling error for procedure 'gimp-brush-get-pixels':
> Brush 'Circle (03)' not found
The data/brushes/Circle-3.vbr brush doesn't exist since commit
7aa12175a4 in 2012 as far as I can see.
Since we renamed a bunch of functions for consistency (the like of
gimp_image_width() to gimp_image_get_width() and others), most Scheme
scripts ended up broken. This is a simple bash fix with `sed` to at
least take care of these simple renaming cases.
Many scripts are still broken for other reasons after our API evolution
(to be continued).
lloyd konneker