Re: [Gimp-developer] Announcing Gimpscripter plugin authoring tool, beta prototype
Yes, the Gimpscripter UI and the whole app is thin and could be improved. But thanks for your suggestion, it helps to prioritize. Thanks for the link, AdaptableGimp is exciting. I haven't yet fully explored AdaptableGimp, so what follows are first impressions. AdaptableGimp seems to be a social way to document a TaskSet (what I call a recipe) and to make the TaskSet point-and-clickable. The difference is that TaskSets are not executable as a unit, you still must point and click. This makes sense when the user needs to use the mouse/pointer during the task, e.g. to make a selection or to draw a shape. OTOH when no user mouse/pointer interaction is required, why not make a TaskSet executable? Shouldn't we merge the two ideas of social programming, and point-and-click authoring of executable-as-a-unit recipes? Maybe the users don't want the messiness: just give me a recipe, I can execute it myself, all that talk about active objects and stacks is confusing. And GEGL is part of the picture, a sequence of image transformations that can be executed as a unit, and controlled as a unit (I have a superficial understanding of GEGL.) Many have suggested improvements to Gimp Registry, to make it more sociable: easier to find, upload, download, and manage plugins. SociableGimp: on-line, community TaskSets AND plugins? Some terminology clarification: Gimpscripter creates what I call shortcuts or wrapper plugins. They are distributable, first-class plugins. They should be sociable. What I call macros are not easily distributable. They are short code fragments built-into Gimpscripter. They are a layer on top of the PDB, to adapt it (eventually some of the macros might migrate to, or be fixed in, the PDB?) They adapt the model presented by the GIMP GUI (e.g. a new layer is in an image) to the model presented by the PDB (e.g., a new layer is not attached.) They don't need to be sociable, once a complete set is created. On Tue, 2011-05-10 at 10:40 +0800, Tim Chen wrote: Looks good. The UI for creating macros could use some improvement though, especially some options to remove/insert actions into existed scripts. Maybe you can reference Michael Terry's recent work on Adaptable GIMP. http://adaptablegimp.org/index.php/How_to_Create_a_Task_Set Thanks for sharing. Regards, Tim Chen http://ht-timchen.org On Mon, May 9, 2011 at 9:23 PM, lloyd konneker boo...@nc.rr.com wrote: Announcing a new version of the Make Shortcut plugin, now called GimpScripter. It lets you point-and-click create a plugin that calls a sequence of plugins, PDB procedures, or macros. It is a plugin authoring tool. Gimpscripter is a Gimp plugin written in Python. It generates Python code for a plugin. The source is at github.com/bootchk/gimpscripter. Installation instruction are in the README file. The source includes many readable documents such as NEWS, TODO, and a user's manual. You can download a tarball or zip there. It is in Python so just install it in the standard Gimp directory for plugins, no compilation necessary. Gimpscripter is still in development. It usually works, but is incomplete and could be improved. Take a look if you are interested in scripting Gimp, as a user or as a programmer. Gimpscripter lets you visually (graphically, point-and-click) implement a sequential recipe, for example Choose this, set that parameter, choose that, ... It doesn't have any control flow statements. It uses a stack model: it hides a prefix of parameters and references them to active objects. It includes a macro facility and macros for common sequences of operations, and to wrap certain PDB procedures with higher-level parameter type, e.g. PF_BRUSH instead of PF_STRING for a brush. Some people suggest using a recorder/playback tool to automate Gimp. Scripts from such tools break when the Gimp GUI changes, and the scripts are not easily distributable. Gimpscripter is an alternative. Gimpscripter does have many weaknesses, some of which can be attributed to lack of support from the PDB. So it could help guide improvements to the PDB (but it might not raise any issues not already known, such as not storing defaults.) I welcome comments or contributions. Here is an example use, to make a plugin Stroke selection with selection: Choose Filter/Gimpscripter to start Gimpscripter. From the menu pane choose Edit/Copy. Choose Edit/Paste as/New Brush. Choose Select/To path. Choose Edit/Stroke/Path. Enter a name for the plugin, for example Stroke selection with selection. Choose the OK button. Read the summary and choose the OK button. Restart Gimp. Open an image and make a selection. Choose Shortcuts/Stroke selection with selection. You should see a mobius like effect. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU
[Gimp-developer] Announcing Gimpscripter plugin authoring tool, beta prototype
Announcing a new version of the Make Shortcut plugin, now called GimpScripter. It lets you point-and-click create a plugin that calls a sequence of plugins, PDB procedures, or macros. It is a plugin authoring tool. Gimpscripter is a Gimp plugin written in Python. It generates Python code for a plugin. The source is at github.com/bootchk/gimpscripter. Installation instruction are in the README file. The source includes many readable documents such as NEWS, TODO, and a user's manual. You can download a tarball or zip there. It is in Python so just install it in the standard Gimp directory for plugins, no compilation necessary. Gimpscripter is still in development. It usually works, but is incomplete and could be improved. Take a look if you are interested in scripting Gimp, as a user or as a programmer. Gimpscripter lets you visually (graphically, point-and-click) implement a sequential recipe, for example Choose this, set that parameter, choose that, ... It doesn't have any control flow statements. It uses a stack model: it hides a prefix of parameters and references them to active objects. It includes a macro facility and macros for common sequences of operations, and to wrap certain PDB procedures with higher-level parameter type, e.g. PF_BRUSH instead of PF_STRING for a brush. Some people suggest using a recorder/playback tool to automate Gimp. Scripts from such tools break when the Gimp GUI changes, and the scripts are not easily distributable. Gimpscripter is an alternative. Gimpscripter does have many weaknesses, some of which can be attributed to lack of support from the PDB. So it could help guide improvements to the PDB (but it might not raise any issues not already known, such as not storing defaults.) I welcome comments or contributions. Here is an example use, to make a plugin Stroke selection with selection: Choose Filter/Gimpscripter to start Gimpscripter. From the menu pane choose Edit/Copy. Choose Edit/Paste as/New Brush. Choose Select/To path. Choose Edit/Stroke/Path. Enter a name for the plugin, for example Stroke selection with selection. Choose the OK button. Read the summary and choose the OK button. Restart Gimp. Open an image and make a selection. Choose Shortcuts/Stroke selection with selection. You should see a mobius like effect. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Enhance PDB display new and delete so scripts don't abort in batch
This proposes enhancing PDB gimp_display_new() to successfully return a
null display when non-interactive, and enhancing PDB gimp_display_delete
to return success even for a null display.
Most scripts (Python and Scheme) that call gimp_display_new() abort the
script when run in batch mode. The proposed changes implement null
displays. Only the behavior changes, not the signature.
Probably no scripts will need to be changed, neither scripts distributed
with Gimp nor third party scripts. (Few use other than
gimp_display_new().)
The benefit of this change is that it simplifies plugin programming.
Plugin authors can worry less about the mode. Batch programmers can use
more plugins without regard for whether they call gimp_display_new().
(About ten Scheme plugins distributed with Gimp will cease to abort when
called in batch mode. Since the plugins don't return an image except to
display it, the plugins are not useful in batch mode, but the lack of a
return value from Scheme plugins is another issue.)
One disadvantage is that the error when a display cannot be created
(because of exhaustion of system resources) cannot be detected in a
script after this change. The error when a display cannot be created
because an invalid image is passed will still abort a script.
An alternative in Python is to bracket a call to gimp_display_new() with
try:except:, but there is no such alternative in Scheme.
The null display is similar to the null Linux device. The new, flush,
and delete display PDB operations will act on a null display, without
aborting, just as on a real display.
The other PDB operations on a null display:
gimp_display_is_valid() will return False on a null display,
gimp_display_reconnect will abort a script,
gimp_display_get_window_handle() will abort a script (on invalid
argument for the display.)
A patch is attached. It includes changes in display.pdb to
gimp_display_new() and gimp_display_delete().
From 218285d3cb532e01177616b3434654bd20e2ae14 Mon Sep 17 00:00:00 2001
From: Lloyd Konneker boo...@nc.rr.com
Date: Mon, 20 Sep 2010 19:59:46 -0400
Subject: [PATCH] Enhance PDB display new and delete so plugins don't abort in batch mode
---
tools/pdbgen/pdb/display.pdb | 22 +++---
1 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/tools/pdbgen/pdb/display.pdb b/tools/pdbgen/pdb/display.pdb
index 168cdfd..83e58c8 100644
--- a/tools/pdbgen/pdb/display.pdb
+++ b/tools/pdbgen/pdb/display.pdb
@@ -21,7 +21,7 @@ sub display_is_valid {
$help = 'HELP';
This procedure checks if the given display ID is valid and refers to an
-existing display.
+existing display. It returns False for the null display.
HELP
neo_pdb_misc('2007', '2.4');
@@ -52,8 +52,8 @@ sub display_new {
Creates a new display for the specified image. If the image already has a
display, another is added. Multiple displays are handled transparently by
GIMP. The newly created display is returned and can be subsequently destroyed
-with a call to gimp_display_delete(). This procedure only makes sense for use
-with the GIMP UI.
+with a call to gimp_display_delete(). This returns the null display
+if there is no UI.
HELP
std_pdb_misc;
@@ -81,10 +81,7 @@ HELP
if (gimp_image_get_display_count (image) == 1)
g_object_unref (image);
}
- else
-{
- success = FALSE;
-}
+ /* else return SUCCESS and the null display. */
}
CODE
);
@@ -97,20 +94,22 @@ sub display_delete {
This procedure removes the specified display. If this is the last remaining
display for the underlying image, then the image is deleted also. Note that
the display is closed no matter if the image is dirty or not. Better save
-the image before calling this procedure.
+the image before calling this procedure. Deleting the null display returns
+success.
HELP
std_pdb_misc;
@inargs = (
- { name = 'display', type = 'display',
+ { name = 'display', type = 'display', no_validate = 1,
desc = 'The display to delete' }
);
%invoke = (
code = 'CODE'
{
- gimp_delete_display (gimp, display);
+ if (display) /* If not the null display */
+gimp_delete_display (gimp, display);
}
CODE
);
@@ -123,7 +122,8 @@ sub display_get_window_handle {
This procedure returns a handle to the native window for a given image
display. For example in the X backend of GDK, a native window handle is
an Xlib XID. A value of 0 is returned for an invalid display or if this
-function is unimplemented for the windowing system that is being used.
+function is unimplemented for the windowing system that is being used
+or for the null display.
HELP
neo_pdb_misc('2005', '2.4');
--
1.7.0.4
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Include resynthesizer plugin in Gimp distribution?
This is a request to put the Resynthesizer plugin in the Gimp project. The author, Paul Harrison, has given me permission to maintain Resynthesizer. I am an unaffiliated computer scientist and have developed in C, Python, and Scheme under Unix, Linux, and MS Windows. I have studied the Resynthesizer code and created a short list of bug fixes, performance enhancements, and refactorings (breaking one large source file into many, and splitting the resynthesizer into an engine and a GUI.) If that's agreeable, I will learn Gimp development processes and create the proper make files etc before uploading a new version to the Gimp project. Also, internationalize where necessary. (But not recode to Gimp style?) The Resynthesizer package includes: the engine written in C++, with its own GUI of settings several plugins written in Scheme that call the engine: Smart enlarge Smart remove selection (now called Heal selection) I would like to include plugins that call the resynthesizer, by other authors: Uncrop - synthesizes a larger image, same perspective, wider view. Written by me. Fill resynthesized pattern - fills with a pattern, but a random texture instead of a regular tiling. Written by Rob A Currently the resynthesizer package is distributed by Debian and other organizations. I have corresponded with the Debian builder of resynthesizer, but he is not the maintainer and relies on the author's downstream source. I believe it is one of the most useful and popular plugin packages. Putting it in Gimp and getting the bugs fixed would help many users. I would be glad to provide more details. Lloyd Konneker ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Include resynthesizer plugin in Gimp distribution?
No benefit for me, doesn't matter to me which organization hosts it. But it makes it easier for the other distributing organizations if it is in Gimp: one less package. I suppose I could also maintain other plugins once I learned the ropes. I would prefer Python. I've done much exploring of the PyGimp code. Hate to say it but one benefit for the users is that if the Resynthesizer comes with the Gimp, then it comes with the MS Windows build of Gimp, which seems to be a frequent source of problems for Resynthesizer users. The main benefit argument is that the plugin is very useful and ought to be one of the core plugins. On Wed, 2010-05-19 at 23:49 +0200, Sven Neumann wrote: On Wed, 2010-05-19 at 10:03 -0400, lloyd konneker wrote: This is a request to put the Resynthesizer plugin in the Gimp project. The author, Paul Harrison, has given me permission to maintain Resynthesizer. Well, if you maintain the plug-in, that is very good. We really don't have enough resources to maintain more plug-ins in the GIMP tree. We would love to see even more plug-ins maintained outside the GIMP source tree. What would be the benefit for you and the core GIMP developers (and the users of course), if the plug-in was maintained in the GIMP source tree? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] User Friendly Plug-In Browser (Sven Neumann): Python plugin defaults accessible
On Mon, 2010-04-12 at 23:20 +0200, Avgoustinos Kadis wrote: Thanks Sven, very important to know that! How feasible are these options? 1. Randomly pick a value for each parameter. From what you said (that it depends a lot on the parameters) this wont give us the best results but at least we will have a preview. 2. Modify PDB so it can store default parameters and enter their values in the plug-ins (maintained in one place only)? Sven wrote: The latter is the only reasonable solution and it has been on the TODO for quite a while already. But IMO it goes way beyond the scope of a GSoC project. Lloyd responds: If the GSoC project was just to be a proof of concept, then you could get the defaults for a subset of plugins, namely some Python plugins, as follows: 1) make the patch to pygimp that allows Gimp to reimport plugins (small patch proposed earlier on this list, search under gimp_env_init.) 2) Python pseudo code snippet: for each python plugin filename in the standard directories: __import__( filename ) for procname in gimpfu._registered_plugins_.keys() params = gimpfu._registered_plugins_[procname][8] for param in params: default = param[3] In other words, reimporting a plugin sometimes calls its register() which creates a private structure in gimpfu that gives the registration parameters, including the defaults (and a range of reasonable values for some types of parameters.) Sometimes means: unless the call to register() is guarded by if __name__ = __main__ !!! The call to register() is a declaration: the convention should be that it NOT be guarded. The call to register() doesn't interact with Gimp. (This is more discussion about the proposed patch.) Not the way you would ultimately want to have defaults accessible, but it might help enable a transition to a more general solution. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Possible Future of ScriptFu/TinyFu: visual editors, action framework, sequences
I have posted a Make shortcut plugin to the Gimp Registry. It lets a user choose from a view of the menu tree of plugins, to create a new plugin (a script) that is a shortcut to a target plugin. It is very rudimentary, but could be extended into a visual editor of sorts, to create named sequences of actions. The visual editor (proposed here as a GSOC project: http://archives.free.net.ph/message/20100325.130320.3246ef1c.en.html ) seems too ambitious. Sequences are enough, represented by lines of text for menu items. Graphical pictures of flowcharts is not necessary, at least as a start. (A UNIX perspective: text is enough.) One problem is that the PDB does not give access to default parameters of plugins. It seems that defaults are maintained by the individual plugins, not by the PDB. I am not sure there is even a convention for storing default parameters. I saw one C-language plugin that stored default in the data attribute of PDB procedures. Pygimp plugins seem to store defaults using Python shelf. I haven't explored how Scheme scripts store defaults. A user of a visual editor would want the defaults. Another problem is that other menu items in GIMP (not plugins) are not exposed by the PDB. I have just started to explore, but it seems the actions (sequences) of other menu items in Gimp might be exposed in the XML for the other menus of Gimp. It would be much easier to create a visual editor if there was a uniform API for determining the actions of all Gimp menu items (not just the plugins.) I am not familiar with the action framework. I would appreciate a link. As to the implementation language, Python seems OK: plenty of support, portable, high level, objects. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] prototype Inspect plugin uploaded to Gimp registry, re gimp_env_init() abort
I uploaded a prototype of an Inspect plugin to the gimp registry. Refer to a previous thread about gimp_env_init() and a proposed patch. If I get encouragement and the proposed patch to GIMP-Python is approved, I might continue development. I think this plugin fits the Gimp practice of keeping documentation in the code. From the README file: A Gimp plugin that lets plugin programmers view documentation for PDB procedures, GIMP-Python modules, plugins and modules written in Python, and image data. The documentation is live, generated from the code itself and from the current state of GIMP and the PDB. Installation: Copy plugin-inspect.py and the inspector directory to your own, local plugin directory. Make plugin-inspect.py executable. See a comment in plugin-inspect.py for Linux commands. Version: This is an alpha version, a proof-of-concept, a work in progress. It works, and shouldn't crash. It is released for comments about the features and about the GUI. This alpha version asks: 1) whether Gimp Python plugin programmers need an inspector, a unified way to browse internals. 2) whether pydoc documentation for Gimp plugins and Gimp-Python is worthwhile. If so, Gimp needs to be patched to allow plugins to be reimported by pydoc without aborting with the message gimp_env_init() must only be called once. Refer to a discussion on gimp-dev mail list. You won't see the crash from this version since this version explicitly only documents a few plugins (itself) that are safe from this crash, i.e. that guard the call to main() so that it is only called if the script is imported at the top level. 3) whether to migrate HelpBrowse Plugins etc. from C to Python and Glade. Discussion: Uses Glade3 graphical GUI designer and pygtk (requires gtk+ 2.16). Duplicates the existing Gimp menu items HelpBrowse Plugins and HelpBrowse Procedures. Documents python language plugins and modules (including GIMP-Python) using the pydoc module (distributed with python, the official way to produce documentation from python code.) Its data driven. Other views of the data could be added, for example to view plugins by directory path. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init (David Gowers)
On Tue, Mar 2, 2010 at 2:58 PM, Sven Neumann s...@gimp.org wrote: On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote: I wonder if importing a plug-in from another plug-in is really something that we want to support. If the goal is to share code, then perhaps the code that is worth sharing should be factored out into a Python module that the plug-ins can import. Every Python program is also able to be a python module that plug-ins can import. We should preserve this feature of the language. (For example, one can implement an app with a comand line interface, and then just add a GUI in another file that uses the functions defined on the stand-alone first file). David Gowers wrote: I've considered this problem a fair bit, and my opinion is that if you want this functionality, you should simply guard your register()s. We cannot safely 'co-opt' python plugins that are not written with this functionality in mind, as they are designed to be run always in an independent process (hence they may do initialization which confuses the calling program, or vice versa); there is no modification to GIMP which could permit that, it is a logistical problem not a technical one. Allowing python plugins to make separate modules available on installation, similar to Sven's suggestion, seems to me the most practical suggestion. This means we would add two items to sys.path -- one the site modules* directory, and the other the modules* directory belonging to the specific user, which the installation of the plugin package could put modules into. We could further postulate that the normal python modules directory should be the destination of modules that do not require GIMP running in order to function, and only GIMP-requiring modules would be installed in it's modules* directory. I make this distinction because there are various good reasons not to install gimp-dependent modules in the global namespace (for example, pydoc and the general help() facility get confused because the imports of gimp modules fail.. so you can look up a specific module, but not search.) * I realize 'modules' is a term already used in the gimp directory structure. This is meant as a placeholder for something else...python-modules? I agree with Joao S. O. Bueno and disagree with David Bowers. Its better to make plugins meet the normal expectations of Python programmers (you can import any Python file to use pieces of it) than to add new conventions and directories for shared Python plugin code. Simpler is better? Often, authors don't plan their code will be useful to others. It's just serendipity. If authors don't plan to share code and put it in these new directories, it thwarts serendipitous reuse and experimentation. It is inconsistent for a duplicate call to register() to be harmless with a warning while a duplicate call to main() is fatal. Also, new conventions and directories does not solve my wish to call pydoc on plugins (which is not very important. I hope to download a prototype Inspect plugin to gimp registry soon.) But it illustrates that you can't always anticipate what people will want to do. Thanks ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init (David Gowers)
On Sat, 2010-03-06 at 08:41 +1030, David Gowers wrote:
On Tue, 2010-03-02 at 08:01 -0500, lloyd konneker wrote:
I agree with Joao S. O. Bueno and disagree with David Bowers.
Well, I'm glad you don't disagree with me, but who is that?
Sorry I mangled your name. BTW David Bowers is a famous
environmentalist, Sierra Club etc. Mr. Gowers was a pharmacist in the
movie Its a Wonderful Life. He boxed Jimmy Stewart up the side of the
head, like you did me. Just kidding.
Its better to make plugins meet the normal expectations of Python
programmers (you can import any Python file to use pieces of it) than to
add new conventions and directories for shared Python plugin code.
Simpler is better?
The normal expectations of Python programmers are that the main loop
will be guarded.
Granted.
This is exactly the thing that allows you to import otherwise
executable modules;
without it, no guarantees can be made that the code you are importing
will not interfere with global state in a way which causes your plugin
to crash. You can depend on a specific version of a plugin which has
known behaviour; In that case you prevent the user from upgrading that
plugin, and you rely on knowledge of the internals of that plugin,
which is very likely to get you into trouble if you ever need to
upgrade it.
The same principle applies to python scripts that are unguarded:
importing them will, at the least, have significant side effects.
Often they are entirely incapable of being cooperative.
Hence, it's not practical to import a plugin module unless it
specifically indicates that it is fit to be imported (by guarding the
main loop)
But Gimp shouldn't protect programmers from themselves. If they import
a plugin that is not fit, or create dependencies on versions, let them.
Often, authors don't plan their code will be useful to others. It's
just serendipity. If authors don't plan to share code and put it in
these new directories, it thwarts serendipitous reuse and
experimentation.
It is inconsistent for a duplicate call to register() to be harmless
with a warning while a duplicate call to main() is fatal.
Currently, the latter is serving the function of preventing the
previously mentioned possibility of side effects of importing a plugin
in this way.
If there is another way of preventing that problem, then we could look
at removing that aspect of main() calls.
Otherwise, we absolutely must not.
Also, new conventions and directories does not solve my wish to call
pydoc on plugins (which is not very important. I hope to download a
prototype Inspect plugin to gimp registry soon.) But it illustrates
that you can't always anticipate what people will want to do.
I wanted to do that too.
Just because you want to do something, doesn't mean it's wise to do so.
Calling pydoc on unguarded python modules is just as unpredictable as
importing unguarded python modules. Why? Because the way it gets the
documentation is by first importing the module in question.
Furthermore, all GIMP plugins' dependency on the 'gimp' (and/or
gimpfu, etc..) modules mean that even if they are in the module search
path, pydoc's attempt at importing them will fail (because the gimp
and gimpfu,etc.. modules are only available to Python scripts that are
being run by GIMP).Changing the mechanics of main() would not effect
that.
If you don't believe that, it's easy to check; set PYTHON_PATH to your
plugins directory (full, absolute path like
/home/llkk/.gimp-2.7/plugins), start Python, and try to import one of
those plugins as a module.
David
My Inspect plugin IS run by Gimp. Thus importing pydoc and invoking it
on plugins DOES work, as far as I can tell by my limited testing, with
the patch to Pygimp that I have proposed.
Also, you CAN invoke pydoc on the pygimp modules from an Inspect plugin
run by Gimp. It turns out not to be really useful, since the existing
documentation for pygimp is rather good.
IF you can't invoke pydoc on the command line on a plugin, it's not
because it can't find the pygimp modules (because you can set the path
so it will) but for the reason you described: they need Gimp running. I
really haven't tested it.
But this does seem to work: start Gimp, open the Python console, import
pydoc, and call pydoc.render_doc('gimp'). I believe this works even
without the patch under discussion. But pydoc.render_doc('colorxhtml')
crashes pyconsole lacking the patch under discussion.
My brain hurts.
Lloyd
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init
Yes, I will submit a proper patch. I'm new but I can figure it out. I mainly wanted to get feedback whether it was desirable. I'm not clear when a discussion of an enhancement should move to Bugzilla. More testing reveals other issues and test cases: First, most plugins have unguarded calls to register(), so importing some plugins from a plugin ends up reregistering a plugin, with a warning to stderr from the Gimp PDB but apparently harmlessly. I'm still exploring, eg whether the order in which plugins are loaded matters, whether the warning is only for local plugins, whether Gimp supports multiple registrations of different plugins from the same Python source, etc. Second, what paths to plugins are set when a plugin is invoked? Apparently only to local plugins, and not to plugins distributed with Gimp. So to import a distributed plugin from any plugin requires the importing plugin to extend the path. Not difficult but annoying. On Tue, 2010-03-02 at 08:49 +0100, Sven Neumann wrote: On Sun, 2010-02-28 at 17:18 +, Omari Stephens wrote: On 02/28/2010 02:43 PM, lloyd konneker wrote: ::snip? SNIP!:: Here is proposed addition for plug-ins/gimpmodule.c in pygimp_main() that I have lightly tested. Note it raises a warning (Python prints warning on stderr once, on the second call), not an exception. Note it compiles with a C90 warning about mixing declarations and code. Just move the variable declaration to the top of the function. We should strive to make the codebase compile with as few meaningful warnings as possible. Also, is that proper code style? No, it isn't. First of all, a gboolean should be used instead of an int and the code should use the macros TRUE and FALSE. And of course it should follow the GIMP coding style guidelines. We can certainly adjust the few lines ourselves. But it would make our life easier if you could submit a proper patch. Thanks, Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init
On Sun, 2010-02-28 at 11:23 +0100, Sven Neumann wrote:
On Sat, 2010-02-27 at 14:35 -0500, lloyd konneker wrote:
This is an enhancement request. Repeated calls to gimp_env_init should
yield warnings and not fatal errors. It has benefits for gimp plugins
written in Python.
Currently gimp_env_init() calls g_error (fatal) if called a second time.
Instead, pygimp_main(), which calls gimp_env_init(), should check
whether this is a repeated call and issue a warning then return an
error. (I'm not sure if any changes are needed for ScriptFu, whether
Pygimp should check the return from gimp_main and raise a warning
exception, etc.)
We would definitely have to change gimp_main() then as it must not be
called more than once. I have a bad feeling about doing this change.
Currently, you can't import a plugin from another plugin unless the
imported plugin guards the call to main() to prevent it from being
called unless this is a top level invocation:
if __name__=='__main__':
main()
It could be sufficient to have a convention for plugins to guard the
call to main(), but the convention is not usually followed. Or you could
have a convention that any shared code needs to be in a separate module
from the top plugin module, but again, that convention is not often
followed.
If you could import a plugin from within a Gimp plugin, then you could
share more code. You could use classes etc. from imported plugins. You
could also invoke the imported plugin's top function without invoking it
as a registered PDB procedure. Neither reason is compelling.
Importing a plug-in from within a GIMP plug-in only makes sense for
Python. So I would suggest that we seek for a solution that only
involves changes to the GIMP Python bindings but does not require a
change to libgimp or libgimpbase. I haven't looked at the code, but it
should be possible to deal with this in pygimp_main().
Sven
That seems reasonable.
Here is proposed addition for plug-ins/gimpmodule.c in pygimp_main()
that I have lightly tested. Note it raises a warning (Python prints
warning on stderr once, on the second call), not an exception. Note it
compiles with a C90 warning about mixing declarations and code.
if (query == Py_None) {
PyErr_SetString(pygimp_error, a query procedure must be
provided);
return NULL;
}
/* lkk 2010 begin enhancement*/
static int was_called_previously = 0;
if (was_called_previously) {
PyErr_WarnEx(PyExc_RuntimeWarning, main() should only be called
once, 1);
Py_INCREF(Py_None);
return Py_None;
}
else {
/* OK to set this here since following code either succeeds in
initializing plugin, or fails hard. */
was_called_previously = 1;
}
/* lkk 2010 end enhancement*/
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] enhancement: warnings instead of fatal error for duplicate calls to gimp_env_init
This is an enhancement request. Repeated calls to gimp_env_init should yield warnings and not fatal errors. It has benefits for gimp plugins written in Python. Currently gimp_env_init() calls g_error (fatal) if called a second time. Instead, pygimp_main(), which calls gimp_env_init(), should check whether this is a repeated call and issue a warning then return an error. (I'm not sure if any changes are needed for ScriptFu, whether Pygimp should check the return from gimp_main and raise a warning exception, etc.) Currently, you can't import a plugin from another plugin unless the imported plugin guards the call to main() to prevent it from being called unless this is a top level invocation: if __name__=='__main__': main() It could be sufficient to have a convention for plugins to guard the call to main(), but the convention is not usually followed. Or you could have a convention that any shared code needs to be in a separate module from the top plugin module, but again, that convention is not often followed. If you could import a plugin from within a Gimp plugin, then you could share more code. You could use classes etc. from imported plugins. You could also invoke the imported plugin's top function without invoking it as a registered PDB procedure. Neither reason is compelling. I am not that familiar with the gimp source. I am guessing that gimp_main() can't be called twice to avoid redundant io channels, and that gimp_env_init() is doing the guarding. But does it need to be fatal, is there any real harm done if they return a warning to the caller? Apparently not. I built a version of gimp in which gimp_main returned a warning on second invocations. It didn't seem to hurt gimp. Context: I was exploring whether you could use pydoc to document plugins. I tried to invoke the python pydoc module on a plugin from within another plugin, an 'inspector' plugin. Pydoc imports a module and introspectively documents it using the python inspect module. It fails to import (fatal error: gimp_env_init must only be called once) unless the call to main() is guarded. This enhancement fixes that problem. (You can't typically invoke pydoc as a command from the shell on a plugin because the shell environment typically does not include the path to the gimpfu module.) Documentation produced by pydoc might be of marginal use, and then only to programmers, and sometimes only if the plugin writer has provided docstrings, self documentation in the code. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
