what are legacy plugins???

On Thu, Mar 7, 2013 at 5:30 PM, wrote:

Send gimp-developer-list mailing list submissions to gimp-developer-list@gnome.org

To subscribe or unsubscribe via the World Wide Web, visit https://mail.gnome.org/mailman/listinfo/gimp-developer-list or, via email, send a message with subject or body 'help' to gimp-developer-list-request@gnome.org

You can reach the person managing the list at gimp-developer-list-owner@gnome.org

When replying, please edit your Subject line so it is more specific than "Re: Contents of gimp-developer-list digest..."

Today's Topics:

1. Re: Improving pygimp documentation (Sean Munkel) 2. Re: GIMP - flesh out a way of allowing lazy rendering? (Jon Nordby)
3. Re: Improving pygimp documentation (Joao S. O. Bueno) 4. Improving pygimp documentation (Sean Munkel)

----------------------------------------------------------------------

Message: 1 Date: Wed, 6 Mar 2013 17:19:33 -0500 From: Sean Munkel
To: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Improving pygimp documentation Message-ID:
<
CAKyAGk3gJCdmfMhE++vY81+Nx1E83r_Nmkp38e7gmNATV8647w@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1

The problem with that is that help() would not display the__doc__ for the instance of PDBFunction, but will instead generate a generic overview of the class itself. As far as I can tell this is because help() doesn't recognize PDBFunction instances as functions (or routines as they're called in inspect). I had actually tried your approach initially and it did not work coming from the C side or from the Python side. This is why I created a custom help(). To get help() to display the __doc__ of an object it has to be a C builtin or a python function.

This brings me to a messier idea that I had to get around this. One way to get around this issue of __doc__ not being display is to actually create a regular python function for each procedure. Instead of using gimp.PDB you would have to wrap it in a class that will use its methods but hook into __getattr__. Inside of __getattr__ it would create a function that would then be able to have a __doc__ that would be displayed by help.

https://gist.github.com/smunkel/5103533

On Mon, Mar 4, 2013 at 6:46 AM, Joao S. O. Bueno wrote:

Your approach could lead to a a patch to dynamically provide the __doc__ attributes of PDB items - taht would be ok. For the builtin items, such as Layer, Image and such, as the code is today, the documentation would have to be hard-coded in the C files, however.

js ->

------------------------------

Message: 2 Date: Thu, 7 Mar 2013 00:41:17 +0100 From: Jon Nordby
To: "Joao S. O. Bueno"
Cc: gimp-developer
Subject: Re: [Gimp-developer] GIMP - flesh out a way of allowing lazy rendering?
Message-ID:

Content-Type: text/plain; charset=UTF-8

On 4 March 2013 15:24, Joao S. O. Bueno wrote:

Hi all --

While GIMP 2.9 is thriving with lots of possibilities, one thing remain

as fact:

it is dead slow.

I most likely missed some of the efforts being done to try to compensate for that -
like avoiding unnecessary pixel format conversions in some operations -

and

the possibility of having GEGL to run with open-CL acceleration.

I think it is not an exaggeration to add that even with this, the current rendering model
is dead slow.

To the point of being unfeasible to work on a 1024x768 image in modern hardware -
one simply can't paint.

Other raster application, including GIMP 2.8, are doing OK performance wise with a rendering mode that is very similar to GIMP uses now, so I don?t we necessarily need to do drastic changes there in order to fix the performance.

I think a useful GSoC project would be to define and implement some meaningful benchmarks for GIMP. If successful, that would give insights into what the causes of the current performance problems are. I believe that is needed for coming up with a good solution for current, and future performance issues.

-- Jon Nordby - www.jonnor.com

------------------------------

Message: 3 Date: Thu, 7 Mar 2013 00:13:40 -0300 From: "Joao S. O. Bueno"
To: Sean Munkel
Cc: gimp-developer-list@gnome.org
Subject: Re: [Gimp-developer] Improving pygimp documentation Message-ID:
<
CAH0mxTQ55qHtr4jEwUAFBewAp50UxcvwUjXSSBtA5rLqN+46vQ@mail.gmail.com> Content-Type: text/plain; charset=UTF-8

On 6 March 2013 19:19, Sean Munkel wrote:

The problem with that is that help() would not display the__doc__ for the instance of PDBFunction, but will instead generate a generic overview of the class itself. As far as I can tell this is because help() doesn't recognize PDBFunction instances as functions (or routines as they're called in inspect). I had actually tried your approach initially and it did not work coming from the C side or from the Python side. This is why I created a custom help(). To get help() to display the __doc__ of an object it has to be a C builtin or a python function.

This brings me to a messier idea that I had to get around this. One way to get around this issue of __doc__ not being display is to actually create a regular python function for each procedure. Instead of using gimp.PDB you would have to wrap it in a class that will use its methods but hook into __getattr__. Inside of __getattr__ it would create a function that would then be able to have a __doc__ that would be displayed by help.

https://gist.github.com/smunkel/5103533

Yes - that would be more or less the way to go - Or that, or make each PDB callable object be in a separate class by itself.

Did the code in the link above work for you? (I have not tried it yet)

js ->

On Mon, Mar 4, 2013 at 6:46 AM, Joao S. O. Bueno

wrote:

Your approach could lead to a a patch to dynamically provide the __doc__ attributes of PDB items - taht would be ok. For the builtin items, such as Layer, Image and such, as the code is today, the documentation would have to be hard-coded in the C files, however.

js ->

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

------------------------------

Message: 4 Date: Wed, 6 Mar 2013 22:47:49 -0500 From: Sean Munkel
To: gimp-developer-list@gnome.org
Subject: [Gimp-developer] Improving pygimp documentation Message-ID:

Content-Type: text/plain; charset=ISO-8859-1

One
way to get around this issue of __doc__ not being display is to actually create a regular python function for each procedure. Instead of using gimp.PDB you would have to wrap it in a class that will use its methods but hook into __getattr__. Inside of __getattr__ it would create a function that would then be able to have a __doc__ that would be displayed by help.

https://gist.github.com/smunkel/5103533

Yes - that would be more or less the way to go - Or that, or make each PDB callable object be in a separate class by

itself.

Did the code in the link above work for you? (I have not tried it yet)

It isn't properly dealing with Nones everywhere yet, but for the most part its
working correctly.

--Sean Munkel

------------------------------

Subject: Digest Footer

_______________________________________________ gimp-developer-list mailing list
gimp-developer-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gimp-developer-list

------------------------------

End of gimp-developer-list Digest, Vol 18, Issue 7 **************************************************