GNOME.org
 

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

Dear Jehan Pagès

Thanks a lot. Your detailed answers help me. :)

Q1.


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).



I could understand the reasons why the two writing style for the propaties
exists.
(I got a detail of your comment lines in an official 'Foggify.py' file.)

I'll try to learn the reference page you showed me.  It may be too
professional and difficult to understand.

Q2.


Yes we use CamelCasing for class names in our Python code, I guess it's
just usage in Python (
https://www.python.org/dev/peps/pep-0008/#class-names).
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.



I'll use the 'CamelCasing for class names'. (Done.)

Q3


Sure. Python doesn't forbid underscores in function names. Actually it
even advises using it in the same coding style document (
https://www.python.org/dev/peps/pep-0008/#function-and-variable-names).
You can see this is also the convention we are using in our Python code in
GIMP's codebase.


  Link


Function names should be lowercase, with words separated by underscores as
necessary to improve readability



I'll use the 'underscores in function names' and with all lowercase
characters.

About Selected Language


I won't be the one to tell you it's wrong.



Thanks. :)

pdb-calling vs Gimp/GimpUI


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.



We, the users, need to keep in mind whether it is an internal function or
an extension.
pdb functions have both...
At the Procedure Browser, Should watch the second line.
Maybe, If it starts with 'pdb.gimp_' then it is an inner function. So Not
need to pdb-calling, isn't it? (First, Can we replace 'pdb.' to 'null'?.)

And Then


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.



So Great!!! ;)

2021年8月25日(水) 1:33 Jehan Pagès <jehan marmottard gmail com>:


Hi!

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


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
'foggify.py' .
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",
"Color", true, red,

GObject.ParamFlags.READWRITE)
procedure.add_argument(paramspec)



Except it doesn't work because of a bug in pygobject:
https://gitlab.gnome.org/GNOME/pygobject/-/issues/227#note_570031

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
property:
https://python-gtk-3-tutorial.readthedocs.io/en/latest/objects.html#create-new-properties

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 (
https://www.python.org/dev/peps/pep-0008/#class-names).
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 = Gimp.ImageProcedure.new' 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 (
https://www.python.org/dev/peps/pep-0008/#function-and-variable-names).
You can see this is also the convention we are using in our Python code in
GIMP's codebase.



Initially, the development language was VB.net.
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 gimp.org 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 pdb.xxx 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!

Jehan




.zip Inf.
FileName : GIMPscriptMigSupport_API2to3.v.0.8.1.15.zip
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

 GIMPscriptMigSupport_API2to3.v.0.8.1.15.zip
<https://drive.google.com/file/d/1lV3W73fYz8B31uyckk9yXWBLmau3TLrz/view?usp=drive_web>




--
ZeMarmot open animation film
http://film.zemarmot.net
Liberapay: https://liberapay.com/ZeMarmot/
Patreon: https://patreon.com/zemarmot
Tipeee: https://www.tipeee.com/zemarmot
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]