On 4/4/07, Steven Howe <[EMAIL PROTECTED]> 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.<function> and
pdb.gimp_<someotherfunciton>; 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 <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.

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.
Gimp-user mailing list

Reply via email to