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] proposal for usability enhancements for Stroke dialog
From: Daniel Falk [EMAIL PROTECTED] 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. Daniel, You're asking for what we call vector shapes or vector layers. That's a longstanding goal, and a lot of the code to support it has already been written, but there are still some problems that need to be solved, probably too many to allow it to get into the next version of GIMP (which aims to come out in 6 months or so). What we are talking about here are less extensive changes that might make it easier to work with stroking in the meantime. Anyway, thanks for your input, -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
Hi, On Sun, 2007-12-09 at 03:32 +, William Skaggs wrote: Okay, I can see that a preview would go a long way toward making the dialog more usable. I looked over the relevant code, though, and I'm not sure it would be very easy to set one up. Previewing libart stroking wouldn't be very hard, because basically all you need is a set of tiles to do the stroking on. Previewing paint tool stroking would be more problematic: it requires either an attached drawable, or massive code changes. So, as far as I can see, the only way to do it without massive rewriting would be to create a new temporary layer, attach it to the image, render the preview onto it, transfer the preview to the dialog, then remove the temporary layer. That wouldn't be hard to do, but it seems a bit, um, baroque. It's not only baroque, it is definitely not a reasonable way to implement this. The Stroke dialog must not alter the image structure. Simply because there is no guarantee that the user (or some plug-in) doesn't do anything else with the image while the dialog is opened. I don't see though why it requires massive changes to implement a preview of paint strokes. It should be possible to do this after some refactoring of the code. 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 usability enhancements for Stroke dialog
Sven wrote: I don't see though why it requires massive changes to implement a preview of paint strokes. It should be possible to do this after some refactoring of the code. Stroking with a paint tool is implemented in gimppaintcore-stroke.c, by gimp_paint_core_stroke() or gimp_paint_core_stroke_boundary(), which are very similar. Each of these functions calls: gimp_paint_core_start() gimp_paint_core_paint() gimp_paint_core_interpolate() gimp_paint_core_finish() gimp_paint_core_cleanup() And each of those requires an attached drawable. Furthermore, each of them is actually a virtual function (mostly), implemented differently by each paint tool. And at least some of those object methods will break if you don't have an attached drawable. So I don't see how to make this work on anything other than an attached drawable by any sort of simple refactoring. It would require a major rewrite of the paint core code, and that's some of the worst code in all of GIMP to mess around with. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
From: William Skaggs [EMAIL PROTECTED] I think I need to follow up on my last message, because it was read incorrectly by some people. I should say that the English skills of most of the people who contribute to GIMP are so strong that I normally don't worry about how I say things, but in this case I assumed too much. The phrase in question is, that's some of the worst code in all of GIMP to mess around with, which was taken by some readers to mean that's some of the worst code in GIMP. To a native English speaker, it certainly does not mean that. It means, approximately, it is dangerous to make changes to that code. The word worst applies to mess around with, not to code. This sort of construction is actually pretty common. If I say, he's a bad man to annoy, it doesn't mean that he is a bad man---bad applies to annoy, not to man. I hope this makes my meaning more clear. Whether it is, in fact, dangerous to make changes to the paint core code is, of course, a different question, but I don't think it is insulting to suggest this. Some of the best code in GIMP is very carefully written to deal with complicated situations, and very dangerous to change, in other words, bad to mess around with. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
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? 2) The default for Dash preset should be Line rather than Custom. This is just obviously wrong. Well, you would have to add logic then that changes it to Custom as soon as the user edits the custom dash pattern. And you would have to remember that setting also. When we did that dialog we decided that it's just not worth the hassle. Also, it shouldn't be called Dash preset, but rather Line style, and the expander should be named something different, such as Stroke settings. Hmm, Stroke settings doesn't tell me anything while Line Style seems to be a good description of the contents of the expander. The line style does however include a lot more than just the dash pattern. 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. 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 usability enhancements for Stroke dialog
I agree with all of your suggestions. I would assume that changes made in the dialog would update the stroke interactively and, hopefully, that the path could be reshaped while the dialog remained open. This would be very useful. I find myself doing Edit-Stroke pretty often, and there are a few easy changes that I think would make it signficantly better. 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. 2) The default for Dash preset should be Line rather than Custom. This is just obviously wrong. Also, it shouldn't be called Dash preset, but rather Line style, and the expander should be named something different, such as Stroke settings. 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. These changes would take me less than an hour to implement, I believe, and I would like to do it. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
William Skaggs writes: I find myself doing Edit-Stroke pretty often, and there are a few easy changes that I think would make it signficantly better. 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. Certainly a full-size preview would be quite useful. Like you, I find that I usually Stroke several times trying to find the right brush size (I usually stroke with the paintbrush tool, for its antialiasing). It wouldn't have to require an extra click: make the dialog offer a Preview button as well as OK. People who are sure they have the right settings can click OK, everyone else can use Preview first. Your other suggestions sound reasonable, but I seldom change the line style so they're not burning issues to me. ...Akkana ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
Hi, On Sat, 2007-12-08 at 10:10 -0800, Akkana Peck wrote: Certainly a full-size preview would be quite useful. Like you, I find that I usually Stroke several times trying to find the right brush size (I usually stroke with the paintbrush tool, for its antialiasing). It wouldn't have to require an extra click: make the dialog offer a Preview button as well as OK. People who are sure they have the right settings can click OK, everyone else can use Preview first. Doing a preview on the image window would be rather difficult to get right. But I guess a simple preview of a short stroke in the Stroke dialog could already help a lot. And the same widget could be used in the brushes list and the brush editor. 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 usability enhancements for Stroke dialog
From: Sven Neumann [EMAIL PROTECTED] 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? How could it be made easier? And even if it were, consider the usage pattern you get: 1) bring up the dialog 2) move the dialog 3) set it up 4) hit okay 5) undo 6) bring back the dialog *) repeat steps 2-6 several times Note that since the dialog is transient, it generally comes up on top of the image, and needs to be moved aside each time. It's not clear how this could be avoided. 2) The default for Dash preset should be Line rather than Custom. This is just obviously wrong. Well, you would have to add logic then that changes it to Custom as soon as the user edits the custom dash pattern. And you would have to remember that setting also. When we did that dialog we decided that it's just not worth the hassle. Consider what this looks like to a user. I select libart stroking, open the expander, and see that the dash preset is custom. How can it be custom? Custom means something that I set up myself, but I haven't set anything up. What makes it even worse is that the default custom pattern only fills half the menu width, so it looks like a dash until you open the menu and see that line looks the same way. Also, it shouldn't be called Dash preset, but rather Line style, and the expander should be named something different, such as Stroke settings. Well, dash preset is programmer language, not user language. Something in user language is needed here. 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. It probably varies by user -- I personally use it pretty often. In any case, a user who chooses libart stroking will always, I think, want to see what is going to happen. Automatically opening the expander when the method is Stroke line would help some too. Anyway, I wouldn't want to get bogged down on the dashes part, when the really important part is streamlining the flow of changing settings and re-stroking. As currently done, it feels broken. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
I agree with all of your suggestions. I would assume that changes made in the dialog would update the stroke interactively and, hopefully, that the path could be reshaped while the dialog remained open. This would be very useful. Those are both feasible, but they go beyond the scope of what I'm suggesting at this point, if I understand you. If by the second point you mean, reshape the path and the stroke will automatically follow, you are basically asking for vector shapes. Not really vector shapes -- which might be reshaped after the dialog was closed -- just that the effect of changes in the dialog would be represented on canvas. If you just mean that the dialog would allow you to change the path and then stroke the result, that wouldn't even need any work, it would happen automatically if the dialog stayed open. If the dialog does not go away when the Stroke button is pushed (per item #1 in your original post) then a second pressing of the button should first remove the effect of the first stroke (in other words, the stroking does not accumulate). I am assuming this is what you intended so that multiple attempts could be made while getting the desired settings. It is currently possible to reshape a path while the dialog is open so I guess my point was just a cautionary note that a second stroking cannot just overwrite the first assuming an unmodified path. It would also require that path modifications send a notification that your handler needs to update the stroke preview (not needed if Akkana's proposal were implemented). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] proposal for usability enhancements for Stroke dialog
Hi, On Sat, 2007-12-08 at 19:39 +, William Skaggs wrote: How could it be made easier? Well, for plug-ins this is already quite easy. You use Undo and then Reshow the filter dialog. It's rather confusing though that this only works for operation implemented as plug-ins. It would perhaps be a good idea to enable Repeat and Reshow for all actions called from the menu. 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 usability enhancements for Stroke dialog
Okay, I can see that a preview would go a long way toward making the dialog more usable. I looked over the relevant code, though, and I'm not sure it would be very easy to set one up. Previewing libart stroking wouldn't be very hard, because basically all you need is a set of tiles to do the stroking on. Previewing paint tool stroking would be more problematic: it requires either an attached drawable, or massive code changes. So, as far as I can see, the only way to do it without massive rewriting would be to create a new temporary layer, attach it to the image, render the preview onto it, transfer the preview to the dialog, then remove the temporary layer. That wouldn't be hard to do, but it seems a bit, um, baroque. -- Bill ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
