Without reading the
exact
description, you would have no idea whether it works on an image, a
layer, whether ir creates something new, etc.

It is unclear from
the name
whether it works on an active layer, or whether it creates a new
image/layer.

would not make sense for all plugins (for all plugins that require a open image ,so almost all) offer as output option

1 edit the active layer and/or
2 create new layer(s)
and/or
3 create a new image

i cannot imagine why those options (with first ,"edit active layer" as default) change from plugin to plugin ,script to script ,while all 3 are useful and i would be happy see them always available, as standard (and available as AND/OR option)

There is a reason?

(NOTE i may imagine a reason why not...but ,again, only for the few plugin that do not require a image open: ...if no image is open, there is no even a active layer so options 1,2 would not make sense in the context..correct, i agree.

Anyway great majority of plugins require a image, to the point that in Gimp almost all filters are greyed out if no image is open

i refer to those)

I may hope for a change?

--- Sab 8/8/09, gimp-developer-request@lists.XCF.Berkeley.EDU ha scritto:

Da: gimp-developer-request@lists.XCF.Berkeley.EDU Oggetto: Gimp-developer Digest, Vol 83, Issue 18 A: gimp-developer@lists.XCF.Berkeley.EDU Data: Sabato 8 agosto 2009, 21:00
Send Gimp-developer mailing list
submissions to
    gimp-developer@lists.XCF.Berkeley.EDU

To subscribe or unsubscribe via the World Wide Web, visit     https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer or, via email, send a message with subject or body 'help' to
    gimp-developer-request@lists.XCF.Berkeley.EDU

You can reach the person managing the list at     gimp-developer-owner@lists.XCF.Berkeley.EDU

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Gimp-developer digest..."

Today's Topics:

   1. Renaming scripts/plugins in a standard way (LightningIsMyName)
   2. more standard outputs(was Renaming scripts/plugins in a standard way )

----------------------------------------------------------------------

Message: 1 Date: Sat, 8 Aug 2009 15:17:46 +0300 From: LightningIsMyName
Subject: [Gimp-developer] Renaming scripts/plugins in a standard way
To: gimp-developer@lists.xcf.berkeley.edu Message-ID:
   
Content-Type: text/plain; charset=ISO-8859-1

Hello,

I have seen the question of how to give a name for a script/plugin in
many places, and most recently here: http://bugzilla.gnome.org/show_bug.cgi?id=588755#c10 Although there are no standard naming rules, I suggest that we styart
to use strict naming rules.

For example - script-fu-3dtruchet. Without reading the exact
description, you would have no idea whether it works on an image, a
layer, whether ir creates something new, etc. Another example plug-in-spheredesigner. It is unclear from the name
whether it works on an active layer, or whether it creates a new
image/layer.

Now, if we decide that this is "obvious" and that all plugins do work
on the same layer unless it was specified otherwise, then plug-in-film
for example, does not match with this standard (since it creates a new
image).

most gimp plug-ins should be renamed, to be plug-in-render-XXX,
plug-in-distort-XXX, script-fu-ctreate-XXX, etc. I know that this will
probably break hundreds of scripts and plugins, so it would be hard to
do. My suggestion (which is the only way in which I can see how no API
uses will be broken) is to allow from now on for each script/pattern
to register in two ways
1. The normal usual way
2. A "suuport old usage" way, which registers a script/plugin so it
won't be viewed in the procedure browser, but it would still be there.

A script which wasn't updated (or doesn't need updating) will continue
to show in the procedure browser, and scripts/plugins that use method
2. will be able to register procedures for "depreceated usage" by
registering to a "depreceated" procedure browser (the database of
procedures will be shared between the two procedure browsers, however
from now on the gui of the procedure browser will show only
non-depreceated functions unless specified to show both).

gimp_install_procedure will continue to work in the usual way, and
gimp_install_depreceated_procedure (this is the new suggested
function) will register a "depreceated" procedure. This way, we don't brake anything and it will make new plugin/script
writers start using the new procedures since they will see only the
new procedures.

Thoughts/Comments?

------------------------------

Message: 2 Date: Sat, 08 Aug 2009 17:38:20 +0200 From: Sven Neumann
Subject: Re: [Gimp-developer] Renaming scripts/plugins in a standard
    way
To: LightningIsMyName
Cc: gimp-developer@lists.xcf.berkeley.edu Message-ID:
Content-Type: text/plain

Hi,

On Sat, 2009-08-08 at 15:17 +0300, LightningIsMyName wrote:

I have seen the question of how to give a name for a

script/plugin in

many places, and most recently here: http://bugzilla.gnome.org/show_bug.cgi?id=588755#c10 Although there are no standard naming rules, I suggest

that we styart

to use strict naming rules.

I don't think that is necessary. The procedure name is just a unique
identifier. It doesn't have to follow a naming scheme. And we are only
creating lots of work and potential trouble if we start to rename our
procedures now.

For GIMP 3.0, where we don't have to care about strict backward
compatibility, it might make sense to introduce a stricter naming scheme
for procedures (if we still have that concept then).

Sven

------------------------------