Re: [Gimp-developer] proposal for better status bar messages (long)
Hi, On Fri, 2006-06-23 at 11:49 -0700, Carol Spears wrote: what is the purpose of a toggle that says Background? There is no toggle that says Background in the options of this tool. That's why I will not try to answer the rest of your mail. You would better look at the tool options again and stop annoying us with your unqualified mails. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
... AARRGH. Accidentally sent this to Sven instead of the list! Sorry Sven.On 6/23/06, David Gowers [EMAIL PROTECTED] wrote: The tool only does foreground extraction (hence its name). There's no toggle that would turn it into a background extraction tool. Makes sense, actually -- the characteristics of a background are less clearly defined than that of an object. Carol, your test subject is extremely uncooperative. Attempting to select the foreground and omit all else met with little success: http://img.photobucket.com/albums/v449/neota/tech/gimp/screenshot-2006-06-21-try.png I guessed from what Sven said, inverting the image colors first might help, and I was right. I made my second try by: * Inverting the image * Selecting the entire image in the initial 'lasso' pass. * Disabling 'Contiguous' * Setting L,a,b sensitivity to 0,707,555 respectively. (a,b was just a guess, but L was 0 to accommodate the harsh brightness contrasts of the widgets) * Switching to background mode * Scrawling a bit (~3 strokes) on the windows Overall it was quite straightforward, actually. http://img.photobucket.com/albums/v449/neota/tech/gimp/screenshot-2006-06-21-try2.png (selected areas marked in blueness -- the window 'shadow' got selected, but otherwise it seems quite satisfactory.) .. My experience above causes me to wonder if 'BGselect' could be made by inverting the L*a*b values before interpreting them; maybe something to try after 2.4. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
I guessed from what Sven said, inverting the image colors first might help, and I was right. I made my second try by: * Inverting the image * Selecting the entire image in the initial 'lasso' pass. * Disabling 'Contiguous' * Setting L,a,b sensitivity to 0,707,555 respectively. (a,b was just a guess, but L was 0 to accommodate the harsh brightness contrasts of the widgets) * Switching to background mode * Scrawling a bit (~3 strokes) on the windows Overall it was quite straightforward, actually. http://img.photobucket.com/albums/v449/neota/tech/gimp/screenshot-2006-06-21-try2.png (selected areas marked in blueness -- the window 'shadow' got selected, but otherwise it seems quite satisfactory.) .. My experience above causes me to wonder if 'BGselect' could be made by inverting the L*a*b values before interpreting them; maybe something to try after 2.4. I do not quite understand your problems. I am an aloof developer who has serious problems to understand user's problems. Please help me out, maybe I am misunderstanding something? So please do not get me wrong here. What one defines foreground or background is not a matter of the tool but a matter of the human being who is using the tool. I cut out the windows selecting them all with the lasso. See: http://www.gerald-friedland.de/tmp/multiwindow_sel.png Then I disabled contiguos because the Windows in this image are not connected (may be disconnected would be a better string?). Then I needed a few foreground strokes, mainly to select the KDE toolbar (or was it GNOME) and to include all the colors shown in this GIMP tool dialog. The result is then: http://www.gerald-friedland.de/tmp/multiwindow_cutout.png If you want to have the screen-background instead of the windows, use select/invert and you get the background instead of the foreground... No need to fiddle with color sensitivity? Greetings, Gerald -- Gerald Friedland Raum 164 Tel: ++49 (0)30/838-75134 Freie Universität Berlin Takustr. 9 http://www.gerald-friedland.org Institut für Informatik 14195 Berlin [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
.. I replied to the wrong address again; argh.On 6/24/06, David Gowers [EMAIL PROTECTED] wrote: On 6/23/06, Gerald Friedland [EMAIL PROTECTED] wrote: I do not quite understand your problems.I am an aloof developer whohas serious problems to understand user's problems. Please help me out, maybe I am misunderstanding something? So please do not get mewrong here.What one defines foreground or background is not a matter of the toolbut a matter of the human being who is using the tool. If you want to have the screen-background instead of the windows, use select/invert and you get the background instead of the foreground... As far as I know, foreground and background are still objectively different from the computer's point of view and our point of view; they have different characteristics. A background tends to be less detailed than a foreground; also, the definition of background is further muddied by the possibility of having multiple overlapping objects at different depths. You clearly understand the tool(and maybe the algorithym too) better than I. However, my basic point is that 'what is not foreground' may mean something quite different from 'what is background'; the only case in which this will be false is when all objects are all at the same depth. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On Fri, Jun 23, 2006 at 03:27:19PM +0200, Gerald Friedland wrote: I do not quite understand your problems. I am an aloof developer who has serious problems to understand user's problems. Please help me out, maybe I am misunderstanding something? So please do not get me wrong here. heh. What one defines foreground or background is not a matter of the tool but a matter of the human being who is using the tool. what is the purpose of a toggle that says Background? this was my expectation. i guess i would be an aloof user who refuses to try any longer to understand where the developers minds are at when they do things... when i toggled it from Foreground to Background, my expectation was to manage what was selected. it seems sort of silly now that i write about it. my goal was to make the parts i wanted to select be what was floated. perhaps a lot of the confusion would disappear if the background/foreground toggle disappeared. as i have considered it since using the tool, it makes sense to me that it makes no difference what is selected. however, the tool option is there. I cut out the windows selecting them all with the lasso. See: http://www.gerald-friedland.de/tmp/multiwindow_sel.png i honestly wrote this before looking at any of the urls. bad form. i will apologize if that is helpful. i am still somewhat stuck with the image in my mind of where the developers minds are though carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
Hi David! As far as I know, foreground and background are still objectively different from the computer's point of view and our point of view; they have different characteristics. A background tends to be less detailed than a foreground; also, the definition of background is further muddied by the possibility of having multiple overlapping objects at different depths. I see your point. The problem is that humans might have an intuition for background although it does not work for all pictures. If there were any objective difference between background and foreground then a foreground selection tool would exist with a hundert percent robustness and nobody would care about extracting manually or even semi-automatically because the entire problem would not exist. One could just use this objective criterion on any image without any user interaction and let the computer do the segmentation (even in batch mode). The reality is that there is no unique definition to distinguish foreground from background in every picture. You can prove this easily: Given a picture that consist of one white pixel and one black pixel. What is foreground now? Four possible answers: - None or Both pixels = No differentiation possible. Thanks, no further argumentation needed. - White = OK. You define all white pixels to be foreground. Given this definition of foreground, I won't have to show you millions of photographs where this definition does not work, will I? - Black. See white. - You give any other definition. This will not apply to the two-pixel checkerboard. = No unique definition for foreground or background exists that works for all all images. Sorry. You clearly understand the tool(and maybe the algorithym too) better than I. However, my basic point is that 'what is not foreground' may mean something quite different from 'what is background'; the only case in which this will be false is when all objects are all at the same depth. In this point you are right. As it is not clear what foreground and background is, it is well possible for a given picture, that a third, fourth, fifth class exists... SIOX is a heuristics and there are several assumptions behind it: 1.) The user wants to extract one object (one connected pixel area) or a set of objects (several connected pixel areas) of similar color structure [=foreground]. 2.) The foreground has an overall different color structure than the rest of the picture [=background]. 3.) The user provides the algorithm with information of the color structure of the background and gives a spatial hint where the foreground may reside. This is done by drawing the first lasso selection. Everything outside the lass is considered background. 4.) The user provides further information on the color structure of the foreground. This is done using the foreground brush marking. Then the SIOX algorithm classifies those pixels that are not background and not part of the foreground marking by comparing their perceptual similarity to these two classes. Further (foreground or background) markings can be added if SIOX' first guess wasn't satisfying. So given the heuristics defined by SIOX, background is the true opposite of foreground. If for some reason it might be hard to extract background with SIOX: Try to extract the foreground and invert the selection. However, because no unique definition of background or foreground exists, there will always be images where any automatic foreground extraction fails (even the one working in our brains). The good thing about SIOX is that it works better for more images than the other extraction tools that I know. Gerald -- Gerald Friedland Raum 164 Tel: ++49 (0)30/838-75134 Freie Universität Berlin Takustr. 9 http://www.gerald-friedland.org Institut für Informatik 14195 Berlin [EMAIL PROTECTED] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
Hi, On Thu, 2006-06-22 at 12:09 +0930, David Gowers wrote: It looks like there is a bug in the SIOX tool/gui that causes it to return to the foreground setting unexpectedly, until the Control key is first pressed, then it works as expected. That's not a bug. You cannot mark background unless you first have marked some foreground area. When you start, the whole image is considered background, so there's really no point in marking background areas. I suggest that you go to http://www.siox.org/ and read about the tool. It is somewhat unfortunate that one needs some basic understanding of the ideas behind SIOX in order to be able to make good use of the tool. But I don't see how this could be avoided. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
Hi, On Thu, 2006-06-22 at 00:08 +0200, Raphaël Quinet wrote: Anyway, my main argument is that it would be more consistent with the other tools: the other selection tools, the transform tools and the zoom tool only consider the state of the modifiers before the first click. Subsequent changes to the modifiers are ignored even if you spend quite some time modifying the selection, the transform parameters or the zoom area: only the initial state matters. All the other tools create the selection immidiately. All tools consider the state of the modifiers at the moment you create the selection. Whether that is the first click or not seems irrelevant to me. I actually made the wrong assumption once or twice with the iscissors: I wanted to add a new area to a selection so I pressed Shift before clicking on the first point, then added more points, closed the shape, clicked inside it and poof! my selection was gone. I naively thought that it would behave as described above and I did not press Shift for the final click. I lost my selection and I had no way to undo/redo this, except by re-selecting. But maybe I am the only one who has this expectation for the selection tools? I don't know. Only some usability tests could tell what is best... This wouldn't have happened to you if you have had a look at the cursor changes. BTW, does anyone object to removing the possibility of turning context dependant cursors off? They are very important and I can't really imagine that someone would want to work without them. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On Wed, 2006-06-21 at 15:36 -0700, Carol Spears wrote: i really tried to use siox this weekend. it is so confusing, i have no idea what to expect from it or if what happened to me was a bug. the default is foreground extraction. i wanted it to background extract and toggled this tool option. The tool only does foreground extraction (hence its name). There's no toggle that would turn it into a background extraction tool. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] proposal for better status bar messages (long)
Here is a proposal for improving the messages that are shown in the status bar. Such messages would be very useful for describing some hidden features of the paint tools (bug #124040) but also for the other tools. Basically, I followed this approach: anything that causes a tool to change its behavior (clicking, dragging or using some modifiers such as Ctrl and Shift) should be displayed or suggested in the status bar. Simon has already done that for the path/vector tool and I would like to apply that to all tools. Some of these different modes are already triggering changes in the cursor. However, this is not sufficient because some people may not see these different cursors and because the status bar messages are better for suggesting what modifiers could also be used. I consider the status bar messages to be a useful complement to these cursors. Note that these messages have to be short enough to fit in the status bar. They may not always fit if the image window is very narrow, but then the user who wants to read the messages can resize the window. The goal is to make the messages reasonably short so that they are entirely visible as often as possible. The suggestion to use some modifiers and the optional description of what these modifiers will do is put at the end of the message so that the essential parts are more likely to be visible. Also, some tools allow their mode to be changed permanently via the tool options and toggled temporarily via a modifier. For example, toggling between horizontal and vertical modes for the flip tool. A change in the tool option reverses the meaning of the modifier. The messages below suggesting (try Shift) or (try Ctrl) should probably be built dynamically depending on whether modifiers are pressed rather than depending on the mode of the tool (tool-op). And finally, most tools only consider the state of the modifiers before the first click for deciding to change their mode. This is the case for most selection tools (Shift/Ctrl for add/subtract/intersect), transform tools, zoom tool, etc. But there are some exceptions, such as siox and iscissors that only consider the modifiers after the area is defined. This has been discussed here a few days ago for the new selection tools. Below, I assume that the old behavior (modifiers considered only when starting) is the correct one because this is the one that brings the best consistency accross all tools. If you want to discuss this, please start a separate thread (new subject). PATH TOOL (app/tools/gimpvectortool.c) -- Most messages would remain unchanged, except that SHIFT would be replaced by Shift. For reference, here are the messages currently used, with the updated capitalization: Click to pick path to edit. Click to create a new path. Click to create a new component of the path. Click to create a new anchor. (try Shift) Click-Drag to move the anchor around. Click-Drag to move the anchors around. Click-Drag to move the handle around. (try Shift) Click-Drag to move the anchors around. Click-Drag to change the shape of the curve. (Shift: symmetrical) Click-Drag to move the component around. (try Shift) Click-Drag to move the path around. Click to insert an anchor on the path. (try Shift) Click to delete this anchor. Click to connect this anchor with the selected endpoint. Click to open up the path. Click to make this node angular. PAINT TOOLS (app/tools/gimppainttool.c) --- - When nothing has been drawn yet: Click to paint, or press Ctrl to pick a color. - After the first brush stroke: Press Shift to draw a straight line. (try Ctrl to pick a color) - While drawing a line (Shift pressed): distance Click to draw the line, try Ctrl for constrained angles. - While drawing a constrained line (Shift+Ctrl pressed): distance Click to draw the line. - While picking a color (Ctrl pressed): Click in any image to pick the foreground color. In these messages, distance is the distance shown as number followed by the current unit. For example, 123.4 pixels or 0.1234 m. Tools such as the eraser, convolve and smudge tools can also use these common messages, with some exceptions explained in their own sections below. It would be better to replace the verb draw by the appropriate action for the tool, if this is possible (I didn't check). For example: Press Shift to erase a straight line. COLOR PICKER (app/tools/colorpickertool.c) -- - While picking the foreground color: Click in any image to pick the foreground color. (try Ctrl, Shift) - While picking the background color: Click in any image to pick the background color. (try Shift) As mentioned above, the try messages would be different if the mode is changed permanently in the tool options (opposite meaning for Ctrl). RECTANGLE SELECTION
Re: [Gimp-developer] proposal for better status bar messages (long)
Hi, On Wed, 2006-06-21 at 21:22 +0200, Raphaël Quinet wrote: Here is a proposal for improving the messages that are shown in the status bar. Such messages would be very useful for describing some hidden features of the paint tools (bug #124040) but also for the other tools. Basically, I followed this approach: anything that causes a tool to change its behavior (clicking, dragging or using some modifiers such as Ctrl and Shift) should be displayed or suggested in the status bar. Simon has already done that for the path/vector tool and I would like to apply that to all tools. A little late to come up with that now. The status bar messages have been waiting for an update for quite a while now. But better late than never. If you want to see such messages in 2.4, hurry up, the string freeze is coming. RECTANGLE SELECTION (app/tools/gimpselectiontool.c, gimprectangletool.c) Some of the current status bar messages are defined in libgimpbase/gimpbaseenums.c. These messages are OK to describe the undo steps or for PDB help texts, but better messages should be used for the status bar messages. I would suggest that the selection tools are finished before status bar messages are being added. The current state is likely going to change and translators will go crazy if we change the messages over and over again. FOREGROUND EXTRACTION TOOL (app/tools/gimpforegroundselecttool.c) - The current messages are fine, except that I they should suggest to use Shift or Ctrl to add/subtract/intersect selections. Something like (try Shift+Enter, Ctrl+Enter) could be useful and accept the selection would be replaced by the appropriate action. However, for greater consistency with other tools I think that it would be better to consider the state of the modifiers _before_ the first click instead of when pressing Enter. That does IMO not make sense. The SIOX tool, just like the Intelligent Scissors tool requires the user to work on the selection outline for quite a while. It makes much more sense to respect the modifiers when the selection is actually created and that happens at the end, when the user confirms her work and presses Enter. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On Wed, 21 Jun 2006 22:45:55 +0200, Sven Neumann [EMAIL PROTECTED] wrote: On Wed, 2006-06-21 at 21:22 +0200, Raphaël Quinet wrote: [...] However, for greater consistency with other tools I think that it would be better to consider the state of the modifiers _before_ the first click instead of when pressing Enter. That does IMO not make sense. The SIOX tool, just like the Intelligent Scissors tool requires the user to work on the selection outline for quite a while. It makes much more sense to respect the modifiers when the selection is actually created and that happens at the end, when the user confirms her work and presses Enter. Users may have a different understanding of what is meant by when the selection is actually created. Or different expectations. We know that it is only done at the end. But I would not be surprised that many users would consider the first click to be when the selection is actually created -- they probably do not care about the difference between a solid outline and marching ants, or between a masked foreground/background and marching ants. They probably consider only when they start defining that selection. Anyway, my main argument is that it would be more consistent with the other tools: the other selection tools, the transform tools and the zoom tool only consider the state of the modifiers before the first click. Subsequent changes to the modifiers are ignored even if you spend quite some time modifying the selection, the transform parameters or the zoom area: only the initial state matters. I actually made the wrong assumption once or twice with the iscissors: I wanted to add a new area to a selection so I pressed Shift before clicking on the first point, then added more points, closed the shape, clicked inside it and poof! my selection was gone. I naively thought that it would behave as described above and I did not press Shift for the final click. I lost my selection and I had no way to undo/redo this, except by re-selecting. But maybe I am the only one who has this expectation for the selection tools? I don't know. Only some usability tests could tell what is best... -Raphaël ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On Thu, Jun 22, 2006 at 12:08:34AM +0200, Rapha?l Quinet wrote: Anyway, my main argument is that it would be more consistent with the other tools: the other selection tools, the transform tools and the zoom tool only consider the state of the modifiers before the first click. Subsequent changes to the modifiers are ignored even if you spend quite some time modifying the selection, the transform parameters or the zoom area: only the initial state matters. I actually made the wrong assumption once or twice with the iscissors: I wanted to add a new area to a selection so I pressed Shift before clicking on the first point, then added more points, closed the shape, clicked inside it and poof! my selection was gone. I naively thought that it would behave as described above and I did not press Shift for the final click. I lost my selection and I had no way to undo/redo this, except by re-selecting. But maybe I am the only one who has this expectation for the selection tools? I don't know. Only some usability tests could tell what is best... i really tried to use siox this weekend. it is so confusing, i have no idea what to expect from it or if what happened to me was a bug. the default is foreground extraction. i wanted it to background extract and toggled this tool option. it toggled itself back to foreground and it also could not see an honest line that was in the image. a dark brown/gray area that ended in a very straight line before a very bright (luminescent even) area started (which was the background i wanted to extract. it would not stay toggled and it seemed to be blind to the colors no matter what values i gave it. it only selected what i selected which, i could have used quickmask for and it would have been a lot less toggling and such. is the tool broken or are my expectations all wrong? i am honestly way to baffled to go to bugzilla with this even. it would be one heck of a status bar message to explain how to use this tool. also, the tooltips are popping up some freaking huge tool tips. it is the long help that is in the script-fu? i think it was some of the third party scripts i have installed that were doing this -- i did not find it at all helpful. is GIMP showing the help blurb or the about blurb from the scripts? carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
Carol Spears wrote: it would not stay toggled and it seemed to be blind to the colors no matter what values i gave it. it only selected what i selected which, i could have used quickmask for and it would have been a lot less toggling and such. is the tool broken or are my expectations all wrong? Can you provide and/or point out the image you tried it on? Michael -- GIMP http://www.gimp.org | IRC: irc://irc.gimp.org/gimp Wiki http://wiki.gimp.org | .de: http://gimpforum.de Plug-ins http://registry.gimp.org | ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On Wed, Jun 21, 2006 at 03:36:53PM -0700, Carol Spears wrote: also, the tooltips are popping up some freaking huge tool tips. it is the long help that is in the script-fu? i think it was some of the third party scripts i have installed that were doing this -- i did not find it at all helpful. is GIMP showing the help blurb or the about blurb from the scripts? http://carol.gimp.org/bikeshed/images/screenshot-2006-06-21.png fitting a whole tutorial into that area does not really seem as if it was the most helpful thing let me apologize to everyone whose little freesoftware project i have been involved in for how many years is it now? i really had to send mail out to say that $3000 was not worth it for a nice girl to get involved in something like how this project worked. if i am following the logic that i have received locally, i was one of the first people to have become successful with something like GIMP. $3000 would not have kept me from having real life problems like i did and do. it would have been the very very wrong thing to just let other girls or nice people fall into the same trap. it seems like california has all of the problems michigan did, just with gender removed. it is more wrong to use and discard people than it is to have been nice and unable to live up to those expectations. also, sorry if actually USING the software makes it difficult to report bugs with that language everyone insists on. the fact that i am using it and that i was successful with the project and the people when i had my life and stuff really ought to count for something. mostly i am sorry that this world does not allow a girl to be successful at something without spending the next few years trying to and maybe succeeding in destroying her. do you know what has not been in my life now since may of 2003? love. if there is no love in a life or in a project it is just going to suck for everyone. everywhere around me, love is bought and sold and traded or only used to make families. let me be somewhere where there is some love and maybe even my stuff and then feel free to complain if i am not being nice. no outlet for when there is a problem. no love. no acknowledgement. and the biggest problem is this. it really looks like a bunch of mean minded little males or malelike females who keep a calendar and know when to start being unreasonable. and there. this email is perhaps the best example of what is wrong when you fit a whole tutorial into what should be a small space. you can see from the screenshot that there are some real problems with this new thing. if i am to consider that the developers who work with this project are human beings and have real life issues that need consideration and also that whatever i expect from them is just my own idea and i should not actually expect anything -- when does that start from those same people back to me? in closing, one of the things that i really really remember from when everything started to go so badly and wrong is something that scizzo said. i am paraphrasing now: can we work next time as a team? i never ever wanted to be alone working on this stuff. never ever did i ever think that i could accomplish anything alone. who do i thank? carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On 6/22/06, Carol Spears [EMAIL PROTECTED] wrote: http://carol.gimp.org/bikeshed/images/screenshot-2006-06-21.png Okay. It looks like there is a bug in the SIOX tool/gui that causes it to return to the foreground setting unexpectedly, until the Control key is first pressed, then it works as expected. the 'Contiguous' option being off seems to be key in this case. I still can't get it to do quite what i tried to make it do. Anyway.. this is a dubious use of this particular tool; it was designed for use on photographic-type images, which your example is quite unlike. I've tried it on photographs and it generally performs pretty well. For this case I would have guessed immediately Fuzzy select would be the quickest route to success, and it did turn out that way: it took me ~45 seconds to select all the gradients without the lines or windows. Though, I suspect that you are tied up in your frustration and thereby preventing yourself from doing things effectively. Maybe you have a genuine grievance or maybe you're just behaving lazy. Personally, I've always found a workout(preferably involving approaching serious peril, and demanding enough to get adrenaline running) good to clear my head and sort out my feelings, decide on something. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for better status bar messages (long)
On Thu, Jun 22, 2006 at 12:09:24PM +0930, David Gowers wrote: On 6/22/06, Carol Spears [EMAIL PROTECTED] wrote: http://carol.gimp.org/bikeshed/images/screenshot-2006-06-21.png well, i did not use the tool on that image. that image is my desktop and what is wrong with some of the third party scripts with this new tooltip thingie. Okay. It looks like there is a bug in the SIOX tool/gui that causes it to return to the foreground setting unexpectedly, until the Control key is first pressed, then it works as expected. i appreciate that you tried to use the tool and can verify that it is returning to the foreground setting like that. the 'Contiguous' option being off seems to be key in this case. I still can't get it to do quite what i tried to make it do. Anyway.. this is a dubious use of this particular tool; it was designed for use on photographic-type images, which your example is quite unlike. I've tried it on photographs and it generally performs pretty well. For this case I would have guessed immediately Fuzzy select would be the quickest route to success, and it did turn out that way: it took me ~45 seconds to select all the gradients without the lines or windows. pathtool works the best for me. i want to write a tutorial for siox though so i have lately been trying to use this tool so that i can write one. it was suggested at the gimp convention that a tutorial should be written. you know how suggestions go, you try to take the good ones and ignore the wrong ones. at least, this is the approach i am trying to take. Though, I suspect that you are tied up in your frustration and thereby preventing yourself from doing things effectively. Maybe you have a genuine grievance or maybe you're just behaving lazy. Personally, I've always found a workout(preferably involving approaching serious peril, and demanding enough to get adrenaline running) good to clear my head and sort out my feelings, decide on something. heh. i think that you are probably right about this. the situation is wrong wrong wrong wrong wrong for adrenaline running in my life right now. all i can do is sit and count the wrongs about it. this in itself is very frustrating. thanks for the verification, carol ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
