> 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@xxxxxxxxxxxxxxxxxxxxxx <gimp-developer-request@xxxxxxxxxxxxxxxxxxxxxx> ha scritto: > Da: gimp-developer-request@xxxxxxxxxxxxxxxxxxxxxx <gimp-developer-request@xxxxxxxxxxxxxxxxxxxxxx> > Oggetto: Gimp-developer Digest, Vol 83, Issue 18 > A: gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > Data: Sabato 8 agosto 2009, 21:00 > Send Gimp-developer mailing list > submissions to > gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > > 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@xxxxxxxxxxxxxxxxxxxxxx > > You can reach the person managing the list at > gimp-developer-owner@xxxxxxxxxxxxxxxxxxxxxx > > 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 <lightningismyname@xxxxxxxxx> > Subject: Renaming scripts/plugins in a > standard way > To: gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > Message-ID: > <e926d4dc0908080517y3569cccahbcf03a4f5a6f3f98@xxxxxxxxxxxxxx> > 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 <sven@xxxxxxxx> > Subject: Re: Renaming scripts/plugins in a > standard > way > To: LightningIsMyName <lightningismyname@xxxxxxxxx> > Cc: gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > Message-ID: <1249745900.21310.5.camel@bender> > 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 > > > > > ------------------------------ > > _______________________________________________ > Gimp-developer mailing list > Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx > https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer > > > End of Gimp-developer Digest, Vol 83, Issue 18 > ********************************************** > _______________________________________________ Gimp-developer mailing list Gimp-developer@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
