gimpfu port to Gimp 3

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

gimpfu port to Gimp 3

Developers mailing list
I started porting gimpfu.py to Gimp 3, Python 3.


Is there any reason not to?  Am I duplicating effort?


The goal is to support legacy third-party plugins that use gimpfu.
Requiring minimal syntax changes to legacy plugins.


I shared the hacked code at https://github.com/bootchk/GimpFu-v3.


My initial testing seems to show that porting gimpfu is doable.  I haven’t
tried a real legacy plugin yet (e.g. clothify.py)
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: gimpfu port to Gimp 3

Developers mailing list
As far as I know, you are not duplicating effort.

As for a reason to not do it, my (perhaps misinformed) understanding is
that there is a goal to make
gimp not target a specific scripting language; that is to equally support
languages like Javascript, Lua (both of which
have example plugins in /plug-ins/goat-exercises), the same as Python.

If you add a GimpFu module for Python, it wont be available for other
languages. Support for other languages might
call for adding additional GimpFu modules for each, and thus adding more
language-specific maintenance.
To my understanding, this language-specific support is what is being
deprecated.

Maybe a better approach would be to have the GimpFu implemented in C, in a
way that it will be available to all scripting languages.

But Is this language-agnostic approach of significant value? I am hardly
objective, because I love Python,
but Python is crushing it
<https://www.infoworld.com/article/3401536/python-popularity-reaches-an-all-time-high.html>
 .


On Fri, Jan 3, 2020 at 4:09 PM Lloyd Konneker via gimp-developer-list <
[hidden email]> wrote:

> I started porting gimpfu.py to Gimp 3, Python 3.
>
>
> Is there any reason not to?  Am I duplicating effort?
>
>
> The goal is to support legacy third-party plugins that use gimpfu.
> Requiring minimal syntax changes to legacy plugins.
>
>
> I shared the hacked code at https://github.com/bootchk/GimpFu-v3.
>
>
> My initial testing seems to show that porting gimpfu is doable.  I haven’t
> tried a real legacy plugin yet (e.g. clothify.py)
> _______________________________________________
> gimp-developer-list mailing list
> List address:    [hidden email]
> 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:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: gimpfu port to Gimp 3

Developers mailing list
I think GimpFu is very useful to novice plugin authors and should be
retained for that reason.  GimpFu provides a much simpler, approachable
API, and is the part that generates the GUI automatically.

Also, there are probably thousands of plugins that use Gimpfu (granted,
many are trivial and rarely used.)  So it seems useful to port GimpFu for
backward compatibility.

Re: goal to support all languages equally.  That would be nice, but I don't
know how to do it.  Also, even if GimpFu is implemented in Python, couldn't
it be available to all languages via GI?  That is, GimpFu doesn't have to
be implemented in C to be available across languages?  So I think a good
strategy is to port GimpFu still in Python (a high level language where
many can contribute quickly) and then proceed to make it cross-language
somehow.

I am still confused about exactly what parts of PyGimp need to be ported to
be able to say GimpFu has been ported.  I think much of PyGimp falls by the
wayside. Or at least the code is much smaller and easy to understand.

I have made some progress, see my repository, which has some design
documents.  But there could be many mistakes.

The problem of porting GimpFu seems VERY educational and interesting.  It
is a plum, that I can't believe someone else has not already plucked, and I
encourage others to get involved.  Granted, there might be a lot of drudge
work.  But at least in this prototyping stage, it seems fascinating.
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: gimpfu port to Gimp 3

Developers mailing list
In reply to this post by Developers mailing list
On Fri, Jan 3, 2020 at 5:09 PM Lloyd Konneker via gimp-developer-list wrote:
>
> I started porting gimpfu.py to Gimp 3, Python 3.
>
> Is there any reason not to?  Am I duplicating effort?

Hello Lloyd!

Are you talking about the contents of
https://gitlab.gnome.org/GNOME/gimp/tree/master/plug-ins/pygimp?

Alex
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: gimpfu port to Gimp 3

Developers mailing list
In reply to this post by Developers mailing list
Alexandre: Yes, that code, in master (2.99, the “dev” branch for Gimp 3)

