On Tuesday 03 April 2007 18:12, Steven Howe wrote:

Hello,
seems at least one question a day.
Close a window. How? I have the image object. What now?

You can only close a window for an image you had created yourself. You tell GIMP to close displays, and the only way you get hold of a display object is creating it itself. So, you can even create aditional displays for exsiting images (and close that ones), but ther ei sno way to close an image that was open prior to calling your plug-in.

Take a look at
pdb.gimp_display_new and pdb.gimp_display_delete

js ->

Steven Howe

Hi,

On 4/4/07, Steven Howe wrote:

OK. So far I've kept my opinions about the documentation and odd naming of features, but ...
Can't close a window?

This is simply hyperbole. It's perfectly sensible not to allow you (the plugin) to destroy something which others may still be referring to. The circumstances described are exactly those where you are definitely the only referrer. You can close a display in those circumstances. Also, presently there is fairly little that you can do with displays; maybe it would be good to be able to access them if you could, for instance, create an alternate display for the current image with 200% zoom and no rulers/scrollbars/statusbar/menubar -- I would like this for previewing. As it is, you can just create them or destroy them, nothing else.

And what is this difference of gimp. and

pdb.gimp_; are multiple poorly documented features really needed?

Nor are they present; the gimp.* are simply wrappers around pdb functions, almost always behaving the same way.

It's all a bit weird. PYGTK and PIL are much better

documented.

I found out that I couldn't even use the register(...) function in the py console. Now that's damn odd.

I thought so initially. In fact, the normal use of register() is when a plugin is being queried; you can't implement a plugin via the console because it is not an executable file, which all plugins are. Thus register has no possible meaning in the console.

The documentation is lacking. The pdb is mostly a good idea, but there

Certainly. Perhaps you'd consider doing something about that.

seems to be far too many types that

don't have access methods or methods. "image_id" and image; display numbers that can't be listed and referenced. Two names for an object; path based and name only. Interactive and batch. Assumption of called in variables (image, drawable run_able), instead of required. The first example I found 'clothify' used timg an tdrawable, as unused variables; then promptly call on globals variables I have know way of knowing exist. It's just bad programming methods. Where's the sense in that?

In other words, is there some 'reason' to have a pdb, but try to keep it's inner working secret? Is it just clumsy programming, transition between a working program and a good program?

No, it's a requirement of the kind of plugin architecture GIMP uses. Because there are plugins at all -- that requires some type of PDB. Then, there is the distinction between extensions and plugins, which imposes restrictions on behaviour.
The PDB is also deliberately language-agnostic; It would certainly be easier to write for one language, but for whatever reason, this choice was made. The requirement to support both C plugins and scripting languages creates this requirement. The PDB could do with an overhaul (named parameters, default values, varargs); what isn't in question is it's necessity.

I see no good reason, from a scripting point of view, that I shouldn't

have access to every property of an object. Open, close, see all it's

I think here, you are assuming that you are programming the GIMP. When you create a plugin, it is an executable that GIMP communicates with through pipes. There is no direct passing of objects; as such there is no way to modify any object's fields directly.

PyGimp's object types use the PDB to read and write values to specific object fields.

properties and operate on them, call menu items and preset their params.

I insist that presetting parameters programmatically is somewhere between a BAD IDEA and a CATASTROPHIC IDEA, mainly because of how confusing it can be to users.

Certainly programs without a scripting adjunct shouldn't have such

features. Ones with should. Everything I can do with a menu selection, I should be able to do with a script call; in fact hav e the pdb console have a trace function would be a damn fine idea.

I agree. By all means, make it so.

Py-gimp was mostly implemented by one person, and currently has one volunteer maintainer, who probably doe snot have that much free time to put into it, and me whoc an hack it around somehow - despite anyone beeing free to contribute.

The poor docuemtnationm is a direct result of that. The pdb has its authomatric docuemtnationa nd will suffice for most thigns. The methods that lie within objects like images do not have, indeed, any docuemtnation at all written, and it is very hard to find about then.

