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.
Something during the port to gimp-drawable-edit (commit
233ac80de1) broke add-bevel.scm when
the thickness is high enough for the selection to become empty.
Add an explicit check for a selection while constructing the bump-
map layer.
Implementing a shiny new GimpFileProcedure doesn't mean the libraries
we use to load/save files are automatically capable of handling remote
files, so we still need this flag.
As discussed on IRC, I am not sure if really this is needed, since
theoretically we now have support for a whole bunch of languages without
doing anything (languages supported by GObject Introspection) and we are
not going to check for all of them.
Yet since now we install one JS plug-in, let's still do a quick check.
We'll see later if we want to change how we handle supported script
languages.
The file path was already the same as ARGV first argument (i.e.
System.programInvocationName as I added this myself!). Why did I even
bothered with this annoying trick!
This makes the code much simpler, which is better for demo code.
Right now it is not working, always because of the same bug about not
being able to create GParamSpec (pygobject#227). As a consequence, I
tried a workaround by creating object properties and using their spec
instead. But it turns out that in pygobject, I cannot create random
properties for custom types (well I could for boxed types or GObject
subclasses, not for GimpImageID or GimpDrawableID). Cf. pygobject#357.
So I am stuck again.
Anyway I still push this demo file which would just work as it is, if we
coult at least got the image/drawable ID.
I comment out the Makefile.am part for now until we can get the issues
sorted out.
because they are deprecated.
Change GIMP_ICON_TYPE_INLINE_PIXBUF to GIMP_ICON_TYPE_PIXBUF and the
libgimp API to (icon-name, GdkPixbuf, GFile). Use the file's uri and a
PNG blob of the pixbuf to pass around on the wire and for storage in
pluginrc.
Only missing parts are:
- localization.
- help function and id unset.
- gimp_procedure_set_icon() should probably be reviewed for proper
introspection.
- Finally there is a String() conversion which raises a warning, but I
couldn't find the proper standard replacement code.
Other than this, the goat-exercise was totally reproduced in JavaScript.
Michael Natterer