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

Script-Fu procedure blurb review

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.

21 of 21 messages available
Toggle history

Please log in to manage your subscriptions.

Script-Fu procedure blurb review Sven Neumann 21 Jun 22:50
  Script-Fu procedure blurb review saulgoode@brickfilms.com 22 Jun 09:53
   Script-Fu procedure blurb review Sven Neumann 22 Jun 20:31
  Script-Fu procedure blurb review saulgoode@brickfilms.com 25 Jun 00:34
   Script-Fu procedure blurb review Sven Neumann 27 Jun 09:04
    Script-Fu procedure blurb review Kevin Cozens 28 Jun 07:17
     Script-Fu procedure blurb review Sven Neumann 28 Jun 07:51
     Script-Fu procedure blurb review Alan Horkan 28 Jun 11:16
      Script-Fu procedure blurb review Sven Neumann 29 Jun 19:16
       Script-Fu procedure blurb review Alan Horkan 01 Jul 12:59
        Script-Fu procedure blurb review Sven Neumann 05 Jul 21:44
   Script-Fu procedure blurb review Alan Horkan 27 Jun 17:02
    Script-Fu procedure blurb review Sven Neumann 27 Jun 19:16
  Script-Fu procedure blurb review saulgoode@brickfilms.com 02 Aug 10:46
   Script-Fu procedure blurb review Toby Speight 02 Aug 12:38
    Script-Fu procedure blurb review Raphaël Quinet 02 Aug 14:55
   Script-Fu procedure blurb review Michael Natterer 02 Aug 13:36
   Script-Fu procedure blurb review Alan Horkan 03 Aug 02:56
Script-Fu procedure blurb review saulgoode@brickfilms.com 27 Jun 14:09
  Script-Fu procedure blurb review Sven Neumann 27 Jun 19:14
  Script-Fu procedure blurb review saulgoode@brickfilms.com 28 Jun 16:03
Sven Neumann
2006-06-21 22:50:26 UTC (almost 18 years ago)

Script-Fu procedure blurb review

Hi,

a while ago we went over all plug-ins, reviewed the procedure blurbs and marked them for translation. The blurbs are shown in the image status bar and as menu tooltips. This hasn't happened for Script-Fu yet, even though the script procedure blurbs are shown in the status bar as well. Thus, we need to do the same for all scripts. Any volunteers for this job? This should happen real soon now, because we want to enter string freeze for 2.4 as soon as possible. Your help would be very much appreciated.

Sven

saulgoode@brickfilms.com
2006-06-22 09:53:52 UTC (almost 18 years ago)

Script-Fu procedure blurb review

I would be willing to spend some time on this; although I am unfamiliar with what the previous work on other plugins was about. In particular, I do not know what "marked them for translation" means (if this is referring to some type of foreign language translation then I am most likely a poor choice).

I am fairly familiar with Script-fu and the PDB but I am not at all familiar with XML or .po files.

Quoting Sven Neumann :

a while ago we went over all plug-ins, reviewed the procedure blurbs and marked them for translation. The blurbs are shown in the image status bar and as menu tooltips. This hasn't happened for Script-Fu yet, even though the script procedure blurbs are shown in the status bar as well. Thus, we need to do the same for all scripts. Any volunteers for this job? This should happen real soon now, because we want to enter string freeze for 2.4 as soon as possible. Your help would be very much appreciated.

Sven Neumann
2006-06-22 20:31:04 UTC (almost 18 years ago)

Script-Fu procedure blurb review

Hi,

On Thu, 2006-06-22 at 00:53 -0700, saulgoode@brickfilms.com wrote:

I would be willing to spend some time on this; although I am unfamiliar with what the previous work on other plugins was about. In particular, I do not know what "marked them for translation" means (if this is referring to some type of foreign language translation then I am most likely a poor choice).

I am fairly familiar with Script-fu and the PDB but I am not at all familiar with XML or .po files.

Marking for translation in the context of Script-Fu only means prefixing the string with an underscore. That will cause it to be added to the strings that have to be translated. You won't have to deal with the translation at all.

