Yes, the proposal seems to have been shot down already. I don't think it
will work.
See a discussion https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/709
I paraphrase here and might not be accurately describing things
The primary goal is to let plugin authors refer to enums
I continued to prototype this.
Proved that a plugin can cross the wire to GIMP with
gimp_procedure_add_enum.
It creates a dynamic GEnum on both sides of the wire.
But it revealed these problems:
1. GIMP crashes when it starts the second time after installation,
I suppose when it is reading
More information since my last email
I prototyped this. Using GTypeModule, a dynamically loaded module which
declares dynamic types.
So far, I seem to be able to create a dynamic GEnum on the plugin side.But
I think it crashes on the GIMP side of the wire.That is, the plugin creates
a
This is a continuation of a thread on this list:
https://mail.gnome.org/archives/gimp-developer-list/2022-July/msg00016.html.
The thread diverged to a discussion about future PF_OPTION implementation
in GIMP 3.
Here are my preliminary thoughts.
A PF_OPTION, in the old PyGimp, or a SF_OPTION, in
Can someone give guidance about plugins and GimpProcedureDialog?
I can probably work on it, both on the plugin side and the libgimp side.
I suppose that for GIMP 3, plugins should use GimpProcedureDialog
and GimpConfig. Where formerly PyGimp and ScriptFu each rolled their own
GUI.
That plugins
To get past that, you could use the meson option to forego building the
vapi?
option('vala-plugins', type: 'feature', value: 'auto', description:
'Build VAPI and Vala plugins')
___
gimp-developer-list mailing list
List address:
A recent commit moved that plugin to "data-extras".
In other words, gimp.org is no longer maintaining it
because it was only for testing purposes,
so you don't need to translate it.
I don't know exactly how to fix your problem, probably just delete one line
from some makefile.
Probably the commit
The v3 PDB API has changes for multilayer capability.
For example this signature change: gimp-edit-copy(drawable) =>
gimp-edit-copy(drawableArray).
This breaks some scripts in the GIMP repository and some third party
plugins.
To provide backward compatibility means allow existing scripts to work
Is there a build option for the meson build similar to the --with-pdbgen
for the automake AM build?
I am hacking at PDB procedures. The meson build doesn't seem to generate
code using the PDBGEN tool (from the source in the pdb/groups directory.)
There is no mention of "pdb" in the
I tried my suggestion. It seems like Gimp.Drawable.apply_operation(node)
is necessary but not exposed in libgimp. A pipe dream then.
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership:
We don't need to enhance Script-Fu to be gegl aware.
We just need a plugin that is gegl aware.
Call the plugin "python-fu-do-gegl-op."
Given a drawable, an operation name like "gegl:median-blur" and a list of
arguments (usually all numeric)
the plugin invokes the gegl operation on the drawable.
I will answer (at least for Median Blur), but I am not a developer, and
someone else might know better.
ScriptFu calls procedures in the PDB, so yes, if it is not in the PDB, you
probably can't call it from ScriptFu ( and the PDB browser would not omit
anything.)
Just browsing the code:
1. The precision degree of a conversion
Maybe it is a candidate for rewriting.
As written, it is noun noun noun.
Might be better written in English as "Precision of Conversion Dialog."
Meaning ((Precision of Conversion) Dialog).
That's still three nouns, still hard to understand without the
I think issue #5402 is relevant, and includes a patch to ScriptFu code for
2.99.
A script still uses string filenames. ScriptFu the interpreter sees that
the signature of a PDB procedure requires a GFile and marshalls the string
into a GFile.
But the patch has not been applied yet. Kevin, are
The file export/import methods are plugins, i.e. in the PDB.
You can browse the PDB using Filters>Development>Python-Fu>Python Console
then the Browse button. There is one named "file-tiff-save"
Yes, you can call a PDB procedure from a C plugin using
gimp_run_procedure ()
No, you don't need to
> is it possible writing a plug-in to generate an image without an opened
image?
Rephrasing the question: can you write a plugin whose menu item is always
enabled, even without an open image? That used to be possible, by passing
an empty string for the "image types" registration data. But your
The official stance is that Python plugins in Gimp 3 will need to use
Python3 and GObject Introspection. There are working examples in the
gimp/plug-ins/python directory and at gimp/plug-ins/goat-exercises/... .py
. AFAIK there is little documentation for plugin authors.
IOW PyGimp and GimpFu
I would hope that in the future the Gimp install would define that variable
in the environment of Gimp so that plugins spawned by Gimp would have the
same environment. But since 2.99 is still in development, there is no
installer so you must temporarily do it yourself.
Try package lua-lgi
I think I had this same issue, and documented it at
https://wiki.gimp.org/wiki/Hacking:Problems_and_solutions#luajit:_...mp.2F2.99.2Fplug-ins.2Fgoat-exercise-lua.2Fgoat-exercise-lua.lua:22:_module_.27lgi.27_not_found
:
___
Possibly liquid rescale plugin will work now. If you look at the github
repository for the plugin, you can see that a bug was fixed recently.
Maybe you just need to download a recent version. If you say exactly what
version of Gimp you are using, and where you downloaded the plugin, others
might
A small example, also shows the problem, with a slightly different error
message:
args = Gimp.ValueArray.new(4)
args.insert(0, GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE))
args.insert(1, GObject.Value(Gimp.Drawable.__gtype__, drawable))
args.insert(2,
Complicated stuff is necessary to implement a new GimpFu, which is what
makes it simple to plugin authors. I am not writing a plugin, I am testing
old plugins with a new implementation of GimpFu.
In the master branch (version 2.99) of gimp repository you will see some
python plugins that have
Specifically, to pass as third arg to Gimp.PDB.gimp_pencil(layer, 4 line).
Said argument should be GimpFloatArray according to PDBBrowser.
I create a GimpValueArray to pass args to the pdb. To create a GValue for
the third arg, I tried:
GObject.Value(Gimp.FloatArray.__gtype__, (1.0, 1.0, 1.0,
Try looking at gimp/plug-ins/common/contrast-retinex.c, or other examples in
the gimp repository. I should think one would be doing a similar thing as your
plugin. I know very little about gegl and plugins.
___
gimp-developer-list mailing list
List
Alex: yes, I understood most of that by browsing the repository, but it is good
to restate it for other readers.
Some plugins, like foggify.py have been ported, but only partially, without the
GUI. If you look at the history (in the repository), you can see that it
formerly was a “gimpfu”
Alexandre: Yes, that code, in master (2.99, the “dev” branch for Gimp 3)
In that branch, the Makefile.am has commented out the pygimp sub directory,
and the meson script does not subdir the pygimp directory (doesn’t try to build
it.)
So an onlooker like myself wonders whether it is abandoned,
I think GimpFu is very useful to novice plugin authors and should be
retained for that reason. GimpFu provides a much simpler, approachable
API, and is the part that generates the GUI automatically.
Also, there are probably thousands of plugins that use Gimpfu (granted,
many are trivial and
I started porting gimpfu.py to Gimp 3, Python 3.
Is there any reason not to? Am I duplicating effort?
The goal is to support legacy third-party plugins that use gimpfu.
Requiring minimal syntax changes to legacy plugins.
I shared the hacked code at https://github.com/bootchk/GimpFu-v3.
My
28 matches
Mail list logo
