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.<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 > 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 -><- 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 Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user