It would help however if you had a look at the procedure blurbs in the plug-ins so that you get an idea of the style of strings that we would like to see as blurbs.

You are a native english speaker, aren't you? That makes you a very good choice for this job and we would very much appreciate your help with this.

Sven

saulgoode@brickfilms.com
2006-06-25 00:34:52 UTC (almost 18 years ago)

Script-Fu procedure blurb review

I estimate that I am about 15% finished on this task and that it will take me another two weeks to complete. Would this be sufficient for your scheduling needs?

At the end of this message is a sample change of the registration for the "3dTruchet.scm" script. I do not know if there is another way to provide the proper formatting (without the blurb being a single, long string on one line in the source) and so I have made the line-breaks "hard-coded". Where I have placed them may be dependent upon my GTK+ settings and therefore a different solution (including no line breaks in the source) may be preferable.

I have tried various approaches -- "\n" in the string, "\" at the end of the source line, et cetera -- all to no avail. If a suggestion is made on how to make SIOD handle this situation better, I probably possess the knowledge to generate a patch to the interpreter to affect it.

I would also wish to take this opportunity to make some modifications to the scripts (while still maintaining their previous behavior and PDB interface). As an example, for the 3dTruchet I would like to initially set the generated image to "clean". It seems unnecessary to prompt for "save" when closing an unmodified logo; the logo can easily be regenerated with the same values by re-running the script.

Also, for the 3dTruchet script I would like to move the globally defined functions (center-ellipse, use-tile, and create-tile) so that they are defined locally. This is very important so that there is no name-space conflicts between scripts.

Please let me know if I am on the right track.

----------- The registration blurb for 3dTruchet script:

(script-fu-register "script-fu-3dtruchet" _"3_D Truchet..." _"This script generates a repeating pattern of Truchet tiles (which are randomly oriented quadrants of a circle). The arcs of the tiles are given a 3-D effect using a gradient of the specified colors. The resulting size of the image is determined by a combination of the tile size and the total number of tiles." "Adrian Likins " "Adrian Likins" "1997"
""
SF-ADJUSTMENT _"Block size" '(64 5 1000 1 10 0 1) SF-ADJUSTMENT _"Thickness" '(12 2 100 1 10 0 1) SF-COLOR _"Background color" '(255 255 255) SF-COLOR _"Start blend" '(0 0 0) SF-COLOR _"End blend" '(255 255 255) SF-TOGGLE _"Supersample" TRUE SF-ADJUSTMENT _"Number of X tiles" '(5 1 1000 1 10 0 1) SF-ADJUSTMENT _"Number of Y tiles" '(5 1 1000 1 10 0 1))

Sven Neumann
2006-06-27 09:04:42 UTC (almost 18 years ago)

Script-Fu procedure blurb review

Hi,

On Sat, 2006-06-24 at 15:34 -0700, saulgoode@brickfilms.com wrote:

I estimate that I am about 15% finished on this task and that it will take me another two weeks to complete. Would this be sufficient for your scheduling needs?

That would be sufficient but I am afraid that you misunderstood the task that I am asking you to do. You will see that the actual task is quite a bit less work.

The registration blurb for 3dTruchet script:

_"This script generates a repeating pattern of Truchet tiles (which are randomly oriented quadrants of a circle). The arcs of the tiles are given a 3-D effect using a gradient of the specified colors. The resulting size of the image is determined by a combination of the tile size and the total number of tiles."

That's nice, but the task is to come up with a short string that must fit into a single line and is oriented towards the user, not towards a script programmer. The string will be visible in the status bar when browsing the menus. Something like the following would be appropriate for your example:

"Generate a repeating pattern of Truchet tiles"

Please have a look at the plug-ins. We have done this there already and the script-fu blurbs should match that style.

Sven

saulgoode@brickfilms.com
2006-06-27 14:09:29 UTC (almost 18 years ago)

Script-Fu procedure blurb review

Sven Neumann stated:

I am afraid that you misunderstood the task that I am asking you to do.

For what it's worth, I did examine the plug-ins but they have two "blurb" strings available (one for the status line and one for the plugin's Help dialog) whereas Script-fus seem to only have the one. I had mistakenly assumed that the intent was to have a more complete description appear in the script's Help dialog.

