Re: [Gimp-developer] About The Python Script writing


On Tue, Aug 24, 2021 at 5:31 PM ShiroYuki Mot <shiroyuki mot mail gmail com>

I wrote the Script File Migration Program.
It was used by MS Visual Studio C#.
The target is to migrate the simple and basic scripts to the new API 3 in
GIMP 2.99 (GIMP 3).
Yes, Scheme and Python, both.
It is still Draft level yet.
Scheme file was almost done, but, Python file is not complete yet.
(No workable Python code has been generated yet. Need manual editings.)

Holding Items for Python.
1. class - Parameters (__gproperties__ = {)
2. class - def do_create_procedure - procedure.add_argument_from_property
3. pdb calling conversion ... not set out. Maybe, I know how to write.
  4. old procedure arguments migration

On Python,
The formatted/migration-based  sources are created from the official
'' .
The qualified phrases using "<<term>>" replace by a value obtained from
the old code.

Here is Questions.
1. Can write PF_COLOR/PF_SPINNER/etc. block like a 'str/float' style in
'__gproperties__ = {' at class ?

Actually creating procedure parameter in Python plug-ins is a bit of a
mess, because of various issues in pygobject.
Adding properties to the class is indeed not mandatory, we should be able
to just create a GParamSpec and use it in gimp_procedure_add_argument().

So we **should** be able to just write:

paramspec = GObject.param_spec_rgb("color",
"Color", true, red,


Except it doesn't work because of a bug in pygobject:

This is why I created gimp_procedure_add_argument_from_property() to grab
the GParamSpec out of a created class' property.

Now the question is: how do you create a property to a GObject class in
Python? Well it turns out documentation lists 3 ways to create a GObject

I used the __gproperties__ one because it felt a bit more centralized and
easy to detect (also it's apparently the only syntax allowing to set
min/max values), but it turned out that I never managed to make a Gimp.RGB
property using this syntax. This is the reason why in Foggify plug-in, all
but the "color" property use the __gproperties__ syntax whereas "color" is
defined like this:

    color = GObject.Property(type =Gimp.RGB, default=_color,
                             nick =_("Fog _color"),
                             blurb=_("Fog color"))

It looks like a limitation of this __gproperties__ syntax, but maybe I
missed something in how this syntax works.
And this is all why it's such a mess. Of course, maybe a best way might be
to define all properties with GObject.Property() syntax, then we don't have
discrepancy in code style (but then we also lose the min/max ability).

2. Is the Class name the Camel-style except "_" ?
   ex. python-fu-shiro-migration-test-210 > ShiroMigrationTest210

Yes we use CamelCasing for class names in our Python code, I guess it's
just usage in Python (
Now we have coding style for within GIMP core code, but we don't mind what
third-party software developers want to use. We are really not into coding
style wars, only keeping consistency within a single codebase.

3. Can the procedure definition name include "_"?
   (4th arg at 'procedure =' of 'def
do_create_procedure(self, name)')
   ex. def shiromigrationtest210 > ? def shiro_migration_test_210 OK?

Sure. Python doesn't forbid underscores in function names. Actually it even
advises using it in the same coding style document ( You
can see this is also the convention we are using in our Python code in
GIMP's codebase.

Initially, the development language was
As a possibility in the future, if I publish the source code (or
project/solution) and expect other people to participate, I thought that C#
was more versatile, so I wrote it by C#, which I am not used to.

To be fair, I don't think I'd be a big fan of either VB or C#. This being
said, same as coding style, you are free to do and use whatever you want,
and I won't be the one to tell you it's wrong. If you make a great tool for
migrating third-party plug-ins into GIMP 3 API, we will even happily make a
mention of it on when we are closing the release date! 👍

We, the beginner level GIMP scripting users, are referring to the
Procedure Browser.
So, I think there are many cases that there are a lot of calling
sentences in the file.
In this case, I feel that visibility deteriorates because there are the
new multiple lines per the old syntax line by the migration.

Maybe, it is better that using not pdb calling but Gimp command (Gimp
class ?).
But currently there does not exist the comparison table/list for these.
I think it would be very useful if that will be provided.

We might do one, but we are very few, so no promises. Your best bet would
be to contribute one.

Actually people were used to the old API but it was a mess. Some functions
were indeed under the `pdb` module, because they were generated from the
pdb protocol. Others were custom wrapper functions specific to the Python
wrapping API. There was no easy way to know what is what and where.
Now we just have the exact same functions as libgimp and libgimpui (the 2
libraries provided for C plug-ins) in respectively Gimp and GimpUi modules.
So you can just look the C header files, and the same functions exist.

I will have to do a tutorial soonish. I will definitely do one before GIMP
3 release.
Maybe I should also do a video tutorial like "create a GIMP plug-in in 15
min" to show a bit how I work and how it's actually quite straightforward.

I hope I answered your questions.
Have fun!


.zip Inf.
FileName :
FileDate : 2021/08/24 23:09:04     ( or * Downloaded Date * )
FileSize : 193099    (189KB)
   MD5 : 318f7a7002a44550188d630c9cd48cfa
  SHA1 : 2e6390231b13f39b4d20f81e70003641cbadf499

FileName : API_Inf/RemovedFunctions_Replacement_GIMP3.txt   <- in zip
FileName : GIMPscriptMigSupport_API2to3.exe   <- in zip
FileName : GIMPscriptMigSupport_API2to3.exe.config   <- in zip
FileName : Ref_Inf/GIMP_Enums.txt   <- in zip
FileName : Ref_Inf/Py3_Import.txt   <- in zip
FileName : Ref_Inf/Py3_Registration.txt   <- in zip

ZeMarmot open animation film

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]