Derailment...
Only by seeing the code... (Not try yet)
In Foggify.py, a variable name "name" conflict with the "name" of the
property registration?
This is probably because the label string 'name' no longer appears in the
dialog.
(Only showing the TextBox default-valued "clouds".)
If so, in that case, we cannot use 'name' as the name that allows us to
specify a variable for the argument.
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
