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.
Much like for images and items. Change the PDB to transmit IDs
instead of names for brush, pattern etc. and refactor a whole
lot of libgimp code to deal with it.
modified: libgimp/gimpplugin-private.h
This allows our script-fu plugins to use the GIMP enum values, just like
all our other plug-ins know them.
In other words:
* Names are consistent with those of other plug-ins
* Introspectable enums are automatically added as they are added to the
introspection file, without even needing a recompile
* No need to keep track of our enum types anymore, as that is just a
redundant implementation of introspection in practice. This in turn
will let us simplify some of the pdb code
GLib has a specific type for byte arrays: `GBytes` (and it's underlying
GType `G_TYPE_BYTES`).
By using this type, we can avoid having a `GimpUint8Array` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GBytes`, we allow other languages to pass on byte arrays 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 byte 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
Simplifies chooser widgets (e.g. GimpBrushSelect) by eliminating attributes (e.g. opacity) of chosen resource.
See #8745, but this commit fixes that by first refactoring the code.
Refactors GUI widgets (e.g. GimpBrushSelectButton and GimpBrushSelect etc.)
Refactor by "Extract class" GimpResourceSelectButton from GimpBrushSelectButton etc.
This moves common code into an inherited class (formerly called GimpSelectButton)
but the subclasses still exist.
The subclasses mainly just do drawing now.
Refactor by "Extract module" GimpResourceSelect from GimpBrushSelect etc.
Moves common code into one file, generic at runtime on type of GimpResource,
that is, the new code dispatches on type i.e. switch statements.
In the future, when core is changed some of that can be deleted.
The files gimpbrushselect.[c,h] etc. are deleted.
The module adapts the API from core to the API of callbacks to libgimp.
Note that core is running the resource chooser (select) widgets remotely.
Core is still calling back over the wire via PDB with more attributes
than necessary.
The new design gets the attributes from the resource themselves,
instead of receiving them from core callback.
The libgimp side adapts by discarding unneeded attributes.
In the future, core (running choosers for plugins) can be simplified also.
Fix gimp_prop_chooser_brush_new same as other resources.
Finish changes, and clean style.
Annotations
So procedures can declare args and GimpProcedureDialog show chooser
widgets
Fix so is no error dialog on id_is_valid for resources
Palette.pdb changes and testing
Memory mgt changes
Gradient pdb
Font and Pattern tests
Test brush, palette
Cleanup, remove generator
Rebase, edit docs, install test-dialog.py
Whitespace, and fix failed distcheck
Fix some clang-format, fix fail distcheck
Fix distcheck
Cleanup from review Jehan
Add a new type 'byte' to be able to handle binary data while still
retaining the utf8 char and string behavior.
Internally the file and string port and character handling have
been reworked to use the new byte-centric functions.
Also adds a new test script (test9) that tests byte, char and
utf8 string handling.
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.
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
