[Gimp-developer] winicon.exe - libpng12.dll issue
OS Window XP Sp 2 Media Center Editioon I just compiled Gimp 2.3.19. During Startup and checking plugins the following message appears winicon.exe 'Der Prozedureinsprungspunkt png_set_add_alpha wurde in der DLL libpng12.dll nicht gefunden.' It is in German but I hope it is clear so far. If I use Gimp 2.3.18 (Installer version) I get the message the libpng12.dll was not found. It is a longer time so and I always 'fixed' this by using of an older libpng12.dll (GTK 2.8.x I believe) file which I put in my GTK folder. What could cause this? Heiko ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug 379150 noone cares about
Von: Heiko Schmidt [EMAIL PROTECTED] http://bugzilla.gnome.org/show_bug.cgi?id=379150 I wonder a bit why noone seems to pay attention to that bug. Sorry If this should be the wrong place (GTK issue) It is assigned to GTK+, so it's not surprising that no one here does pay attention. GTK+ bugs are not among the ones I browse regularly, for example. I can't reproduce this with GIMP 2.3.18. HTH, Michael -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] winicon.exe - libpng12.dll issue
Von: Heiko Schmidt [EMAIL PROTECTED] 'Der Prozedureinsprungspunkt png_set_add_alpha wurde in der DLL libpng12.dll nicht gefunden.' Is there more than one copy of libpng12.dll in PATH? Regards, Michael -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
On 7/26/07, Guillermo Espertino [EMAIL PROTECTED] wrote: Stephen: The Bezier tool is better suited to the tasks you're describing. Using freehand tool as a precision tool (i.e. for background extraction) is a bad idea. Freehand tool is intended to make coarse selections or tweaks in selections that don't need too much precision. I'd reccomend you this workflow for background extraction: -Draw a path along the edges of the shape that you want to extract, draw other paths for the holes (if you create them in the same path layer they are automatically combined with the other paths forming holes). -Turn path into selection -Add a mask channel based on that selection. So, imo, the existence of better tools for the same procedure makes this request questionable. If you ask me, I'd love to have the ability to apply boolean operations between different paths before seeing further work on the free selection tool. You can already do that. Right-click in the Paths dialog, all the standard operations (replace, add, subtract, intersect) are available. Unless you mean boolean operations that modify the paths themselves, rather than the selection. GIMP doesn't have that. Oh, btw. I'm experiencing some troubles with SIOX. In some images (I couldn't figure it out exactly when it happens) after the initial coarse selection the mask is displaced to the lower left of the image (with the right shape, but completely misaligned with the image) making it impossible to perform the extraction. Is that a known bug or it's just me? I thought this was a known bug that had already been fixed in SVN. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Bug 379150 noone cares about
Michael Schumacher mailto:[EMAIL PROTECTED] schrieb: It is assigned to GTK+, so it's not surprising that no one here does pay attention. GTK+ bugs are not among the ones I browse regularly, for example. I can't reproduce this with GIMP 2.3.18. HTH, Michael -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Gimp-developer mailing list mailto:Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer When I say noone cares about I don't mean only the people here I mean all - the users. Nobody seems to have this issue (this bug report is now more then 6 months old). Now if it is just a problem which only concerns my PC, my setup, what could cause this and what need I to do to get rid of it? Heiko ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
Guillermo, Thanks for taking the time to reply to my request. It appears that you and I have a fundamentally different point of view on how to best select regions in an image. Let me throw out a couple of observations before I address some of your points in the hope that I can avoid starting a religious argument about which technique is better (especially if my side is outnumbered). - In most applications most of the users focus on about 20% of the options and capabilities in a given tool whether it is an office tool, or an engineering Design Automation tool. I suspect this is true of almost any tool that is fairly flexible. This does not mean that the 80% that any one user doesn't normally use aren't valuable as different users solving different problems. - It is important that the work on an image has an intuitive feel. No one methodology or selection method works best across all of the images you might encounter. Users will develop favorite methods based on their own success and failures with features of a tool. Failure with a feature of a tool is not a reflection on the feature, it just points out that a variety of robust features are necessary for a well rounded tool. - The “enhancement” that I am asking for is for the current mode of operation to perform in a manner that would be expected by a reasonable user. When the user selects a mode of operation using the menu and switches, it seems reasonable for the tool to honor those choices rather than making a unilateral decision to change modes based on cursor location. The fact the behavior is called out in the specification doesn't really change the fact that it is kind of user unfriendly. Let me try and address your points: The Bezier tool is better suited to the tasks you're describing. Using freehand tool as a precision tool (i.e. for background extraction) is a bad idea. If I believed this I would not have bothered to ask for the enhancement in the first place. I think of using the freehand select for precision work as part of my methodology rather than a bad idea. When I started using Gimp I tried the Path / Bezier tool but in practice I really haven't found much use for it. The notion that it is “better” is subjective and is not in line with my experience. Freehand tool is intended to make coarse selections or tweaks in selections that don't need too much precision. This may have been the vision when the tool was put together, if it was I would say the Freehand select exceeded the original expectation. I believe that it is the best selection mode in Gimp for making precise selections. - How fine your control is for defining a selection line is determined by the level of zoom you are at, not whether you are drawing the line or defining it with a series of dots. The freehand select is as precise as the picture and tool will allow. - Describing a line with a series of dots is not inherently quicker or more precise than just drawing the line. If you have to start inserting more dots or fiddling with the handles to reshape the line, you are going to waste lots of time. The trick with Freehand select is to do a rough selection and then do the precise work using small closed strokes to add or subtract onto the selection. The feedback is immediate, and is easy to draw a precise line with the mouse as long as it is short. - The selection using a path matches the line in the path, which may be what we are referring to as precise, but this is actually due to the path selection being less flexible than a Freehand selection. In a Freehand select you can get a selection that matches the line you draw, just like the path select, if you turn of the “Feather edges”, but instead of being precise, it is precisely what I don't want. When you select people in your image without feathering the edge and paste them back on a background that has been blurred, they have a cut out with an exacto knife look. There may be a way to get feathered edges and antialiasing with the path tool, but this is still a problem because you can't see what you actually selected. The actual selection depends on the amount of feather (radius), the radius of curvature (shape) of the selection line. - The feedback from a freehand select is immediate. You can see what your selection is as you make it without having to wait until after you have completed a long path description. If you are able to feather the edges on a path, most likely with a time consuming post processing, it won't be the precise edge you described with the path. It might not fully include everything you want. - In my opinion the freehand tool is more intuitive for all but the very experienced user. Making the freehand select work the way most user's would expect would lower the learning curve for new users. The idea of adding to, subtracting from, or intersecting with the current selection is fairly straightforward and powerful. - The fact
[Gimp-developer] winicon.exe - libpng12.dll issue
Heiko Schmidt writes: I just compiled Gimp 2.3.19. 'Der Prozedureinsprungspunkt png_set_add_alpha wurde in der DLL libpng12.dll nicht gefunden.' What could cause this? Your executable is using another libpng12.dll than the one that corresponds to the import library you linked it against. You have some older version of libpng12.dll in the Windows system32 folder that you are not aware of? --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] winicon.exe - libpng12.dll issue
Michael Schumacher mailto:[EMAIL PROTECTED] schrieb: Von: Heiko Schmidt mailto:[EMAIL PROTECTED] Sorry Michael don't know what you man with in PATH PATH is an environment variable. Its value - -a list of directories - determines where programs and DLL files are searched when they are requested. What I noticed is, I have in the MinGW\bin folder a dll with the same name but very old (dated 19.09.2004) maybe this causes ´the problem? Yes, most likely. You did run GIMP 2.3 from the MSYS console, didn't you? HTH, Michael Ok thanks Michael, the evironment variable PATH is not unknown for me and now I know what you mean. In my case the PATH variable is set to C:\Mingw\bin and in that folder is as already mentioned a very old libpng12.dll. But the libpng12.dll which apparently caused the error message is inside of the gtk directory. As I told I replaced in the GTK directory the newer dll with the older one and the problem was solved but now the newer dll (in GTK 2.3.13 package) seems to work as well. Strange! Should I set up a new PATH variable pointing to the GTK\2.0 directory to avoid this error in the future? Heiko ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 2.3.19 development release
On 7/26/07, Nemes Ioan Sorin wrote: back to Gimp2.4 - Enhanced SIOUX tool (Detail Refinement Brush) will be on 2.4 ? Unfortunately it's not implemented yet. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 2.3.19 development release
It took us long enough to get 2.4 done. I don't worry too much about adoption at this point. Sooner or later everyone will update. Btw, about adoption Gimp became more and more important - 2.4 is long awaited - interested peoples will upgrade to 7.10 even only for Gimp 2.4 (if is a library problem) - I AM USING GUTSY FOR Gimp 2.3.18 (and 2.3.19 now). Feisty is not going to include GIMP 2.4 anyway. If we manage to release soon, then 2.4 will be in the next Ubuntu release though. And that release is likely going to use GTK+ 2.12 anyway. Gutsy already use GTK 2.11.6 and 2.3.18 work very well on Gutsy - not a single crash (and I use Gimp very intensive). -- 10 seconds off topic: 2 coworkers working with Avid for compositing, need to use Photoshop sometime to create TGA's or PNG's with transparecy for flying letters or images over the movies (commercials) - looking at my daily work - they starting to use Gimp to make transparent areas for export on TGA and PNG format.They like Gimp over Photoshop because is easy to cut, to select, to export and notable - what you see (on canvas) is what you import(on compositor). Photoshop and Photopaint export is problematic and sometime they got black areas instead of transparency(..yep forgetting to put a mask - they stuck in export dialogs on both Photoshop and Photopaint). Well, some peoples start to feel the difference ;) -- end of off topic back to Gimp2.4 - Enhanced SIOUX tool (Detail Refinement Brush) will be on 2.4 ? Sven Neumann wrote: Hi, On Wed, 2007-07-25 at 23:13 -0500, Tim Jedlicka wrote: Great! - looks like 2.4 is getting closer. Is there a hard dependency on GTK+ 2.10.13? Yes, there is. And it is there for a very good reason (bug #436242). I run Ubuntu 7.04 (Feisty) which unfortunately is still on libgtk2.0-dev 2.10.11. I know this isn't GIMP's issue, but if 2.4 is imminent then a dependency on GTK 2.10.13 might cause a delay in getting it out to at least one major distribution. I'm not clear how the upstream/downstream provider works out the dependencies but the 2.10.13 dependency MIGHT cause a delay in adoption of GIMP 2.4. Feisty is not going to include GIMP 2.4 anyway. If we manage to release soon, then 2.4 will be in the next Ubuntu release though. And that release is likely going to use GTK+ 2.12 anyway. It took us long enough to get 2.4 done. I don't worry too much about adoption at this point. Sooner or later everyone will update. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] winicon.exe - libpng12.dll issue
Von: Heiko Schmidt [EMAIL PROTECTED] Sorry Michael don't know what you man with in PATH PATH is an environment variable. Its value - -a list of directories - determines where programs and DLL files are searched when they are requested. What I noticed is, I have in the MinGW\bin folder a dll with the same name but very old (dated 19.09.2004) maybe this causes ´the problem? Yes, most likely. You did run GIMP 2.3 from the MSYS console, didn't you? HTH, Michael -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] ANNOUNCE: GIMP 2.3.19 development release
Hi, On Wed, 2007-07-25 at 23:13 -0500, Tim Jedlicka wrote: Great! - looks like 2.4 is getting closer. Is there a hard dependency on GTK+ 2.10.13? Yes, there is. And it is there for a very good reason (bug #436242). I run Ubuntu 7.04 (Feisty) which unfortunately is still on libgtk2.0-dev 2.10.11. I know this isn't GIMP's issue, but if 2.4 is imminent then a dependency on GTK 2.10.13 might cause a delay in getting it out to at least one major distribution. I'm not clear how the upstream/downstream provider works out the dependencies but the 2.10.13 dependency MIGHT cause a delay in adoption of GIMP 2.4. Feisty is not going to include GIMP 2.4 anyway. If we manage to release soon, then 2.4 will be in the next Ubuntu release though. And that release is likely going to use GTK+ 2.12 anyway. It took us long enough to get 2.4 done. I don't worry too much about adoption at this point. Sooner or later everyone will update. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
On 7/27/07, Stephen Kiel [EMAIL PROTECTED] wrote: Guillermo, Thanks for taking the time to reply to my request. It appears that you and I have a fundamentally different point of view on how to best select regions in an image. Let me throw out a couple of observations before I address some of your points in the hope that I can avoid starting a religious argument about which technique is better (especially if my side is outnumbered). - In most applications most of the users focus on about 20% of the options and capabilities in a given tool whether it is an office tool, or an engineering Design Automation tool. I suspect this is true of almost any tool that is fairly flexible. This does not mean that the 80% that any one user doesn't normally use aren't valuable as different users solving different problems. - It is important that the work on an image has an intuitive feel. No one methodology or selection method works best across all of the images you might encounter. Users will develop favorite methods based on their own success and failures with features of a tool. Failure with a feature of a tool is not a reflection on the feature, it just points out that a variety of robust features are necessary for a well rounded tool. - The enhancement that I am asking for is for the current mode of operation to perform in a manner that would be expected by a reasonable user. When the user selects a mode of operation using the menu and switches, it seems reasonable for the tool to honor those choices rather than making a unilateral decision to change modes based on cursor location. The fact the behavior is called out in the specification doesn't really change the fact that it is kind of user unfriendly. The 'enhancement' that you describe, in my experience, has been included in the GIMP for at least a year. I cannot reproduce the problem you describe (and for the purposes of getting this changed, you will probably need to come up with some reliable way of reproducing it.) Let me try and address your points: The Bezier tool is better suited to the tasks you're describing. Using freehand tool as a precision tool (i.e. for background extraction) is a bad idea. If I believed this I would not have bothered to ask for the enhancement in the first place. I think of using the freehand select for precision work as part of my methodology rather than a bad idea. When I started using Gimp I tried the Path / Bezier tool but in practice I really haven't found much use for it. The notion that it is better is subjective and is not in line with my experience. Freehand tool is intended to make coarse selections or tweaks in selections that don't need too much precision. This may have been the vision when the tool was put together, if it was I would say the Freehand select exceeded the original expectation. I believe that it is the best selection mode in Gimp for making precise selections. - How fine your control is for defining a selection line is determined by the level of zoom you are at, not whether you are drawing the line or defining it with a series of dots. The freehand select is as precise as the picture and tool will allow. That doesn't even make sense. The freehand tool and path tool have both exactly the same level of precision -- they both render polygons, so they're infinitely-precise; freehand can be faster if you have a steady hand; paths is more precise because it can draw shapes with holes in them in the same step as drawing the outside - freehand select must do such things in two steps, because it makes some assumptions about how the user wants to use it. Freehand select works under the exact same rules as path tool - including eg. what happens when a polygon self-intersects. The only difference is that freehand composes the path itself, so that you can select a complex shape with click+move... instead of one click per point as in paths selection. To demonstrate that, move your mouse in a circle with freehand select, and scribble through the circle before releasing the mouse button. - Describing a line with a series of dots is not inherently quicker or more precise than just drawing the line. If you have to start inserting more dots or fiddling with the handles to reshape the line, you are going to waste lots of time. I must point out that for simply-shaped selections, adjusting the path handles gives results of higher quality, faster. The trick with Freehand select is to do a rough selection and then do the precise work using small closed strokes to add or subtract onto the selection. The feedback is immediate, and is easy to draw a precise line with the mouse as long as it is short. Yes, agreed on all points here. Try using freehand select with a tablet though (if anyone you know has one you can borrow) -- it eliminates some of the complexities that you are describing, so that you can select an entire
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
On 7/26/07, Guillermo Espertino [EMAIL PROTECTED] wrote: David Gowers wrote: You can already do that. Right-click in the Paths dialog, all the standard operations (replace, add, subtract, intersect) are available. Unless you mean boolean operations that modify the paths themselves, rather than the selection. GIMP doesn't have that. Yes, I'm aware of that. I mean to perform boolean operations on the paths tehmselves. Well I think that GIMP should avoid doing that, and instead expect you to do it with inkscape; transfer of paths between the two programs is very simple and inkscape's just plain better at path editing. Anyway the current behaviour is functional (performing boolean operations on the selection using the paths layers as input) so this can be an interesting enhancement but not an urgent one. Actually, if you perform these operations on the selection and then convert the resultant selection back to a path, how does that work for you? I think, if GIMP got a better selection to path function (for example, the one that I made which uses PoTrace as a backend.), then this would work quite well for your purposes. Oh, btw. I'm experiencing some troubles with SIOX. I thought this was a known bug that had already been fixed in SVN. I'm having that problem in Gimp 2.3.18 and the fix is not announced in the latest realese. actually, it is.. 'Bug fixes' :) Yes, it really is. http://bugzilla.gnome.org/show_bug.cgi?id=448417 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] winicon.exe - libpng12.dll issue
Michael Schumacher mailto:[EMAIL PROTECTED] schrieb: Von: Heiko Schmidt mailto:[EMAIL PROTECTED] Is there more than one copy of libpng12.dll in PATH? Regards, Michael -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Gimp-developer mailing list mailto:Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer Sorry Michael don't know what you man with in PATH If I install the GTK package the dll is finally in C:\Programme\Gemeinsame Dateien\GTK. What I noticed is, I have in the MinGW\bin folder a dll with the same name but very old (dated 19.09.2004) maybe this causes ´the problem? because after I did replace the dll with old one in the GTK\2.0\bin folder the error message does not appear. Heiko ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Bug 379150 noone cares about
http://bugzilla.gnome.org/show_bug.cgi?id=379150 or noone can confirm this? I wonder a bit why noone seems to pay attention to that bug. I would like to know if someone can confirm this. For me is it a bit cumbersome because I use the 'save a copy' dialog very often but it concerns the save/save as dialog as well. Here again the bug report maybe a bit more precise: OS Windows XP SP2 -Select for example 'Save a copy' -you see in the 'Name' field the current file name - ok so -expand 'Browse for other folders' and select in 'Places' any folder Now the 'Name' field on top gets empty which I assume is wrong. -I browse through all the folder until I have the desired one. If there is already a file which I would like to overwrite I select the file - the file appears in the 'Name' field I press 'Save' - file is saved. If I want to save the file within a session again and I open the 'Save a copy' dialog the 'Name' field is empty. I can select the file again from the 'Name' list - no problem. But if the 'Browse for other folders' option is inactive I can only type in the file name and if I do this a list drops down which shows the file name multiple times and the list gets longer and longer which each Save action. Sorry If this should be the wrong place (GTK issue) but can anybody confirm this or is this just specific for my own setup / PC configuration. In the mean time I bought a new PC with Window Media Center Edition but the bug is still there. I would say this should be fixed because of upcoming Gimp 2.4 release. Heiko ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
David, Thanks for the reply. I am using the Windows version of 2.2.17. In this version the issue that I am having an issue with can be reproduced in any image by selecting the freehand select tool, draw a circle in the image creating a selection, press the subtract from current selection mode button, move the cursor inside the selected region, depress the mouse button to start defining the region you want to subtract, and when you move the mouse you move the selection as a floating section instead of defining what you want to subtract. If there is a fairly stable version of the tool that has a fix for the issue I am having, that would be great. Which version should I be using? Your comment See the Channels dialog -- that's exactly what it is for. for a providing a selection stack capability sounds interesting. Do you have a link or reference that elaborates on this? Thanks Stephen - Original Message From: David Gowers [EMAIL PROTECTED] To: Stephen Kiel [EMAIL PROTECTED] Cc: Guillermo Espertino [EMAIL PROTECTED]; gimp-developer@lists.xcf.berkeley.edu Sent: Thursday, July 26, 2007 5:37:29 PM Subject: Re: [Gimp-developer] Request for Change 0 Free Select Behavior On 7/27/07, Stephen Kiel [EMAIL PROTECTED] wrote: Guillermo, Thanks for taking the time to reply to my request. It appears that you and I have a fundamentally different point of view on how to best select regions in an image. Let me throw out a couple of observations before I address some of your points in the hope that I can avoid starting a religious argument about which technique is better (especially if my side is outnumbered). - In most applications most of the users focus on about 20% of the options and capabilities in a given tool whether it is an office tool, or an engineering Design Automation tool. I suspect this is true of almost any tool that is fairly flexible. This does not mean that the 80% that any one user doesn't normally use aren't valuable as different users solving different problems. - It is important that the work on an image has an intuitive feel. No one methodology or selection method works best across all of the images you might encounter. Users will develop favorite methods based on their own success and failures with features of a tool. Failure with a feature of a tool is not a reflection on the feature, it just points out that a variety of robust features are necessary for a well rounded tool. - The enhancement that I am asking for is for the current mode of operation to perform in a manner that would be expected by a reasonable user. When the user selects a mode of operation using the menu and switches, it seems reasonable for the tool to honor those choices rather than making a unilateral decision to change modes based on cursor location. The fact the behavior is called out in the specification doesn't really change the fact that it is kind of user unfriendly. The 'enhancement' that you describe, in my experience, has been included in the GIMP for at least a year. I cannot reproduce the problem you describe (and for the purposes of getting this changed, you will probably need to come up with some reliable way of reproducing it.) Let me try and address your points: The Bezier tool is better suited to the tasks you're describing. Using freehand tool as a precision tool (i.e. for background extraction) is a bad idea. If I believed this I would not have bothered to ask for the enhancement in the first place. I think of using the freehand select for precision work as part of my methodology rather than a bad idea. When I started using Gimp I tried the Path / Bezier tool but in practice I really haven't found much use for it. The notion that it is better is subjective and is not in line with my experience. Freehand tool is intended to make coarse selections or tweaks in selections that don't need too much precision. This may have been the vision when the tool was put together, if it was I would say the Freehand select exceeded the original expectation. I believe that it is the best selection mode in Gimp for making precise selections. - How fine your control is for defining a selection line is determined by the level of zoom you are at, not whether you are drawing the line or defining it with a series of dots. The freehand select is as precise as the picture and tool will allow. That doesn't even make sense. The freehand tool and path tool have both exactly the same level of precision -- they both render polygons, so they're infinitely-precise; freehand can be faster if you have a steady hand; paths is more precise because it can draw shapes with holes in them in the same step as drawing the outside - freehand select must do such things in two steps, because it makes some assumptions about how the user wants to use it. Freehand select works under the exact same rules as path tool - including eg.
Re: [Gimp-developer] Request for Change 0 Free Select Behavior
David Gowers wrote: You can already do that. Right-click in the Paths dialog, all the standard operations (replace, add, subtract, intersect) are available. Unless you mean boolean operations that modify the paths themselves, rather than the selection. GIMP doesn't have that. Yes, I'm aware of that. I mean to perform boolean operations on the paths tehmselves. Anyway the current behaviour is functional (performing boolean operations on the selection using the paths layers as input) so this can be an interesting enhancement but not an urgent one. Oh, btw. I'm experiencing some troubles with SIOX. I thought this was a known bug that had already been fixed in SVN. I'm having that problem in Gimp 2.3.18 and the fix is not announced in the latest realese. Can you confirm if that was actually addressed? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
