RSS/Atom feed Twitter
Site is read-only, email is disabled

Renaming scripts/plugins in a standard way

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

2 of 2 messages available
Toggle history

Please log in to manage your subscriptions.

Renaming scripts/plugins in a standard way LightningIsMyName 08 Aug 14:17
  Renaming scripts/plugins in a standard way Sven Neumann 08 Aug 17:38
LightningIsMyName
2009-08-08 14:17:46 UTC (over 15 years ago)

Renaming scripts/plugins in a standard way

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?

Sven Neumann
2009-08-08 17:38:02 UTC (over 15 years ago)

Renaming scripts/plugins in a standard way

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