In that branch, the Makefile.am has commented out the pygimp sub directory,
and the meson script does not subdir the pygimp directory (doesn’t try to build it.)

So an onlooker like myself wonders whether it is abandoned, or just waiting for someone to work on it.
Maybe there was a prior discussion about it, maybe a private discussion?
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: gimpfu port to Gimp 3

Developers mailing list
On Sat, Jan 11, 2020 at 1:55 PM Lloyd Konneker via gimp-developer-list wrote:
>
> Alexandre: Yes, that code, in master (2.99, the “dev” branch for Gimp 3)
>
> In that branch, the Makefile.am has commented out the pygimp sub directory,
> and the meson script does not subdir the pygimp directory (doesn’t try to build it.)
>
> So an onlooker like myself wonders whether it is abandoned, or just waiting for someone to work on it.
> Maybe there was a prior discussion about it, maybe a private discussion?

Around autumn 2019, GIMP in the master branch was ported to use
GObject introspection (https://gi.readthedocs.io/en/latest/) and
Python 3 (Lua and JavaScript plugins also possible now). My
understanding from talking to Jehan is that he ported some of the
existing plug-ins to Python 3 and moved them to
https://gitlab.gnome.org/GNOME/gimp/tree/master/plug-ins/python. The
rest was disabled from building/installing. According to Jehan, Elad
looked into other Python plugins and found out only two of them make
sense to be ported (I don't know which ones exactly, Elad will
probably elaborate).

Of course, there are also 3rd party Python plugins like the one you
ship with Resynthesizer.

I hope things are a bit clearer now :)

Alex
_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list
Reply | Threaded
Open this post in threaded view
|

Re: gimpfu port to Gimp 3

Developers mailing list
In reply to this post by Developers mailing list
Alex: yes, I understood most of that by browsing the repository, but it is good to restate it for other readers.

Some plugins, like foggify.py have been ported, but only partially, without the GUI.  If you look at the history (in the repository), you can see that it formerly was a “gimpfu” plugin i.e. it “from gimpfu import *”.

If gimpfu had been ported first, the former foggify.py might work without porting (or just minor changes.)  I am not trying to criticize the order in which things were done, I realize that the port of foggify was pioneering, to test the machinery at lower levels.  I have looked at the ported code myself to see how to do things (although I think despeckle.c or some other might be a more definitive, complete example of all the things a well-behaved plugin should do.)

GimpFu simplifies writing plugins in Python.  It generates GUI dialog automatically, provides aliases “gimp” and “pdb”, and has only two other methods “register” and “main”.  So loosely speaking you can write a gimpfu plugin knowing little more than the PDB.

Other parts of PyGimp provide pythonic classes for Gimp classes, such as “gimp.Image” (note the lower case “g”, it is not the gobject introspected Gimp.Image.)  These classes have many “convenience” methods (not found elsewhere?)  Many plugins that use gimpfu also use the convenience classes.

I can see that the PyGimp classes are now less useful, since now GI gives you much the same thing.  All an author needs to do is translate from the language of the PyGimp classes to the very similar language of GI of Gimp.

To elaborate my original question: has anyone decided that the convenience of gimpfu (and/or the other parts of PyGimp) is not useful anymore?  I gather that the answer is: some of it might be useful, we just haven’t done it yet, its much, hard work, and noone understands the code anymore.

If there are plans to automatically generate plugin GUI, but implemented cross-language, as Elad suggested…..  then any port of gimpfu could omit writing that in Python and introspected gtk3.

I think the gimpshelf module of pygimp (that provides session persistent storage, mainly for plugin settings) is deprecated because the capability is in Gimp class gimp_procedure_config now.

I think the gimpui module of pygimp (that lets authors use libgimpui i.e. Gimp provided widgets e.g. color picker) could be deprecated because authors can use GI, and as far as I can determine, there are extremely few plugins in the wild that ever used it.



_______________________________________________
gimp-developer-list mailing list
List address:    [hidden email]
List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:   https://mail.gnome.org/archives/gimp-developer-list