RSS/Atom feed Twitter
Site is read-only, email is disabled

Improving pygimp documentation

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

5 of 6 messages available
Toggle history

Please log in to manage your subscriptions.

Improving pygimp documentation Sean Munkel 04 Mar 01:25
  Improving pygimp documentation Joao S. O. Bueno 04 Mar 11:46
   Improving pygimp documentation Sean Munkel 06 Mar 22:19
    Improving pygimp documentation Joao S. O. Bueno 07 Mar 03:13
     CAKyAGk1L=GyzBcGamgnjsU=i-D... 07 Mar 03:48
      Improving pygimp documentation Sean Munkel 07 Mar 03:47
Sean Munkel
2013-03-04 01:25:36 UTC (over 11 years ago)

Improving pygimp documentation

I know that the documentation of pygimp itself is a bigger priority than this, but I've been experimenting with a way to dynamically generate the documentation for procedures based on the metadata that they have. It automatically converts the parameters to the correct python type (though admittedly that wasn't exactly that confusing), makes sure that things fit nicely in the default python console (on Windows at least), and most importantly makes the handling of the run_mode keyword argument clearer. Aside from this is there a good way to approach improving the documentation for pygimp? I know that the documentation for gimpplugin is pretty scares and gimpui and gimpthumb seem to have none at all, but at the same time there is documentation for properties of things like Layer and Channel that are either completely useless, or out of date.

Anyway here is the program that I propose be integrated into the python console: https://github.com/smunkel/pygimp-help/blob/master/gimphelp.py

--Sean Munkel

Joao S. O. Bueno
2013-03-04 11:46:17 UTC (over 11 years ago)

Improving pygimp documentation

I am sorry -
this is not the way to proceed.

There is no GIMP's "built-in help" - GIMP_Python does use standard Python's help - and that should no tchange. What standard Python help does is to display the function signature, when available, and the contents of the object's __doc__ attribute.

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 -> wrote:

I know that the documentation of pygimp itself is a bigger priority than this, but I've been experimenting with a way to dynamically generate the documentation for procedures based on the metadata that they have. It automatically converts the parameters to the correct python type (though admittedly that wasn't exactly that confusing), makes sure that things fit nicely in the default python console (on Windows at least), and most importantly makes the handling of the run_mode keyword argument clearer. Aside from this is there a good way to approach improving the documentation for pygimp? I know that the documentation for gimpplugin is pretty scares and gimpui and gimpthumb seem to have none at all, but at the same time there is documentation for properties of things like Layer and Channel that are either completely useless, or out of date.

Anyway here is the program that I propose be integrated into the python console:
https://github.com/smunkel/pygimp-help/blob/master/gimphelp.py

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

Sean Munkel
2013-03-06 22:19:33 UTC (over 11 years ago)

Improving pygimp documentation

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 ->

Joao S. O. Bueno
2013-03-07 03:13:40 UTC (over 11 years ago)

Improving pygimp documentation

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

Sean Munkel
2013-03-07 03:47:49 UTC (over 11 years ago)

Improving pygimp documentation

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