what are legacy plugins??? On Thu, Mar 7, 2013 at 5:30 PM, <gimp-developer-list-requ...@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-requ...@gnome.org > > You can reach the person managing the list at > gimp-developer-list-ow...@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 <seanmun...@gmail.com> > To: gimp-developer-list@gnome.org > Subject: Re: [Gimp-developer] Improving pygimp documentation > Message-ID: > < > cakyagk3gjcdmfmhe++vy81+nx1e83r_nmkp38e7gmnatv86...@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 <gwid...@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 <jono...@gmail.com> > To: "Joao S. O. Bueno" <gwid...@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= > z...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 4 March 2013 15:24, Joao S. O. Bueno <gwid...@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" <gwid...@mpc.com.br> > To: Sean Munkel <seanmun...@gmail.com> > Cc: gimp-developer-list@gnome.org > Subject: Re: [Gimp-developer] Improving pygimp documentation > Message-ID: > < > cah0mxtq55qhtr4jewuafbewap50uxcvwujxssbta5rlqn+4...@mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On 6 March 2013 19:19, Sean Munkel <seanmun...@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 <gwid...@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 <seanmun...@gmail.com> > To: gimp-developer-list@gnome.org > Subject: [Gimp-developer] Improving pygimp documentation > Message-ID: > <CAKyAGk2deMQo= > byn0kzx5rrmn8tutxnzxa68-xrbdkdbsw0...@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 > ************************************************** >
_______________________________________________ gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list
