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.
This just adds a dialog before running the actual processing of data.
- it also shows what the run-mode is for;
- the purpose of the plug-in becomes explicit (plug-in creation
documentation);
- it shows some GTK+ code too.
- last but not least, the code is actually shown for people to study,
with a button to access the last version of the code on gitlab.
This makes the plug-in a lot more useful and understandable this way.
Other exercise plug-ins in other languages will have to do the same
thing.
It is not installed yet, I am just committing my first version. Further
version should look like goat-exercise as an example of what must be
done in javascript.
Also the plug-in stopped working with one of the recent libgimp commits,
without any change in the plug-in code. This will need to be
investigated before installing.
We will fill this up with more examples of plug-ins in other languages.
Also we will improve a bit the examples to redirect people to source
code so that they understand what these plug-ins are.
1/ First I realize we were still using AM_PATH_PYTHON() and not
AM_PATH_PYTHON3().
2/ We don't need to check anymore for pygtk, pycairo, nor do we need
Python headers. Everything is now taken care of by GObject
Introspection and we have nothing else to build GIMP-side.
3/ Change --enable-python into --with-python. We don't actually build
anything now. There is no Python support to enable or disable
anymore. We simply install Python plug-ins or not. The 3 values are
"yes" (default, configure breaks if a Python 3 interpreter is not
found), "no" (Python plug-ins are not installed, not recommended) and
"force" (install Python plug-ins anyway even if an interpreter is not
found; this can be useful especially for cross-compilation since
Python is not useful at build-time anymore).
Note that --with-python=force, if an interpreter is not found, the
file `pygimp.interp` won't be installed. This is not a problem at all
if the interpreter can be found at runtime the standard way.
Otherwise packagers should add themselves a pygimp.interp file with
the known interpreter path.
Oups, I left the plug-in as Python 2. This was still a good
proof-of-concept that GIMP 3 will support as well Python 2 and Python 3
(even though Python 2 is end-of-life soon anyway).
This first version will just offset by 1 in interactive mode, by
default. The GIMP 2 version used to have a GUI, but it was not created
by the plug-in itself. I am guessing that maybe our Python wrapper used
to create GUI by default.
If so, this will have to change. Python plug-ins will be responsible of
their own GUI, just like C plug-ins.
Older palette-to-gradient used to have a palette argument. Bring it
back. The logics is that if the string is empty or None, the procedure
will use the currently selected palette. Otherwise it will try to
transform the named palette into a gradient and will fail with an error
if this palette does not exist.
We have code for this in gimp_proc_browser_dialog_new(), but it cannot
be moved in the object init() because this is a construction-time only
property. So this needs to be passed from the python call too.
As mentioned in issue #1777, exporting non-animated WebP images was
only keeping the current layer.
Mimick file-gif-save.c: display the encoding settings pop-up earlier
so that gimp_export_image() can merge the layers unless "As Animation"
is enabled. Call gimp_image_get_layers() directly in save_image() in
case the layers were merged (for clarity because layers are used only
for animations).
Basically this commit makes sure that all return values that are marked
as "Returns:" also have a `(nullable)` annotation if it is mentioned on
the same line that NULL can also be returned.
This will prevent a few problems in GObject-introspection.
Since GParamSpec are not working fine (cf. pygobject#227), we have this
trick of initializing new arguments or return values with properties.
Use this trick in the palette-to-gradient plug-in.
Michael Natterer