On my previous post, the following blocks is wrong. > (First, Can we replace 'pdb.' to 'null'?.) Please forget it. And Please remove it. PS; When I tried from The Console, The applied last result from the Procedure Browser shows '[ ]'. It's not user friendly, a bit. At the white space place, we need to write something like a 'GObject.Value(Gimp.RunMode, Gimp.RunMode.NONINTERACTIVE), ...' so on, right? 2021年8月25日(水) 12:26 ShiroYuki Mot <shiroyuki.mot.mail@xxxxxxxxx>: > 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@xxxxxxxxx>: > >> Hi! >> >> On Tue, Aug 24, 2021 at 5:31 PM ShiroYuki Mot < >> shiroyuki.mot.mail@xxxxxxxxx> 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 >> > _______________________________________________ gimp-developer-list mailing list List address: gimp-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