I understand now what is expected (and certainly a single line blurb will be much easier to produce).

Alan Horkan
2006-06-27 17:02:29 UTC (almost 18 years ago)

Script-Fu procedure blurb review

On Sat, 24 Jun 2006 saulgoode@brickfilms.com wrote:

Date: Sat, 24 Jun 2006 15:34:52 -0700 From: saulgoode@brickfilms.com
To: gimp-developer@lists.XCF.Berkeley.EDU Subject: Re: [Gimp-developer] Script-Fu procedure blurb review

initially set the generated image to "clean". It seems unnecessary to prompt for "save" when closing an unmodified logo; the logo can easily be regenerated with the same values by re-running the script.

I've considered this before, it would probably be a good idea. The only reason I could come up with as to why you might want to mark the image as dirty/modified was in cases where there was a stack full of undo steps the user might want to play with. I generally prefer to allow easier modification of things laterby providing seperate layers.

Sven Neumann
2006-06-27 19:14:24 UTC (over 17 years ago)

Script-Fu procedure blurb review

Hi,

On Tue, 2006-06-27 at 05:09 -0700, saulgoode@brickfilms.com wrote:

For what it's worth, I did examine the plug-ins but they have two "blurb" strings available (one for the status line and one for the plugin's Help dialog) whereas Script-fus seem to only have the one. I had mistakenly assumed that the intent was to have a more complete description appear in the script's Help dialog.

Yes, unfortunately the Script-Fu API only has a single string for this purpose. I thought about changing it in one way or another (backwards-compatible of course). But since only a handful of scripts did actually provide useful help, I decided that we better use that string for a short blurb. More detailed help should probably go into the user manual instead.

Sven

Sven Neumann
2006-06-27 19:16:23 UTC (over 17 years ago)

Script-Fu procedure blurb review

Hi,

On Tue, 2006-06-27 at 16:02 +0100, Alan Horkan wrote:

initially set the generated image to "clean". It seems unnecessary to prompt for "save" when closing an unmodified logo; the logo can easily be regenerated with the same values by re-running the script.

I've considered this before, it would probably be a good idea. The only reason I could come up with as to why you might want to mark the image as dirty/modified was in cases where there was a stack full of undo steps the user might want to play with. I generally prefer to allow easier modification of things laterby providing seperate layers.

Yes, it is propably a good idea. But can we please focus on one issue? I would really like to get a patch that only changes the blurbs and marks them for translation. Other changes will be considered, but please submit them separately.

Sven

Kevin Cozens
2006-06-28 07:17:58 UTC (over 17 years ago)

Script-Fu procedure blurb review

Sven Neumann wrote:

On Sat, 2006-06-24 at 15:34 -0700, saulgoode@brickfilms.com wrote: The registration blurb for 3dTruchet script:

_"This script generates a repeating pattern of Truchet tiles (which are randomly oriented quadrants of a circle). The arcs of the tiles are given a 3-D effect using a gradient of the specified colors. The resulting size of the image is determined by a combination of the tile size and the total number of tiles."

That's nice, but the task is to come up with a short string that must fit into a single line and is oriented towards the user, not towards a script programmer. The string will be visible in the status bar when browsing the menus. Something like the following would be appropriate for your example:

"Generate a repeating pattern of Truchet tiles"

Is there a particular need for these blurbs to be short one liners other than making things easier for the translaters? I don't think they should be shortened to the extent that information useful to users might get lost. The example above loses the fact that it is a repeating pattern of 3D Truchet files.

One option would be to move the longer blurbs in to the comments at the top of the script files to preserve any information in the blurbs which might be useful to users of the scripts (such as any restrictions for entered values).

