Maybe should we have IMAGE_ARRAY types as we still have to pass image
IDs when we pass more than one image between core and plug-in. And even
maybe have alternate LIST types to ARRAY ones, so that we can pass GList
through rather than one array parameter + one length parameter.
Anyway this port still return just old style array of image IDs + array
length as int32.
Turn all ID param specs into object param specs (e.g. GimpParamImageID
becomes GimpParamImage) and convert between IDs and objects in
gimpgpparams.c directly above the the wire protocol, so all of app/,
libgimp/ and plug-ins/ can deal directly with objects down to the
lowest level and not care about IDs.
Use the actual object param specs for procedure arguments and return
values again instead of a plain g_param_spec_object() and bring back
the none_ok parameter.
This implies changing the PDB type checking functions to work on pure
integers instead of IDs (one can't check whether object creation is
possible if performing that check requires the object to already
exist).
For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is
not involved in automatic object creation magic at the protocol
level. Added wrappers which still say gimp_foo_is_valid() and take the
respective objects.
Adapted all code, and it all becomes nicer and less convoluted, even
the generated PDB wrappers in app/ and libgimp/.
Note: there were 2 additional arguments which were totally unused in the
existing implementation. So I commented them out. Anyone is welcome to
actually implement their usage.
Remove the separate "advanced" procedure. With GParamSpec default
values the differance between normal and advanced is just
non-interactive vs. interactive.
There are 2 TODOs to take care of here. First, there is no GUI yet for
the interactive mode which will just use the default values.
Second, the color argument is not working yet because I had issues
passing a GimpRGB as argument (ideally I should create a GimpParamRGB
with gimp_param_spec_rgb(), but since we still have the pygobject bugs
about manipulating GParamSpec data directly, I can't).
Anyway it works with default values, which is already a good first step.
:-)
We now have both variants, one returning a GList, and another
returning an array. Turns out that while a list is often nicer,
sometimes a random-access array really keeps the code much simpler.
Adapt all plug-ins, and clean up a bit (like use g_list_reverse() once
instead of iterating the list reversed).
Apart from porting, only code logics change is the whole
encode()/decode() code because it created a string vs bytes mess and the
zipfile API apparently didn't like to deal with bytes, even though the
docs say otherwise.
It's hard to test on my UTF-8 system, so please anyone working with
non-UTF-8 paths, we welcome reports if ORA load/save does not work
properly.
Other than this, load, save and load_thumb were all tested and working
properly so far.
The JS and Python 3 had to be ported to the new GimpImageProcedure API.
The Lua one was still using the old ID API hence was broken. Also not
sure why run_mode enum has become a string in Lua with the new
GimpImageProcedure API (probably some automatic conversion happening
during the C to Lua binding?), but well… it works like that, so what.
Sync also the late changes from the C goat exercise, like for instance
not returning an error when selection is empty as well as keeping the
order of calls to be the same across the 4 supported demo scripts.
This fixes:
> warning: source file 'images/imagemap-icon-images.c' is in a subdirectory,
> but option 'subdir-objects' is disabled
And similar warnings.
This means that images' ownership is not given to caller in particular.
libgimp will now keep a reference of all GimpImage-s it creates and
return this same reference if called again. It also means that you can
now compare images by pointer comparison (as 2 GimpImage objects
representing the same image ID will be equal).
Obviously as a side effect, gimp_image_list() is changed to (transfer
container) as you must only free the container now, not the elements.
Also various other functions creating new images are now (transfer none)
too.
Long-time plug-ins will have to be taken in consideration in a further
step (we currently never free GimpImage for destroyed images in
particular).
PyGObject seems to have at least 3 syntaxes to create object properties.
Though the one I used previously was apparently the recommended syntax,
it was clearly a bit messy and not clear. This alternative syntax ends
up much more compact, really look alike the C-style, which is a good
thing and is very visual. From what I can see, we should also override
the get|set_property() methods, but since we are not going to actually
set any value (this is only a workaround to make a GParamSpec), it seems
to work fine without.
You'll notice that with the new class when used together with the new
GimpPlugIn API, it is not needed to allocate/destroy anymore the
GimpImage/GimpDrawable. These can be directly the parameters.
It's just too weird to be public. Remove its properties from the wire
protocol and from pluginrc. Instead, have all GParamSpecs' flags on
the wire and in pluginrc, so we can use stuff like
GIMP_PARAM_NO_VALIDATE.
Port the remaining few places to GIMP_PROC_ARG_STRING().
I'm sure something is broken now wrt UTF-8 validation,
will add tighter checks in the next commit.
And always pass URIs to all file procedures, the ones what didn't
register as "handles remove" will only ever get local file:// URIs.
Change all file plug-ins (also legacy ones) to expect URIs instead
of filenames, and convert to local paths in the plug-in.
The wire protocol should now be almost 100% clean of non-UTF-8 strings.
All the GimpImageProcedure must remap the order of their additional
arguments (i.e. subtracts 3).
This fixes the other plug-ins changed in commit 15019fef52 which had
such additional arguments.
I got a 'Invalid cross-device link' error (errno 18) on my system. Let's
add some redundancy and try g_file_move() if g_rename() failed.
This at least fixed my case.
This commit removes all save procedures except gimp-png-save with all
parameters, and kills the default value handling procedures.
Default handling is now broken for NONINTERACTIVE use, but we will
handle this much better and consistent for all save procedures inside
GimpSaveProcedure
So procedure:new_return_values() just seems broken with LGI. It doesn't
even look like it reaches the C code.
Anyway we can also just reconstruct the GimpValueArray, which works
fine. We now have official support for Lua plug-ins!
It is working fine except that it crashes at the end when running
procedure:new_return_values(). I have not understood why yet, but it may
be a bug in lua LGI. Maybe we'll have to create the returned
GimpValueArray by hand in Lua.
Also the dialog does not show the source yet.
This is not installed yet (and lua interpreter is not checked at
configure) because of these issues which I will have to figure out. In
the meantime, I commit this work-in-progress.
So it seems that whatever is in _SCRIPTS is not in the distribution by
default (I suppose the reason is that even scripts can be generated). So
let's add the non-generated scripts to EXTRA_DIST.
Michael Natterer