Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
Sven Neumann wrote: Hi, On Sat, 2007-12-08 at 17:51 +, William Skaggs wrote: 1) The most important is that the dialog should not go away after the Stroke button is pushed. It often takes several tries to get the settings right, and it is very annoying to have to bring the dialog back each time. The gain in usability would easily be worth the cost of an extra button-click to close the dialog, in my opinion. We don't do this kind of Apply thing anywhere in GIMP. I think it would be rather inconsistent and confusing if we start to do it for some dialogs. Since the dialog already remembers all settings, I don't really see what you want to achieve with this change. Perhaps it just needs to be made easier to bring up the dialog again? From a user perspective, I think the ideal solution would be to treat strokes on vectors similar to how Inkscape does it. For those not familiar with Inkscape, it works by attaching line and fill properties to the vector, which can be changed at any time. This is different from GIMP, which simply renders a stroke straight into pixels, which is somewhat less reversible. Unlike Inkscape however, GIMP should display the stroke and fill in pixels at all times, so the user can preview what the rastered result would look like and modify the vector accordingly. That is basically the reason I'm suggesting that it work this way. On many occasions, people really need to be able to see what a vector will look like filled and/or stroked while editing it. Here's a good example: suppose I have a vector with a horizontal or vertical line in it. Normally, you'd want the vector to fall right in the middle of the pixel row such that there is no ghost line occurring as a result of aliasing. Worst case scenario here is that you've put your vector right in between the two pixels and now you have a 2 pixel wide gray stroke instead of the 1 pixel black stroke you wanted. I realize this would be a lot of work to implement, but I'm putting it out there as a possible eventual goal and as my answer to the question of how to best solve this problem in the long run. 3) The Dash preset (or whatever it is called) control is by far the most important in the expander, and should be at the top. In fact, I think it should be out of the expander, since a user *always* wants to know what type of line will be rendered. My guess is that the user almost always wants a line. Using a dash pattern is rather uncommon, isn't it? But yes, perhaps moving it to the top would help. I agree with Sven that using a dash pattern is uncommon, and do prefer that the settings for that be hidden. Unless the line was changed from being solid to dashed before. Supposing that the dialog remembers the last settings, I think I'd like to see that my line is going to be dashed and not solid. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Developer-User Disconnect
Michael Schumacher wrote: Von: Daniel Falk [EMAIL PROTECTED] Also, if you are a user with a 1 time issue or question, subscribing to a mailing list is overkill, whereas signing up for a forum is easier and you don't get the mail volume. ... and this is the reason why so many questions are asked multiple times on forums. Not on forums that are administered well. I've seen forums that have strict rules against such things and that works surprisingly well. They also put sticky topics in the forums that appear on top that have frequently repeated questions. Even so, it's the ones who answer the questions who are most annoyed by seeing the same questions over again. For the user, the friendliest thing is to allow such questions, not that I'm advocating it. My point is that what works for the developers seems to be different from what works for the users. To the people who like mailing lists: what mail client do you like to use that handles mailing lists well? I would like to use one that lets me watch or ignore threads at least. That's probably the biggest gripe with them at the moment. I do assume that you should start looking for console-based ones, they are more likely to be used and influenced by people who prefer to work efficiently. mutt, maybe? I prefer to work efficiently with a gui actually (Don't laugh!). Anybody know of a good gui option? I might look at mutt for mailing lists though and see how it turns out. Thanks for the suggestion. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Feature request for a spot healing brush
On Mon, 2007-11-05 at 09:30 +0100, Sven Neumann wrote: Hi, On Sun, 2007-11-04 at 20:37 -0500, Daniel Falk wrote: Photoshop has a tool that works like the healing brush except that it doesn't require a source region to be specified before using the tool. When there are a lot of quick touch-ups to do, this is very convenient. Photoshop somehow guesses what it should use as source material and is often accurate. When it's not accurate, users can undo it, and then fall back on the healing brush and manually specify that information. Since we don't know how this works in detail, there is not much point in suggesting that we add such a feature. I could find a video for anyone interested, but that really wasn't my point. I suggested the feature not simply to ask for someone to copy photoshop in detail, but to solve the same problem that photoshop has managed to solve. Namely, figuring out an effective, efficient, and time-saving way of cleaning up a photo with a lot of marks or a dusty scan. In general I would like to point out that it is unlikely that any of the active core developers will pick up your feature requests. If you can find a developer who is interested in the algorithms and willing to work on this stuff, then we are very willing to give him/her a hand and guide him/her through the GIMP code and to review patches. But without a volunteer, this is likely to be just another feature requests. We already have several hundreds of them. Sven That's a shame, but I do understand there is a lot of work to be done on the gimp and only so much expertise to go around. Still, can it be logged as a valid feature request somewhere in the event that someone with the interest in improving the gimp might choose to implement this request? After all, I didn't just request it to scratch my own itch. I wanted to add my input into how the GIMP could improve. I wouldn't really know how to find a developer to work on this stuff. I would assume it's more likely that developers would come to you as core developers of the GIMP than to me after all. Thanks for your attention and all the hard work you guys do on the GIMP. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Feature request for a spot healing brush
Photoshop has a tool that works like the healing brush except that it doesn't require a source region to be specified before using the tool. When there are a lot of quick touch-ups to do, this is very convenient. Photoshop somehow guesses what it should use as source material and is often accurate. When it's not accurate, users can undo it, and then fall back on the healing brush and manually specify that information. It might be a better idea to make this an option to the healing tool rather than creating a separate tool, but the functionality this provides can save a lot of time and mouse strokes. So what do you think? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] momentary shortcut to the zoom tool?
There doesn't seem to be a way to temporarily switch to the zoom tool while a button is pressed. For example if I hold down ctrl + space, it would switch to the zoom tool, I could click-drag a rectangle to zoom, and let up on the ctrl + space, and it would switch back to the tool that was selected previously. I used this in photoshop all the time, so I can attest to its benefit. I realize there are shortcuts in the GIMP for zooming. The scroll wheel comes to mind, but zooming by dragging a rectangle is often much more useful for zooming in, and switching to the zoom tool by going over to the toolbox, clicking the zoom tool, then going back to draw the rectangle, then going back to the toolbox to re-select the previous tool, then back to the image to do the thing you were going to do... And I also realize there's a shortcut key for the zoom tool, but even then you have to switch back to the previous tool, which often requires a more difficult shortcut key than Z and probably a good memory too (there are over 30 different tools after all.) Another conceivable solution is simply to have a way to select the previous tool with an easy, left-handed shortcut. Doing that wouldn't be quite as simple for zooming as the momentary zoom idea, but on other occasions might be useful in its own right. What do you all think? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Patch tool for the GIMP
I'm afraid that I committed a little faux pas by prematurely posting this as a bug, but I was told to discuss the idea in the mailing list for the devs to decide whether they want to implement it. Here's the idea (as posted in my bug) what do you think? Photoshop's patch tool is very effective for larger areas that need healing. This is a request for a similar tool to be added to the Gimp. Patching works like this. The user selects the blemish and with the patch tool selected drags that selection to a source region that will replace what had been selected. Of course more than just a replace, it is a sort of blended replace that seems to resemble the way the healing brush would blend. Also as the user is dragging that selection to find a good area to clone from, the originally selected region updates with a somewhat blended view as a sort of preview. I say somewhat because I think it's a quicker algorithm that manages to update without taxing the cpu significantly. When the mouse button is release, the blend completes. Please see the reference video for a good example of how the tool works. http://video.about.com/graphicssoft/The-Patch-Tool.htm ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