Sven Neumann
2006-06-28 07:51:19 UTC (over 17 years ago)

Script-Fu procedure blurb review

Hi,

On Wed, 2006-06-28 at 01:17 -0400, Kevin Cozens wrote:

Is there a particular need for these blurbs to be short one liners other than making things easier for the translaters?

Yes, they need to fit into the statusbar and should follow the same style that plug-ins use for the blurb.

One option would be to move the longer blurbs in to the comments at the top of the script files to preserve any information in the blurbs which might be useful to users of the scripts (such as any restrictions for entered values).

If this information was available, it should of course not be thrown away but should be moved to a comment. But since almost no script provides such information, that's an academic question.

Sven

Alan Horkan
2006-06-28 11:16:41 UTC (over 17 years ago)

Script-Fu procedure blurb review

On Wed, 28 Jun 2006, Kevin Cozens wrote:

That's nice, but the task is to come up with a short string that must fit into a single line and is oriented towards the user, not towards a script programmer. The string will be visible in the status bar when browsing the menus. Something like the following would be appropriate for your example:

"Generate a repeating pattern of Truchet tiles"

Is there a particular need for these blurbs to be short one liners other than making things easier for the translaters? I don't think they should be

Plugins have both a short summary description ("blurb") be and a longer more descriptive help. It might be worth making things consistent and doing the same for scripts.

saulgoode@brickfilms.com
2006-06-28 16:03:45 UTC (over 17 years ago)

Script-Fu procedure blurb review

I agree that it would be desirable to have the help descriptions be more informative but I will focus on the one-line blurbs for now. I am working on the "g"s now.

After I have finished the one-liners, I will look into having Script-fu parse the help text into a 1-line "text" and a multi-line "blurb" (it looks like this is handled in "plugins/script-fu/script-fu-interface.c"). I would think that it could easily be handled while still maintaining backwards compatibility.

Sven Neumann
2006-06-29 19:16:33 UTC (over 17 years ago)

Script-Fu procedure blurb review

Hi,

On Wed, 2006-06-28 at 10:16 +0100, Alan Horkan wrote:

Plugins have both a short summary description ("blurb") be and a longer more descriptive help. It might be worth making things consistent and doing the same for scripts.

As I already explained, we can't easily do that without breaking backwards compatibility. And since almost no plug-in provides a useful help string, it makes a lot of sense to clean up the short strings now. Other changes can be considered after 2.4.

Sven

Alan Horkan
2006-07-01 12:59:29 UTC (over 17 years ago)

Script-Fu procedure blurb review

On Thu, 29 Jun 2006, Sven Neumann wrote:

Date: Thu, 29 Jun 2006 19:16:33 +0200 From: Sven Neumann
To: Alan Horkan
Cc: gimp-devel
Subject: Re: [Gimp-developer] Script-Fu procedure blurb review

Hi,

On Wed, 2006-06-28 at 10:16 +0100, Alan Horkan wrote:

Plugins have both a short summary description ("blurb") be and a longer more descriptive help. It might be worth making things consistent and doing the same for scripts.

As I already explained,

Only read your message after I had sent mine.

we can't easily do that without breaking backwards compatibility.

The switch over to Tiny-Fu will result in a certain amount of incompatibilities anyway so it might be a good time to reconsider.

it makes a lot of sense to clean up the short strings now. Other changes can be considered after 2.4.

CVS will still have the long descriptions if anyone wants to go back and add then in again.

Sven Neumann
2006-07-05 21:44:44 UTC (over 17 years ago)

Script-Fu procedure blurb review

Hi,

On Sat, 2006-07-01 at 11:59 +0100, Alan Horkan wrote:

The switch over to Tiny-Fu will result in a certain amount of incompatibilities anyway so it might be a good time to reconsider.

We are most likely not going to do the switch to Tiny-Fu until those incompatibilities have been sorted out. There might be some scripts that will stop to work when Script-Fu is changed to use the tiny-fu interpreter, but those scripts can basically be considered broken already. Broken because they are using undocumented misbehaviour of the SIOD interpreter.

