Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
Hi, On Sun, 2006-10-01 at 07:23 -0700, Saul Goode wrote: To a large extent, all operations in the Layers menu do not honor selections. The notable exceptions are: Transparency-Color To Alpha Transparency-Semi-flatten Transparency-Threshold Alpha Transform-Arbitrary Rotate These are plug-ins (color2alpha, semiflatten, threshold_alpha) or tools (Rotate tool). Plug-ins automatically honor the selection, they can't modify unselected pixels, Arbitrary Rotation is just a shortcut for switching to the Rotate tool. 5) Restore the option to use the space bar to move the current layer without any dialog being presented. This could readily be implemented by executing the Move Tool in the ignore selection mode. The space bar feature is still present (as an option) and it has always been implemented by switching to the Move tool temporarily. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
The space bar feature is still present (as an option) and it has always been implemented by switching to the Move tool temporarily. Sven Indeed, you are correct. I must have switched the affect: option of the Move tool during my experimentation and failed to restore it. These are plug-ins (color2alpha, semiflatten, threshold_alpha) or tools (Rotate tool). Plug-ins automatically honor the selection, And being able to make such a blanket statement should simplify things for the user. Unfortunately, without a way of differentiating between a plug-in or a core function in the menu system that knowledge is of no benefit to the user. Nonetheless, of more importance than the Layer menu, it would be of great benefit to the user interface to be able to make such a general statement about tools (i.e., tools automatically honor the selection). Since there is only one tool that violates this at the current time, it would seem most reasonable to make that tool conform; especially since Move operations bear such a connection and similarity to Transform operations. The current Affect: options of the Move Tool and all of the transform tools have the same tool hints: Transform Layer, Transform Selection, and Transform Path. There is nothing in the user interface to suggest that the Move Tool does not honor selections while the other tools do. It seems to me that adding a Transform Selection Contents mode to the Move tool and a Transform Layer mode to the transform tools would provide an extremely desirable commonality while correcting an obvious inconsistency. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
All tools in the current toolbox honor the selection EXCEPT the Move Tool -- though in some cases the selection is not reasonably applicable (eyedropper, zoom, measure, and crop) and in cases of the selection tools, there are modes which modify how selections are treated. To a large extent, all operations in the Layers menu do not honor selections. The notable exceptions are: Transparency-Color To Alpha Transparency-Semi-flatten Transparency-Threshold Alpha Transform-Arbitrary Rotate I would submit that the exceptions listed would best be eradicated: that a general policy be maintained that the default behavior of all functions under the Layer Menu operate on drawables while disregarding any selection and that the default behavior of all tools in the Toolbox honor selections (unless directed otherwise). In order to prosecute such a policy, I would propose the following changes to the current (development) interface: 1) Move the offending Transparency functions to the new Colors menu. 2) Have the Arbitrary Rotate MENU function ignore the selection, operate on the drawable, and not generate a floated layer. 3) Modify the Move Tool so that it operates precisely like the transform tools, honoring the selection and operating on its contents. (This means that a dialog would be presented, numeric offsets possibly enterred, and OK pressed to generate a floated layer). 4) Add a modified mode to ALL of the transform tools (plus/including the new Move Tool) which makes them ignore the selection, operate on the drawable, and not generate a floated layer. Ideally, if the tool is activated in this mode (perhaps CTRL+ALT being held down while the mouse is initially clicked), there should be no dialog presented and the operation take place when the mouse button is released (if the mode is activated after the tool is executed then pressing OK would be required). 5) Restore the option to use the space bar to move the current layer without any dialog being presented. This could readily be implemented by executing the Move Tool in the ignore selection mode. It is amazing what you can accomplish if you do not care who gets the credit. -- Harry S. Truman ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
On Thu, 28 Sep 2006 01:42:12 +0200, [EMAIL PROTECTED] wrote: [...] 1/ In general I find it needs too many mouse/keyboard actions to achieve a simple operation. 1a/ specific: undo : edit | undo . This must be one of the most common actions I want a one click solution, in the same window as I am editting in. There's always cntl-Z cntl-Y but that means dropping the mouse and diverting my attention away fron the screen. Very slow. Well, the undo shortcut is probably not assigned to Ctrl-Z by accident. Did you notice that there is no Z in undo? Something like Ctrl-U could have been used instead (and was used in the past). But many applications use Ctrl-Z. If you are a right-handed english-speaking user (or at least someone with a qwerty keyboard), you can see that Ctrl and Z are close to each other and can be pressed easily with the left hand while the right hand is on the mouse. You might complain about discrimination against lefties or foreigners, but at least for a large percentage of the users, the Ctrl-Z shortcut can be found easily without diverting attention from the screen or mouse. 1b/ I pull up a dlg. the first text entry is highlighted so I can type to replace , fine. But if I want to edit it eg 100 to 400, I go to select the 1 with the mouse and the editted text gets dragged. Huh? So I have to click to deselect the reselect the bit I want. Solving this problem would probably require disabling drag drop from the input fields. I am not sure that anyone uses that feature anyway, at least for the short entry fields that we have in most dialogs (except for the text tool). I agree that it is more likely that someone who clicks and drags in one of these short input fields wants to select some digits instead of dragging the whole number elsewhere. This should probably be submitted in Bugzilla. 2/ I am continually repeating the same placement/configuration operations where once should be enough. 2a/ It seems none of the filters retain thier position and size, although they retains _some_ of their settings. Right. We do not even have an API allowing the plug-ins to retain their size and position easily. Although the current API based on gimp_get_data() and gimp_set_data() could be used for that, every plug-in writer would have to write hacks around gimp_dialog_new() or gimp_dialog_run() in order to resize the window correctly. In addition, the filters that have a more complex layout with resizeable panes inside the window would also have to remember the size of each of them (e.g. Filters-Map-Bump Map) and those that have multiple tabs should remember which tab is active. specific: Filters | Motion Blur ... I resize to get a more visible preview size and move it out of the way of other things on the screen. Next time I use it I dont want to start again. While this is probably down to the plugin writer, at least the common filters should be vetted/modded to retain size/pos before being integrated. And it should be recommended for all plug-ins. I agree. Please submit this improvement proposal in Bugzilla. It may even be useful to remember the window positions (for the plug-ins) accross gimp sessions. In this case, this information should probably go into the pluginrc or something similar. 2b/ If I use a dlg on one image and set, say units to pixels , if I open another image or even duplicate I have to reset the same options. specific: Image | Scale Image , set to percent . Duplicate image , Scale Image : back to default pixels. Although it would make sense for Duplicate, I am not sure that it would be good to always remember the last values used when you create a new image. The defaults can be set in Preferences-Default Image and I would like these values to be used. 2c/ I have select for tools to store settings but this seems limitted. specific: again the Scale Image dlg. units combo. This is held for the time I edit an image but not affected by the config option :tools store settings. I do not understand what you expect in this case. Things like the resolution, units, grid spacing and so on are a property of the image. The Scale Image dialog should just use what is specified for that image. But maybe I misunderstood what you meant. 2d/ I set a value , eg rotation degrees or scale percent. Next time I pull up the dlg it's back to NOP settings : zero degrees or 100% scaling. Now I dont necessarily want the same value but one thing it's sure I dont need is a NOP. Last entered value would be a better starting point. Hmmm... I am not too sure about that. One the one hand it would not be too hard to remember the last values and the user could easily click on the nice Reset button if these values are not appropriate for the next image. On the other hand, I would probably be surprised to see my image (preview) instantly rotated, shrunk or distorted as soon as I activate one of the transform tools.
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
Hi, On Thu, 2006-09-28 at 14:39 +0200, Raphaël Quinet wrote: 2d/ I set a value , eg rotation degrees or scale percent. Next time I pull up the dlg it's back to NOP settings : zero degrees or 100% scaling. Now I dont necessarily want the same value but one thing it's sure I dont need is a NOP. Last entered value would be a better starting point. Hmmm... I am not too sure about that. One the one hand it would not be too hard to remember the last values and the user could easily click on the nice Reset button if these values are not appropriate for the next image. On the other hand, I would probably be surprised to see my image (preview) instantly rotated, shrunk or distorted as soon as I activate one of the transform tools. Indeed. The image is also not filled with the last used color if the user switches to the Bucket Fill tool. Doing this for the transform tools would be very inconsistent. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
On Thu, 28 Sep 2006 14:39:39 +0200, Raphaël Quinet [EMAIL PROTECTED] wrote: On Thu, 28 Sep 2006 01:42:12 +0200, [EMAIL PROTECTED] wrote: [...] 1/ In general I find it needs too many mouse/keyboard actions to achieve a simple operation. 1a/ specific: undo : edit | undo . This must be one of the most common actions I want a one click solution, in the same window as I am editting in. There's always cntl-Z cntl-Y but that means dropping the mouse and diverting my attention away fron the screen. Very slow. Well, the undo shortcut is probably not assigned to Ctrl-Z by accident. Did you notice that there is no Z in undo? Something like Ctrl-U could have been used instead (and was used in the past). But many applications use Ctrl-Z. If you are a right-handed english-speaking user (or at least someone with a qwerty keyboard), you can see that Ctrl and Z are close to each other and can be pressed easily with the left hand while the right hand is on the mouse. You might complain about discrimination against lefties or foreigners, but at least for a large percentage of the users, the Ctrl-Z shortcut can be found easily without diverting attention from the screen or mouse. Yes, I know cntl-Z can be hit with one hand but I am going to scrabble around unless I look, in which we're back to my original point. A close to hand undo button would be a lot faster. 1b/ I pull up a dlg. the first text entry is highlighted so I can type to replace , fine. But if I want to edit it eg 100 to 400, I go to select the 1 with the mouse and the editted text gets dragged. Huh? So I have to click to deselect the reselect the bit I want. Solving this problem would probably require disabling drag drop from the input fields. I am not sure that anyone uses that feature anyway, at least for the short entry fields that we have in most dialogs (except for the text tool). I agree that it is more likely that someone who clicks and drags in one of these short input fields wants to select some digits instead of dragging the whole number elsewhere. This should probably be submitted in Bugzilla. Done. 2/ I am continually repeating the same placement/configuration operations where once should be enough. 2a/ It seems none of the filters retain thier position and size, although they retains _some_ of their settings. Right. We do not even have an API allowing the plug-ins to retain their size and position easily. Although the current API based on gimp_get_data() and gimp_set_data() could be used for that, every plug-in writer would have to write hacks around gimp_dialog_new() or gimp_dialog_run() in order to resize the window correctly. In addition, the filters that have a more complex layout with resizeable panes inside the window would also have to remember the size of each of them (e.g. Filters-Map-Bump Map) and those that have multiple tabs should remember which tab is active. Taking Bump Map as an example, this is a good case in point. The preview autorescales so all we need is size and position to be reatained. Many of these previews are too small to see the effect clearly. That's my main reason to resize the dlg. I think technical difficulties of implementation need to be separated from UI discussion until the value of the idea has been assessed. I would have other comments about the flexibility on API implementations. specific: Filters | Motion Blur ... I resize to get a more visible preview size and move it out of the way of other things on the screen. Next time I use it I dont want to start again. While this is probably down to the plugin writer, at least the common filters should be vetted/modded to retain size/pos before being integrated. And it should be recommended for all plug-ins. I agree. Please submit this improvement proposal in Bugzilla. It may even be useful to remember the window positions (for the plug-ins) accross gimp sessions. In this case, this information should probably go into the pluginrc or something similar. Done. 2b/ If I use a dlg on one image and set, say units to pixels , if I open another image or even duplicate I have to reset the same options. specific: Image | Scale Image , set to percent . Duplicate image , Scale Image : back to default pixels. Although it would make sense for Duplicate, I am not sure that it would be good to always remember the last values used when you create a new image. The defaults can be set in Preferences-Default Image and I would like these values to be used. I was refering to scale image, duplicate was mentioned to show that each instance of the dlg reverts while the same instance retains. Rather inconsistant. Settings could be stored when the dlg is closed so that the same dlg on another image can retain them. 2c/ I have selected for tools to store settings but this seems limitted. specific: again the Scale Image dlg. units combo. This is held for the time I edit an image but not affected by the config option
Re: *** PROBABLY SPAM *** Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
On Thu, 28 Sep 2006 19:12:57 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Thu, 2006-09-28 at 14:39 +0200, Raphaël Quinet wrote: 2d/ I set a value , eg rotation degrees or scale percent. Next time I pull up the dlg it's back to NOP settings : zero degrees or 100% scaling. Now I dont necessarily want the same value but one thing it's sure I dont need is a NOP. Last entered value would be a better starting point. Hmmm... I am not too sure about that. One the one hand it would not be too hard to remember the last values and the user could easily click on the nice Reset button if these values are not appropriate for the next image. On the other hand, I would probably be surprised to see my image (preview) instantly rotated, shrunk or distorted as soon as I activate one of the transform tools. Indeed. The image is also not filled with the last used color if the user switches to the Bucket Fill tool. Doing this for the transform tools would be very inconsistent. Sven Yes there are inconsistencies already here. Rotate and shear behave differently and bucket-fill does not revert to black and white every time you use it. Bucket-fill remembers its settings but does not apply them until you ask. Rotate shows the selection outline rotated but not the pixels so if it remembered this would work well without arbitarily transforming the image before required. If the other transforms were made consistant with rotate, all could retain values and you would have the best of both worlds and be more consistant than the current situation. What do you think would be the best way to align these differences? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements
Hi, On Thu, 2006-09-28 at 22:50 +0200, [EMAIL PROTECTED] wrote: I think technical difficulties of implementation need to be separated from UI discussion until the value of the idea has been assessed. I would have other comments about the flexibility on API implementations. I don't think this needs much further discussion. We already have plans for adding a GimpPlugInDialog widget and porting the plug-ins to it. Such a dialog would provide a framework for loading and storing plug-in settings or at least for changing the defaults. It could also take care of session management such as setting the window size. I dont see what tool store settings does. I see some data about brushes if I plough through the configs but if I choose to work in percent rather than pixels this is not remembered. IIRC, the dialog currently takes the unit from the image that is being edited. This seems to make some sense to me and it might be difficult to decide when it makes sense to use percent instead. Or perhaps percent would even be a better default? We should ask some users. Well I looked at this with rotate. The preview on the image just shows the outline that will be rotated but does not move the image/selection until the dlg closes. This indeed seems the best of both worlds if it retains my last rotation setting. I either hit go or reset as you suggest. IIRC, the Rotate tool shows a preview of the rotation by default. If it shows only the outline for you, then you probably changed the default rotate tool settings. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
Hi, On Thu, 2006-09-28 at 23:01 +0200, [EMAIL PROTECTED] wrote: Yes there are inconsistencies already here. Rotate and shear behave differently and bucket-fill does not revert to black and white every time you use it. Your accusations are unfair. First of all, your GIMP setup seems somewhat screwed. Try to reset the tool options or remove the ~/.gimp-2.3/tool-options folder. And you also ignore the fact that a lot of thought has gone into the current behaviour. It would help if you could appreciate that and ask before you jump to conclusions quickly. Also you need to admit that your usage of GIMP is just one possible way of using it. We don't know much about you yet, so we can't tell if your usage patterns are in any way representative for a large user group. We are willing to do changes. But very often people forget to see all aspects of user interface design. Are you sure that you have thought about all possible user scenarious? Are you sure that you understood the rationale behind the current behaviour? If not, it might be a good idea to ask those questions first. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] UI improvements (was: Moving selection contents with the move tool?)
On Thu, 28 Sep 2006 23:21:15 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Thu, 2006-09-28 at 23:01 +0200, [EMAIL PROTECTED] wrote: Yes there are inconsistencies already here. Rotate and shear behave differently and bucket-fill does not revert to black and white every time you use it. Your accusations are unfair. First of all, your GIMP setup seems somewhat screwed. Try to reset the tool options or remove the ~/.gimp-2.3/tool-options folder. And you also ignore the fact that a lot of thought has gone into the current behaviour. It would help if you could appreciate that and ask before you jump to conclusions quickly. Also you need to admit that your usage of GIMP is just one possible way of using it. We don't know much about you yet, so we can't tell if your usage patterns are in any way representative for a large user group. We are willing to do changes. But very often people forget to see all aspects of user interface design. Are you sure that you have thought about all possible user scenarios? Are you sure that you understood the rationale behind the current behaviour? If not, it might be a good idea to ask those questions first. Sven Sven, (and the rest of the team) please don't take any of this the wrong way. I made a list of things that I found held me back. This is in no way suggesting that no-one has put any thought into this interface , clearly they have. By and large it works very well. I would like to help you improve it. I clearly stated that all of the issues were minor but the overall effect was that a lot more mouse input was required than was really necessary. I listed a number of points , not as a means of ripping it apart, but to give clear indications where I could identify lost time and hence give something concrete to look into rather than broad unjustified comments. You will appreciate it also takes time to go through all this and give precise, hopefully useful, criticisms. Neither do I assume my way of working is typical, it almost certainly is not, because like most of you on this list I have a technical programmers background and a good knowledge of maths. What I say about settings is not that the one's I choose are in any way better or typical but that there is a need to retain user settings in order to avoid a lot of unwarranted repetition. Sorry if I have a bit of a blunt style , I do tend to come straight to the point. This is not meant to be dismissive or disrespectful of the work that has been done. We all also know email is a lousy form of communication and it's easy to take things the wrong way. You and Bill in particular have been very helpful in helping find my way around the code and I've felicitated you on the openness of your approach. Let's not let irritations drift drift in the way here. Thanks for your time and comments. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
