Re: [Gimp-developer] Script-Fu procedure blurb review
On Wed, 2 Aug 2006 [EMAIL PROTECTED] 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. -- Alan H ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Gimp Perspective Clone Tool
On 8/2/06, Pedro Alonso <[EMAIL PROTECTED]> wrote: Hi,I am developing Gimp Perspective Clone Tool in the context of SOC. - Now I have to develop a gui so the user may define the perspectiveplane in a similar way that they do via perspective tool. Using GimpTransformTool. I don't know how to do that :S - Another thing that also would be fine is that when you choose a brush instead you see a brush outline while you are not painting see apreview. I don't know if is possible to do that. I'd like this, but I think it's unrelated to vanishingpoint cloning.. I think it's been discussed before and it was concluded that it would be too slow/tricky until GEGL ws in use. The goal of that patch is to be included in version 2.6 of gimp, but Iencourage you to test it and give some feedback ;) Actually, I still haven't tried it -- mainly because of the UI issue. Initially, I would think that you could just have the user CTRL+click and drag to set the perspective. That would not handle many cases, but it would be enough to test with. Sadly, I don't understand enough of the way the UI works to be able to suggest a way to implement that. .. looking around, the right thing to investigate might be gimpdrawtool. you have, for example, gimp_draw_tool_draw_line, gimp_draw_tool_draw_handle. I got my ideas from tools/gimpvectortool.c: The user-interaction seems to be in gimp_vector_tool_button_press, gimp_vector_tool_button_release, gimp_vector_tool_motion, gimp_vector_tool_key_press, gimp_vector_tool_modifier_key, gimp_vector_tool_oper_update (not sure exactly how this one is supposed to work.) and the drawing of any tool-specific things (like the source cursor for the clone tool) is in gimp_vector_tool_draw. Most of those functions are pretty clear. I hope that helps. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] gimp_pixel_rgn_resize help
Hi everyone, I'm building a plugin to compare two images side-by-side with panning and zooming, and I'm having a bit of an issue with getting the zooming to work. The way I'm doing it is initalizing a pixel region with the width being (width of preview) / (zoom factor) and soforth. /* Snip */ map_1 = gimp_drawable_get (vals.map_id_1); gimp_pixel_rgn_init (&map_1_rgn, map_1, p1_x1, p1_y1, init_width, init_height, FALSE, FALSE); gimp_pixel_rgn_resize ( &map_1_rgn , p1_x1, p1_y1, p1_width, p1_height); gimp_drawable_preview_draw_region (GIMP_DRAWABLE_PREVIEW (preview), &map_1_rgn); /'* Snap */ p1_x1, p1_y1 are the coordinates of the top left point, p1_width and p1_height are the width and height of the preview window, init_width and init_height are the smaller coordinates of the pixel region that have been divided by the zoom factor. This isn't even close to working, and after going through the API documentation several times and gdb equally, I'm sure its being called, the only problem is that it isn't doing anything, it would be the same as initializing the region with the width and height of the preview pane. Thanks, Brohan ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
My apologies for my preceding post which merely quoted Michael Natterer; I was using a new mail editor and it apparently expects me to only TAB between header fields. Quoting Michael Natterer <[EMAIL PROTECTED]>: Unfortunatel not. You apparently diffed between modified scripts from 2.3 and original scripts from 2.2, therefore most of the patch is bogus :( I haven't done much with 2.3 as I was reluctant to upgrade my glib in the midst of another project that was important to me. I should be able to upgrade in the coming weeks. I am willing to effect the necessary changes to the 2.3 source once a consensus is reached on blurb phrasings. I would also eliminate all of the "non-blurb" changes at that time. ... 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. The next revision of the patch will not address any "non-blurb" issues; it was laziness on my part (and apparently ignorance of changes made in the dev branch) that I didn't remove my changes from this patch. 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. The important thing is to clearly and consistently distinguish selection masks from selection contents. It has been my experience that the vast majority of GIMP users (granted, neophytes) consider selections to be boolean. Any user who is aware of the true nature of selection masks will not be confused by a less precise terminology while those who are ignorant will likely be confused by the technically precise term. I agree that "selection outline" or "selection border" are better choices than "selection frame" and think that Toby Speight explained the reasons well. 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... Nor am I. The two methods that the GIMP currently uses for "alpha objects" would seem to be "alpha channel" (in the "Add layermask" dialog) and "alpha" (in the "Alpha to selection" command). I tend to think of the alpha channel as being the transparent portion of a layer (since a layer with no alpha channel is opaque) and am hoping that a more intuitive terminology can be determined. 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. I don't wish to cause any confusion with GtkWidgets but I see no difference between a pixmap generated for a webpage and one generated for a GUI. I had considered leaving out the part of the blurbs which stated "for a webpage" as this was not precise; but, again, users who are aware of the difference will not be confused by its inclusion whereas those who are not might likely be confused by its absence. You marked all menu paths for translation, which is wrong. They don't need to be marked any more. The revised patch will address this. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Gimp Perspective Clone Tool
Hi, Linear interpolation is now implemented. You can see some plots: http://pedroalonso.es/soc/persp_antialias.png http://pedroalonso.es/soc/persp_antialias2.png http://pedroalonso.es/soc/persp_antialias3.png The patch and the source code in html are also updated again to the server. The links to them are the same. Thanks, Pedro On 8/2/06, Pedro Alonso <[EMAIL PROTECTED]> wrote: Hi, I am developing Gimp Perspective Clone Tool in the context of SOC. Currently the status of the project is: - Paint Core ( /app/paint/gimpclonevanishing.c ) works fine but anti-aliasing is still not developed. Transform matrix is set in the code, so by now it only works with the test_image that I have also included in the zipped patch. Patch: http://www.pedroalonso.es/soc/PatchGimpCloneVanishing.zip Plot 1: http://www.pedroalonso.es/soc/persp.png Plot 2: http://www.pedroalonso.es/soc/persp2.png - The file where all the stuff is developed is /app/paint/gimpclonevanishing.c the other ones are the same that for clone tool by now. Source Code in html: http://www.pedroalonso.es/soc/gimpclonevanishing.html - Now I have to develop a gui so the user may define the perspective plane in a similar way that they do via perspective tool. Using GimpTransformTool. I don't know how to do that :S - Another thing that also would be fine is that when you choose a brush instead you see a brush outline while you are not painting see a preview. I don't know if is possible to do that. The goal of that patch is to be included in version 2.6 of gimp, but I encourage you to test it and give some feedback ;) Thanks, Pedro ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: Script-Fu procedure blurb review
On Wed, 02 Aug 2006 11:38:01 +0100, Toby Speight <[EMAIL PROTECTED]> wrote:
> 0> In article <[EMAIL PROTECTED]>,
> 0> saulgoode mailto:[EMAIL PROTECTED]> ("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
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
On Wed, 2006-08-02 at 01:46 -0700, [EMAIL PROTECTED] wrote: > Quoting Sven Neumann <[EMAIL PROTECTED]>: > > > 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 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Re: Script-Fu procedure blurb review
0> In article <[EMAIL PROTECTED]>,
0> saulgoode mailto:[EMAIL PROTECTED]> ("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?
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Script-Fu procedure blurb review
Quoting Sven Neumann <[EMAIL PROTECTED]>: 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. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