it makes a lot of sense to clean up the short strings now. Other changes can be considered after 2.4.

CVS will still have the long descriptions if anyone wants to go back and add then in again.

Now you are forcing me to repeat myself again. There are basically no scripts in CVS that have a long description. The scripts are merely undocumented. If more than five scripts would use anything longer than half a sentence as their help string, we would of course not throw it away.

Sven

saulgoode@brickfilms.com
2006-08-02 10:46:43 UTC (over 17 years ago)

Script-Fu procedure blurb review

Quoting Sven Neumann :

a while ago we went over all plug-ins, reviewed the procedure blurbs and marked them for translation. The blurbs are shown in the image status bar and as menu tooltips. This hasn't happened for Script-Fu yet, even though the script procedure blurbs are shown in the status bar as well. Thus, we need to do the same for all scripts. Any volunteers for this job? This should happen real soon now, because we want to enter string freeze for 2.4 as soon as possible. Your help would be very much appreciated.

Sorry that I took so long. I have generated a patch (against 2.2.12) which I hope is close to what was expected. It is available as a plain text file at
http://flashingtwelve.brickfilms.com/GIMP/Bugzilla/patch-script-fu-new-blurbs (160kb) or available as a GZIPped file at http://flashingtwelve.brickfilms.com/GIMP/Bugzilla/patch-script-fu-new-blurbs.gz (27kb).

Even if I didn't completely screw it up, I imagine there will be some discussion. I have many doubts about my wording myself. Some issues as I see them:

1. There are unfortunately some changes in the patch that are not related to the blurbs: I made these changes in order to get the scripts to function and forgot to back out the changes when I generated the patch. It mostly concerned the 'gimp-layer-set-lock-alpha' being deprecated and I replaced it with 'gimp-layer-set-preserve-trans'. It also occurred when there was an out-dated usage of "SF-COLOR" as a text string (e.g., "white"). I understand that this is not proper update policy but I am not keen on undoing something that has to eventually be done.

2. In a couple of places I employed the term "selection frame" in order to differentiate operations that affected the selection mask versus those that affected the selection's contents (e.g., 'script-fu-selection-rounded-rectangle' is described as "Round the corners of the current selection frame"). I feel that "selection frame" is more intuitive than "selection mask" in these contexts.

3. Many scripts will operate on the non-transparent portion of the active layer (i.e., where the alpha channel is not BLACK) if there is nothing selected. I have termed these "alpha objects" and consistently employed the phrase "an alpha object or selection" to describe this situation. If a better terminology is proposed to describe this, it should be a simple matter to change these using "sed".

4) I do not understand what is happening with the 'script-fu-gap-dup-continue' portion of the patch. I only changed the blurb but for some reason the entire file is shown as added lines. (The patch works, I just don't understand why.)

5) I do not understand what is occurring with "SF-GRADIENT" in the 'script-fu-lava' registration. Other "SF-GRADIENT"s create a gradient selection widget while 'script-fu-lava' still presents a text-entry.

6) I used the word "widget" in some of the descriptions of scripts which generate webpage components. I am comfortable with its usage in this sense but perhaps others are not. So long as the reason for avoiding the term "widget" has nothing to do with The Apple Company's opprobrious attempt to usurp this otherwise ubiquitous computing term, I am open to suggestions. :-)

7) Finally, the menu registration is per 2.2.12 and therefore the scripts' relocation in 2.3 needs to be addressed by someone familiar with their new locations.

Toby Speight
2006-08-02 12:38:01 UTC (over 17 years ago)

Script-Fu procedure blurb review

0> In article ,
0> saulgoode ("saulgoode") wrote:

saulgoode> 2. In a couple of places I employed the term "selection saulgoode> frame" in order to differentiate operations that affected the saulgoode> selection mask versus those that affected the selection's saulgoode> contents (e.g., 'script-fu-selection-rounded-rectangle' is saulgoode> described as "Round the corners of the current selection saulgoode> frame"). I feel that "selection frame" is more intuitive saulgoode> than "selection mask" in these contexts.

