Re: [Gimp-developer] About The Python Script writing
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 :
> 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 :
>
>> Hi!
>>
>> On Tue, Aug 24, 2021 at 5:31 PM ShiroYuki Mot <
>> shiroyuki.mot.m...@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 "<>" 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,
>>>
Re: [Gimp-developer] About The Python Script writing
Hi,
On Wed, Aug 25, 2021 at 1:52 AM Ofnuts via gimp-developer-list <
gimp-developer-list@gnome.org> wrote:
> Wouldn't it be more natural to write the migration program in Python
> itself (plus this needs Python2->Python3 migration)? Why add a
>
It's a third-party tool, not an official one. We don't have our say to what
people enjoying GIMP want to use it with?
This being said, someone could create a similar tool in Python or whatever
you want.
dependency on yet another language? Is there a decent C# runtime on Linux?
>
That's a good question. I have no idea.
In any case, if it were to be contributed as an official tool in the end,
your worry would be most valid as cross-platform code matters a lot. As
long as it's just a third-party tool, everyone may use whatever they want.
Jehan
>
> On 24/08/2021 17:31, ShiroYuki Mot via gimp-developer-list 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. Can it be run on L
> > 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 "<>" 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 ?
> > 2. Is the Class name the Camel-style except "_" ?
> > ex. python-fu-shiro-migration-test-210 > ShiroMigrationTest210
> > 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?
> >
> >
> >
> > 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.
> >
> >
> >
> > 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.
> >
> >
> > .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
> >
> > ___
> > gimp-developer-list mailing list
> > List address:gimp-developer-list@gnome.org
> > List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> > List archives: https://mail.gnome.org/archives/gimp-developer-list
>
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives: https://mail.gnome.org/archives/gimp-developer-list
>
--
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@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] About The Python Script writing
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 :
> Hi!
>
> On Tue, Aug 24, 2021 at 5:31 PM ShiroYuki Mot <
> shiroyuki.mot.m...@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 "<>" 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
Re: [Gimp-developer] About The Python Script writing
Dear Ofnuts.
Thanks for your reply.
Sure.
But, Simply, I'm easier to write in C# than Python. (and more easier in
VB.net than C#.)
I answer that I don't have enough knowledge about it.
Why add a dependency on yet another language? Is there a decent C# runtime
> on Linux?
There exists a 'Mono' runtime.
https://www.mono-project.com/
https://www.mono-project.com/docs/advanced/runtime/
But, currently, My code strongly relies on Windows for OS-specific path
separators and line-breaks/new-line, so I think it will be an error at
runtime.
In other words, it is windows-only. Sorry.
I don't expect the migration to be completed with a mechanical replacement.
We may need to change the enumeration in many cases.
I think it is desirable to do it interactively, so I think GUI (ex.
TEXTBOX) is essential.
Perhaps, from in the Console of GIMP, it is difficult for me.
2021年8月25日(水) 8:52 Ofnuts via gimp-developer-list <
gimp-developer-list@gnome.org>:
> Wouldn't it be more natural to write the migration program in Python
> itself (plus this needs Python2->Python3 migration)? Why add a
> dependency on yet another language? Is there a decent C# runtime on Linux?
>
> On 24/08/2021 17:31, ShiroYuki Mot via gimp-developer-list 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. Can it be run on L
> > 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 "<>" 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 ?
> > 2. Is the Class name the Camel-style except "_" ?
> > ex. python-fu-shiro-migration-test-210 > ShiroMigrationTest210
> > 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?
> >
> >
> >
> > 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.
> >
> >
> >
> > 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.
> >
> >
> > .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
> >
> > ___
> > gimp-developer-list mailing list
> > List address:gimp-developer-list@gnome.org
> > List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> > List archives: https://mail.gnome.org/archives/gimp-developer-list
>
>
> ___
> gimp-developer-list mailing list
> List address:gimp-developer-list@gnome.org
> List membership:
> https://mail.gnome.org/mailman/listinfo/gimp-developer-list
> List archives: https://mail.gnome.org/archives/gimp-developer-list
>
___
gimp-developer-list mailing list
List address:
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 :
> Hi!
>
> On Tue, Aug 24, 2021 at 5:31 PM ShiroYuki Mot <
> shiroyuki.mot.m...@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 "<>" 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:
>
Re: [Gimp-developer] About The Python Script writing
Wouldn't it be more natural to write the migration program in Python
itself (plus this needs Python2->Python3 migration)? Why add a
dependency on yet another language? Is there a decent C# runtime on Linux?
On 24/08/2021 17:31, ShiroYuki Mot via gimp-developer-list 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. Can it be run on L
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 "<>" 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 ?
2. Is the Class name the Camel-style except "_" ?
ex. python-fu-shiro-migration-test-210 > ShiroMigrationTest210
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?
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.
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.
.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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] About The Python Script writing
Hi!
On Tue, Aug 24, 2021 at 5:31 PM ShiroYuki Mot
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 "<>" 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
[Gimp-developer] About The Python Script writing
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 "<>" 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 ?
2. Is the Class name the Camel-style except "_" ?
ex. python-fu-shiro-migration-test-210 > ShiroMigrationTest210
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?
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.
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.
.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
___
gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives: https://mail.gnome.org/archives/gimp-developer-list
