Pass the help-id specified by the procedure to the core, and use it in
the core if set instead of always using the procedure's name (which
was probably good enough for all eternity, but it's still more
consistent this way).
This partly reverts commit d999248d70.
The GimpStringArray is still very weirdly handled, in particular
regarding the difference of processing with static_data set or not.
Still this g_return_val_if_fail() was making more problems. It may come
back but will need more coding to handle the side effects.
Our GimpStringArray is so weird. We are obviously expecting it to be
NULL-terminated since, when we duplicate the data, we add one value.
Yet we were not checking that the stored data was NULL-terminated, in
particular when the string array is created with static data (in which
case, we use the input data as-is, without re-allocating).
Note that this doesn't fix the type mismatch Gimp.StringArray vs
Gimp.Array when introspecting.
Documentation-wise in C, this doesn't matter a lot, but it allows
GObject-Introspection based bindings to use their built-in versions when
they want to render any kind of documentation (for example, docs for
Python plugins can render `%NULL` as `None`).
Basically the number of parameters comes from plug-ins which could write
whatever crap on the wire. I had a case (playing with Python plug-ins)
where GIMP tried to allocate insane amount of parameters. This is bad
as it allows third-party plug-ins to crash GIMP core.
Instead only *try* to allocate, then return as though there were no
parameters if allocation fails. I also print some info on stderr, but
don't output WARNING/CRITICAL (this is not a core error, but a plug-in
error). Fixes:
> GLib-ERROR **: 16:30:23.357: gmem.c:135: failed to allocate 187186442160 bytes
which means that it's now included normally via gimpbase.h
and not any longer via gimpbasetypes.h which we only did out
of lazyness. A *lot* of files in libgimp* and app/ now need to
and _new_from_types_valist()
which take a va_list of GTypes and creates a GimpValueArray
initialized with these types, so one can simply have a list of
g_value_set_foo (gimp_value_array_index (array, i), foo);
in the next lines. I'm not so sure this is the best API ever...
- libgimpbase: change GPParam to transfer all information about the
GValues we use, in the same way done for GPParamDef. GPParam is now
different from GimpParam from libgimp, pointers can't be casted any
longer. The protocol is now completely GimpPDBArgType-free. Remove
gp_params_destroy() from the public API.
- libgimp: add API to convert between an array of GPParams and
GimpValueArray, the latter is now the new official API for dealing
with procedure arguments and return values, GimpParam is cruft (the
wire now talks with GimpPlugIn more directly than with the members
of GimpPlugInInfo, which need additional compat conversions).
- libgimp, app: rename gimpgpparamspecs.[ch] to simply
gimpgpparams.[ch] which is also more accurate because they now
contain GValue functions too. The code that used to live in
app/plug-in/plug-in-params.h is now completely in libgimp.
- app: contains no protocol compat code any longer, the only place
that uses GimpPDBArgType is the PDB query procedure implementation,
which also needs to change.
- app: change some forgotten int32 run-modes to enums.
- Change the wire protocol's GPProcInstall to transmit the entire
information needed for constructing all GParamSpecs we use, don't
use GimpPDBArgType in GPProcInstall but an enum private to the wire
protocol plus the GParamSpec's GType name. Bump the wire protocol
version.
- Add gimpgpparamspecs.[ch] in both app/plug-in/ and libgimp/ which
take care of converting between GPParamDef and GParamSpec. They
share code as far as possible.
- Change pluginrc writing and parsing to re-use GPParamDef and the
utility functions from gimpgpparamspecs.
- Remove gimp_pdb_compat_param_spec() from app/pdb/gimp-pdb-compat.[ch],
the entire core uses proper GParamSpecs from the wire protocol now,
the whole file will follow down the drain once we use a GValue
representation on the wire too.
- In gimp_plug_in_handle_proc_install(), change the "run-mode"
parameter to a GParamSpecEnum(GIMP_TYPE_RUN_MODE) (if it is not
already an enum). and change all places in app/ to treat it as an
enum value.
- plug-ins: fix cml-explorer to register correctly, a typo in
"run-mode" was never noticed until now.
- Add gimpgpcompat.[ch] in libgimp to deal with all the transforms
between old-style wire communication and using GParamSpec and
GValue, it contains some functions that are subject to change or
even removal in the next steps.
- Change the libgimp GimpProcedure and GimpPlugIn in many ways to be
able to actually install procedures the new way.
- plug-ins: change goat-exercise to completely use the new GimpPlugIn
and GimpProcedure API, look here to see how plug-ins will look in
the future, of course subject to change until this is finished.
- Next: changing GPParam to transmit all information about a GValue.
all the stuff from app/core/gimpparamspecs.[ch] that is not about
image, drawable etc IDs, these will have to go to libgimp with
different implementations than in app/.
At first I thought these could be different namespaces, but actually
GObject Introspection parses files and can only use (AFAICS) the
namespace actually used in our C function, which is always `gimp_` (and
not `gimpbase_` or whatever.
So make the introspection at the root level, and it will include all
libgimp* libraries in one namespace, same as the C lib anyway. For now
only libgimp and libgimpbase as I am still testing.
Also I move the introspectable sources in their own file in order to
share the list between the library building Makefile and the GI
makefile because I can't find how to pass over variables otherwise.
So far only libgimpbase is introspected. It just works though (I could
test that I could just run a plug-in which could access libgimpbase API
without any problem).
The g-ir-scanner call outputs a lot of warning but I won't care for
these right now.
The `introspection.m4` is taken straight from GEGL tree.
Add a new gimp:offset operation, which implements equivalent
functionality to gimp_drawable_offset(), in preparation for adding
an interactive offset tool.
To simplify things, add a GIMP_OFFSET_WRAP_AROUND value to the
GimpOffsetType enum, to avoid the need for a separate wrap-around
flag. This makes the gimp-drawable-offset procedure parameters a
little superfluous, but whatever.
Older --enable-binreloc configure option had basically the same purpose
as the newer --enable-relocatable-bundle, though the old binreloc was
only used for gimpenv.c code.
As a consequence, commit 10ce702188 was still not working fine since
gimp_installation_directory_file() also need binreloc enabled (to be
actually relocatable).
Let's get rid of this whole mess, by implying we want binreloc code to
be used when --enable-relocatable-bundle is ON. We don't need the
m4macros anymore, since AM_BINRELOC was basically just checking that
`/proc/self/maps` was present. But anyway being present at compile time
does not mean it will be at runtime (nor the opposite). So this test is
not that useful. The binreloc code will anyway fallback gracefully to
the non-binreloc code (i.e. trying to use build-time install paths) if
the procfs is lacking at runtime.
... on macOS.
The debugger running on macOS is usually lldb and (from the reports we
get) it looks like lldb displays the tid as hexadecimal on macOS
(whereas lldb displays decimal tid on Linux! I know, it's confusing, yet
consistent with crash report experience!). So let's just do the same,
making it easy to quickly copy-search in order to look up the crashing
thread (without having to convert from decimal to hexa).
This is a bit of an approximation as I imagine we could have gdb on
macOS or whatever edge case. Let's say it's good for the common case and
still not an error otherwise (just a base conversion away).