Other ideas: "selection boundary", "selection bounds", "selection outline", "selection edge". Do any of these make more sense?

saulgoode> 3. Many scripts will operate on the non-transparent portion saulgoode> of the active layer (i.e., where the alpha channel is not saulgoode> BLACK) if there is nothing selected. I have termed these saulgoode> "alpha objects" and consistently employed the phrase "an saulgoode> alpha object or selection" to describe this situation. If saulgoode> a better terminology is proposed to describe this, it saulgoode> should be a simple matter to change these using "sed".

"Opaque" is the natural opposite of "transparent". Does that help here?

saulgoode> 4) I do not understand what is happening with the saulgoode> 'script-fu-gap-dup-continue' portion of the patch. I saulgoode> only changed the blurb but for some reason the entire saulgoode> file is shown as added lines. (The patch works, I just saulgoode> don't understand why.)

Wild guess, without looking at it - line-end conversion?

Michael Natterer
2006-08-02 13:36:38 UTC (over 17 years ago)

Script-Fu procedure blurb review

On Wed, 2006-08-02 at 01:46 -0700, saulgoode@brickfilms.com wrote:

Quoting Sven Neumann :

a while ago we went over all plug-ins, reviewed the procedure blurbs and marked them for translation. The blurbs are shown in the image status bar and as menu tooltips. This hasn't happened for Script-Fu yet, even though the script procedure blurbs are shown in the status bar as well. Thus, we need to do the same for all scripts. Any volunteers for this job? This should happen real soon now, because we want to enter string freeze for 2.4 as soon as possible. Your help would be very much appreciated.

Sorry that I took so long. I have generated a patch (against 2.2.12) which I hope is close to what was expected.

Unfortunatel not. You apparently diffed between modified scripts from 2.3 and original scripts from 2.2, therefore most of the patch is bogus :(

It is available as a plain
text file at
http://flashingtwelve.brickfilms.com/GIMP/Bugzilla/patch-script-fu-new-blurbs (160kb) or available as a GZIPped file at http://flashingtwelve.brickfilms.com/GIMP/Bugzilla/patch-script-fu-new-blurbs.gz (27kb).

Even if I didn't completely screw it up, I imagine there will be some discussion. I have many doubts about my wording myself. Some issues as I see them:

1. There are unfortunately some changes in the patch that are not related to the blurbs: I made these changes in order to get the scripts to function and forgot to back out the changes when I generated the patch. It mostly concerned the 'gimp-layer-set-lock-alpha' being deprecated and I replaced it with 'gimp-layer-set-preserve-trans'.

It's 'gimp-layer-set-preserve-trans' that is deprecated, and gimp-layer-set-lock-alpha' is the new function.

It also occurred when there was an out-dated usage of "SF-COLOR" as a text string (e.g., "white").

Likewise. "white" is the new version, '(255 255 255) the old one.

I
understand that this is not proper update policy but I am not keen on undoing something that has to eventually be done.

2. In a couple of places I employed the term "selection frame" in order to differentiate operations that affected the selection mask versus those that affected the selection's contents (e.g., 'script-fu-selection-rounded-rectangle' is described as "Round the corners of the current selection frame"). I feel that "selection frame" is more intuitive than "selection mask" in these contexts.

But "selection mask" is the known term here. "selection frame" is imho totally unusual and will confuse people.

3. Many scripts will operate on the non-transparent portion of the active layer (i.e., where the alpha channel is not BLACK) if there is nothing selected. I have termed these "alpha objects" and consistently employed the phrase "an alpha object or selection" to describe this situation. If a better terminology is proposed to describe this, it should be a simple matter to change these using "sed".

I'm not sure about this...

4) I do not understand what is happening with the 'script-fu-gap-dup-continue' portion of the patch. I only changed the blurb but for some reason the entire file is shown as added lines. (The patch works, I just don't understand why.)

GAP scripts are not part of gimp and should be patched separately.

5) I do not understand what is occurring with "SF-GRADIENT" in the 'script-fu-lava' registration. Other "SF-GRADIENT"s create a gradient selection widget while 'script-fu-lava' still presents a text-entry.

6) I used the word "widget" in some of the descriptions of scripts which generate webpage components. I am comfortable with its usage in this sense but perhaps others are not. So long as the reason for avoiding the term "widget" has nothing to do with The Apple Company's opprobrious attempt to usurp this otherwise ubiquitous computing term, I am open to suggestions. :-)

