Re: [Gimp-developer] gimp-developer-list Digest, Vol 18, Issue 7

[Kim Malar <kimmalar126 gmail com>]

what are legacy plugins???

On Thu, Mar 7, 2013 at 5:30 PM, <gimp-developer-list-request gnome org> 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 <seanmunkel gmail com>
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 <gwidion mpc com br> 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 <jononor gmail com>
To: "Joao S. O. Bueno" <gwidion mpc com br>
Cc: gimp-developer <gimp-developer-list gnome org>
Subject: Re: [Gimp-developer] GIMP - flesh out a way of allowing lazy
        rendering?
Message-ID:
        <CAJeABUU25E69nyD8PpnSCkCYstS7kn91NnqMX8wO_qp0meY=zQ mail gmail com>
Content-Type: text/plain; charset=UTF-8

On 4 March 2013 15:24, Joao S. O. Bueno <gwidion mpc com br> 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" <gwidion mpc com br>
To: Sean Munkel <seanmunkel gmail com>
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 <seanmunkel gmail com> 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 <gwidion mpc com br> 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 <seanmunkel gmail com>
To: gimp-developer-list gnome org
Subject: [Gimp-developer]  Improving pygimp documentation
Message-ID:
        <CAKyAGk2deMQo=BYn0KZx5rRmN8tUtXNzXA68-XrBdkdBsw0DUQ mail gmail com>
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
**************************************************