As you can see, this is a comunitary project, not some software you paid for and there is a hotline ready to fullfill you last wishes as an user (as I am pretty sure all major software vendors do!) However, here at least, you can use the idea of "if you want it well done, do it yourself": that mean - you can contribute wirting some docuemtation, hacking the code, and even pointing interesting features to be added.

I'd be a liar if I said I do not complain, several times each time I have to write a script, of about the samethings you do. Just last week, I was pretty shuhre all pdb fucntionality regarding to layer masks was not working - then I found out one such odditty. (And I made something, although minimal, to make the situation better in the future)

Most oddities around just where historically built witht he code, and there is just no man power around to either clean some of it up, or document it better. It is that simple.

As for access to every propertis of tthe objects: each property available for objects like "Image" have to be re-implemented on the python side, manually, as the only access the plug-in has to the gimp dore is throught the PDB, that just knows id-numbers for the objects (which actually lie inside the program core). So any missign properties have to be coded. It is easy to take a look at the code, even if you don't intend to have the gimp soruce dcode tree ontyour computer - there is a code browser feature in the gnome svn, jsust go to gimp/plug-ins/pygimp in the source tree.

As for not being able to close displays nto open for the plug-in, that is a different issue: it is a design decision in the GIMP itself. And it makes quite some sense for me - plug-ins are external programs to the gimp, and the program must behave well despite any plug-ins that run. Threfore, a plug-in is prevented of closign an image in which the user is working, for example.

On Wednesday 04 April 2007 04:18, Steven Howe wrote:

OK. So far I've kept my opinions about the documentation and odd naming of features, but ...
Can't close a window? And what is this difference of gimp. and pdb.gimp_; are multiple
poorly documented features really needed?

It's all a bit weird. PYGTK and PIL are much better documented.

Considered answered.

I found out that I couldn't even use the register(...) function in the py console. Now that's damn odd.

Never tried...but the fact is that the GIMP expects a registered plug-inj to lie in a phisical file in the disk, not a procedure in side the python interpreter. A new interpreter is called each time a python plug-in is called (and anyh functions you typed in the consel won't exist in the new interpreter instance). So, the register call wouold not work, indeed.

The documentation is lacking. The pdb is mostly a good idea, but there seems to be far too many types that don't have access methods or methods. "image_id" and image;

Anywhere where the use of image_id is needed is actually bug - shoud not be needed from within python.

display
numbers that can't be listed and referenced. Two names for an object; path based and name only. Interactive and batch. Assumption of called in variables (image, drawable run_able), instead of required. The first example I found 'clothify' used timg an tdrawable, as unused variables; then promptly call on globals variables I have know way of knowing exist. It's just bad programming methods. Where's the sense in that?

Already answered above.
The python plug-ins taht ship with GIMP are mostly not usefull copies of other plug- ins and are intended as examples. Feel free to make the code better and submit a patch for it at bugzilla.gimp.org

In other words, is there some 'reason' to have a pdb, but try to keep it's inner working secret? Is it just clumsy programming, transition between a working program and a good program?

Yes - the PDb is the wya the GIMP makes itself available forexternal programs. The python- OO access to things is built itself usng the PDB and is far from complete. And even when its done, the PDB should still be there so that newly added objects/methotds a re readly available in python.

I see no good reason, from a scripting point of view, that I shouldn't have access to every property of an object. Open, close, see all it's properties and operate on them, call menu items and preset their params. Certainly programs without a scripting adjunct shouldn't have such features. Ones with should. Everything I can do with a menu selection, I should be able to do with a script call;

Again, easier said than done. But you cna do __most__ things. Colisng a window is a design decision, as I said. There are somethings lacking on the pdb, and anyone is free to implement then and submit a patch.

in fact hav e the pdb console have a trace function would be a damn fine idea.

OK Done ranting.

sph

js
->t have the time I like to to contribute to then.