I haven't heared the word "widget" in the context of a web page. Actually, in GTK+ world it's pretty clearly reserved for GtkWidgets.

7) Finally, the menu registration is per 2.2.12 and therefore the scripts' relocation in 2.3 needs to be addressed by someone familiar with their new locations.

You marked all menu paths for translation, which is wrong. They don't need to be marked any more.

Sorry, but the patch as-is is unfortunately unapplyable. What is needed is a patch against a recent 2.3 version, or preferrably CVS HEAD.

ciao,
--mitch

Raphaël Quinet
2006-08-02 14:55:28 UTC (over 17 years ago)

Script-Fu procedure blurb review

On Wed, 02 Aug 2006 11:38:01 +0100, Toby Speight wrote:

0> In article ,
0> saulgoode ("saulgoode") wrote:

saulgoode> 2. In a couple of places I employed the term "selection saulgoode> frame" in order to differentiate operations that affected the saulgoode> selection mask versus those that affected the selection's saulgoode> contents (e.g., 'script-fu-selection-rounded-rectangle' is saulgoode> described as "Round the corners of the current selection saulgoode> frame"). I feel that "selection frame" is more intuitive saulgoode> than "selection mask" in these contexts.

Other ideas: "selection boundary", "selection bounds", "selection outline", "selection edge". Do any of these make more sense?

I would go for "selection outline" or "selection edge".

It looks like most users think about the outline of the selection rather than its contents. This can easily be explained by the fact that the outline (the marching ants) is the only visible part of the selection (without quickmask).

From a technical point of view, referring to the selection as a mask is more

appropriate especially for heavily feathered selections for which the outline is taken arbitrarily at 50%. But even if "selection mask" would be more appropriate, it may be less confusing to use "selection outline" because this is understood immediately and there is less risk of confusion with other terms like layer mask, channels and maybe future clipping masks, etc.

The terms "selection bounds" should be avoided because of the confusion with the function gimp_selection_bounds() which returns the bounding box of the selection instead of the selection itself.

I did a quick google match between these terms with the following results (in square brakets you have the numbers for gimp + "selection " and for photoshop + "selection "):
- "selection outline" [1050/609] is the most popular combination of terms for gimp users but not for photoshop users. It is found in tutorials, various articles, in the manual, etc. - "selection mask" [565/830] is mainly used by gimp developers and by photoshop users. For gimp, "selection mask" can be found in the archives of this mailing list, in scripts and in the PDB. - "selection boundary" [478/648] is used in the book Grokking the GIMP, in some tutorials and in archives of this mailing list. - "selection frame" [350/631] is used mainly in the context of XSane, in the new manual (gimp-help-2) and in a number of false positives from RPM(?). - "selection edge" [154/1150] is not used much in the gimp context but is the most popular term for photoshop users. For gimp, it can be found in the old manual (GUM) and in the new one (gimp-help-2).

-Raphael

Alan Horkan
2006-08-03 02:56:15 UTC (over 17 years ago)

Script-Fu procedure blurb review

On Wed, 2 Aug 2006 saulgoode@brickfilms.com wrote:

Even if I didn't completely screw it up, I imagine there will be some discussion. I have many doubts about my wording myself. Some issues as I see them:

2. In a couple of places I employed the term "selection frame" in order to differentiate operations that affected the selection mask versus those that affected the selection's contents

The selection contents is the image or the drawable. No new terminology needed.