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
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.<function> and pdb.gimp_<someotherfunciton>; are multiple
> poorly documented features really needed?
> It's all a bit <OK megabit> weird. PYGTK and PIL are much better
> 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.
> 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
> in fact hav e the pdb console have a trace function would be a damn
> fine idea.
> OK Done ranting.
as I said, feel welcome. I myself rant about alot of these things as
well, and don't have the time I like to to contribute to then.
Gimp-user mailing list