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