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).
It isn't being used by any plug-in or any code in GIMP at all even.
Let's get rid of it while we can still break API, so we can cut down on
all the complexity of the gimp-param stuff a bit.
Renaming the temporary function gimp_scale_entry_new2() into
gimp_scale_entry_new() now that the original code is entirely gone. This
is now a fully-fledged widget with a nice and proper introspectable API.
Just "Console" is enough in the context of menus with submenu hierarchy,
but when accessing directly the feature (with Action Search for
instance), a more accurate name is nicer. It avoids to have to check
what is what in the tooltip text.
This gives a big cleanup in the meson.build files of the plug-ins.
It's also quite a bit more maintainable, since anything that changes in
libgimp's dependencies, linkage, ... doesn't have to be copy-pasted into
each plug-in.
1 > warning: "_WIN32_WINNT" redefined
2 > pointer targets in passing argument 2 of 'send' differ in signedness
3 > passing argument 4 of 'setsockopt' from incompatible pointer type
For the signedness/type issues, I just casted to (void *) which was the
expected type for these parameter on the Linux API anyway. As for
Windows API (which was expecting char* for these various API), the
compiler just does the cast itself from void* without complaining
anymore.
On Windows, accept() wants an int for addrlen but on Linux, it wants a
socklen_t which is an unsigned int. So we can't just switch to gint as
proposed in !232 (if we do so, the signedness warning now happens on the
Linux build instead of the Windows one).
Fortunately it looks like socklen_t is actually typedef-ed to int in
Windows headers. So let's just use this type, which is much more proper
anyway as this variable is only used in functions which want this type
on Linux.
Fixes:
> warning: pointer targets in passing argument 3 of 'accept' differ in signedness
Variable ai and ai_curr going out of scope at line 496.
Variable ai going out of scope at line 545.
Revealed by Coverity Scan.
(cherry picked from commit 1ce1b0eebe)
