Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 11/6/06, Øyvind Kolås <[EMAIL PROTECTED]> wrote: [...] Perhaps you'll find the interface in http://pippin.gimp.org/gegl/gegl-20061105.gif easier to decode, since that is a screengrab made to illustrate such a type to find a filter interface. In that interface I copied the mozilla behavior of focusing "the location bar" with ctrl+L probably a suboptimal choice but it worked for my experiment[1]. Yeah, this is similar to what I was suggesting, and it seems to work quite nicely. By the way, notice how you had to move the dialog box out of the way sometimes in order to see the image you were editing. This happens to me in Gnome a lot, especially with the crop tool, which I use a lot. It pops up right where I am making a selection, so I can't see what I am selecting! How daft! It would be much better if it popped up as a button that expands to a dialog when you (say) mouse over it and contracts back to a button if you move the mouse outside the dialog. Or the dialog should pop up outside the image if possible (over the toolbox if it exists and does not overlap with the image), or at the edge of the image where I am less likely to work. [...] ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
Hi, we are asking for a volunteer to fix the Plug-In Browser for several years now. The GimpBrowser widget in libgimpwidgets was designed especially to allow this sort of search interface and all that needs to be done is to port the Plug-In Browser to it and to extend it a little so that you can also run plug-ins from it. Now if you guys would spend less time discussing things that have already been discussed to dead and would do some coding instead... Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/12/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: > where applicable. I envisioned using a tile-based interface for this not > unlike the beagle-search tool* but never gotten to mock things up. Feel > like speccing things up? ;) [rearranged] > * http://upload.wikimedia.org/wikipedia/en/5/54/Beagle-search.png I added a very simple thing like this to my image processing app. a couple of years ago. I have about 350 menu items :-( so it really helps finding things (I use it myself sometimes). You can see it on the RHS of this screenshot: http://www.vips.ecs.soton.ac.uk/images/Screenshot-nip2-7.10.10.png The localised descriptions of the menu items are displayed in a list. As you type in the search box, the list expands and contracts showing matching items. Double-clicking on an item activates that menu action. There's a tickbox in the View menu which shows and hides the browser (with a little animation), or you can drag on the pane handle. As well as the localised description, if you scroll to the right it also displays the path to the menu item, the action arguments and the keyboard shortcut (if any). ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 11/6/06, Øyvind Kolås wrote: Well for brightness/contrast for instance, I think something like the "curves" like UI provided at http://pippin.gimp.org/bauxite/old_screenshots/2004-06-15.png combined with entries would probably be superior to just separate sliders for brightness/contrast. Another example would be UFRaw and curve in Correction tab. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 11/6/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: On Mon, 06 Nov 2006 11:10:59 +0100, Øyvind Kolås <[EMAIL PROTECTED]> wrote: > Perhaps you'll find the interface in > http://pippin.gimp.org/gegl/gegl-20061105.gif easier to decode very interesting. Obviously sliders would be more intuitive when you get further on , a contrast change of 2.25 does not have any meaning to most people. The user interface presented there is a very simple and naive representation of the parameters of the operation itself, if custom GUI's were available for the operations they would probably be used instead, for most of these things, integrating the user interaction in the view itself would probably also be beneficial. Popups like this are quite annoying if they can be avoided. It's probably only of use in being able to log a numerical value for future reference, documenting what was done or repeating with the same parameters later. That is to say it's worth having numerical input but is slider is more relevant most of the time. Well for brightness/contrast for instance, I think something like the "curves" like UI provided at http://pippin.gimp.org/bauxite/old_screenshots/2004-06-15.png combined with entries would probably be superior to just separate sliders for brightness/contrast. Could you briefly outline how you capture the sequence of events and prepare the gif amin. , it's a very good way to present things sometimes. Byzanz, http://www.gnomefiles.org/app.php?soft_id=1261 , is used to capture from the screen to a gif animation. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/13/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: On 10/13/06, Øyvind Kolås <[EMAIL PROTECTED]> wrote: > I have implemented a similar solution in my > prototypes of more advanced layer interfaces and added one more thing, > items can exist in multiple locations in the menu system with the aim > to make it easier finding what you are looking for when only browsing > the menu as well. Adding an item to more than one menu is probably a good idea. It must have been tried before, and perhaps even user tested, but I haven't researched to know whether it was useful or confusing. > http://pippin.gimp.org/tmp/search-menu.gif contains a recorded > animation of the UI elements I've been using. I did not understand what is the purpose of the interface in the animation. I see that you have some searching, but there is a lot of use of the mouse, which is generally inefficient[1]. Perhaps you'll find the interface in http://pippin.gimp.org/gegl/gegl-20061105.gif easier to decode, since that is a screengrab made to illustrate such a type to find a filter interface. In that interface I copied the mozilla behavior of focusing "the location bar" with ctrl+L probably a suboptimal choice but it worked for my experiment[1]. /Øyvind K. 1: I am increasingly annoyed with people assuming that when I present functional prototypes of things that they are in a form even considered final enough for an end user to use. In most cases they are sketches or scaffolding on top of code that I am actually developing. It is probably not a solution if I start complaining that buttons in mockups do not work when I press them. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On Fri, 20 Oct 2006 02:36:29 +0200, Manish Singh <[EMAIL PROTECTED]> wrote: On Fri, Oct 20, 2006 at 02:24:48AM +0200, Omar wrote: Omar a ?crit : >Alexandre Prokoudine a ?crit : >>On 10/20/06, gg wrote: >>>On Thu, 19 Oct 2006 17:35:19 +0200, Sven Neumann wrote: >>> all other toolkits that have tear-off menus >>> >>>'still interested to know what "all the other toolkits" are. >> >>Qt OpenMotif :) And it's not just unix stuff, Microsoft Office has had them for a while too. IIRC they do have a tooltip for the "--" bit. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer Qt , really? I just ran up thre "K*" progs and dont see any sign of it. :? Long time since I went anywhere near M$ Orafice , but if they use "---" it must be right :P thanks for educating me. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On Fri, Oct 20, 2006 at 02:24:48AM +0200, Omar wrote: > Omar a ?crit : > >Alexandre Prokoudine a ?crit : > >>On 10/20/06, gg wrote: > >>>On Thu, 19 Oct 2006 17:35:19 +0200, Sven Neumann wrote: > >>> > all other toolkits that have tear-off menus > >>> > >>>'still interested to know what "all the other toolkits" are. > >> > >>Qt > OpenMotif :) And it's not just unix stuff, Microsoft Office has had them for a while too. IIRC they do have a tooltip for the "--" bit. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
Omar a écrit : Alexandre Prokoudine a écrit : On 10/20/06, gg wrote: On Thu, 19 Oct 2006 17:35:19 +0200, Sven Neumann wrote: > all other toolkits that have tear-off menus 'still interested to know what "all the other toolkits" are. Qt OpenMotif :) -Omar ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/20/06, gg wrote: On Thu, 19 Oct 2006 17:35:19 +0200, Sven Neumann wrote: > all other toolkits that have tear-off menus 'still interested to know what "all the other toolkits" are. Qt Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On Thu, 19 Oct 2006 17:35:19 +0200, Sven Neumann <[EMAIL PROTECTED]> wrote: all other toolkits that have tear-off menus 'still interested to know what "all the other toolkits" are. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
Hi, On Thu, 2006-10-19 at 16:22 +0200, [EMAIL PROTECTED] wrote: > A short helpful text item like "tear-off" would not take make the menu a > single pixel larger nor would it "clutter" the menu more than a > meainingless line of hyphens. Yes, it would. It would distract the user's view from the actual menu entries and makes it harder to quickly scan the menu. > The "tear along the dotted line" that the current entry presumably is > supposed to represent has no meaning until you are aware of the feature > and what it is called. There is not analogy elsewhere this I am aware off > that would cause a user to understand this otherwise. Well, all other toolkits that have tear-off menus do it pretty much the same way and use pretty much the same visual representation. Having a tooltip on the menu might be a good idea. Please propose it to the GTK+ developers and stop discussing this here any further. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On Thu, 2006-10-19 at 19:52 +0930, David Gowers wrote: > Checking the UI again, if there is any confusion as to the function of > , shouldn't get a tooltip saying 'Tear off this > menu'? As Sven said, discussing this here makes no sense whatsoever, please bring it up on a gtk mailing list. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
Checking the UI again, if there is any confusion as to the function of , shouldn't get a tooltip saying 'Tear off this menu'? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/19/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Nice feature , shame there is absolutely nothing in a line of- to suggest this actually does something.To me, if I can select a menu item, it does something. Personally I had no trouble discovering this feature. I agree that it could be improved, and it should be non-textual (as in, it shouldn't look like any other menu entry.) The --- seems fairly obvious to me, though - perforation marks showing that you can 'tear off here' ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
Hi, On Thu, 2006-10-19 at 11:07 +0200, [EMAIL PROTECTED] wrote: > Conclusion: how about giving it a meaningful label rather than "" > . "Tear off" would be enough to raise the curiosity and once clicked this > excellent feature would be imediately available to all users. Suggest that to the GTK+ developers then. This is not a GIMP feature, it's provided by GTK+ (but disabled by default IIRC). I strongly disagree with adding a label to it though as that would IMO clutter the menus too much. This is a power-user feature and it should be sufficient to mention it in the user manual. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On Thu, 19 Oct 2006 02:12:39 +0200, Leon Brooks <[EMAIL PROTECTED]> wrote: Omar <[EMAIL PROTECTED]> wrote: Saul Goode a écrit : The menus that you obtain with a right-click have a dotted line across the top. If you click on that dotted line, a menu window is created with just that sub-menu. By right-clicking on "Edit" and selecting the dotted line at the top of the "Edit->Paste As" sub-menu, you will create a menu dialog that will make the "Paste As New Image" command just a mouse-click away at all times. Such tear-offs lose their utility if commands are all clumped together on a top-level menu. For this reason, I question the wisdom of the GNOME HIG discouraging nesting of menus (or at least the idea that three levels is excessive, especially if the menu bar is itself to be considered a menu). DON'T touch/remove "TEAR-OFF menu"! NEVER! :) This is one of the best Gimp's UI concept here. ps: sorry to play the intruder in this ML :) I was worth it. (-: My sister-in-law uses that feature extensively. She had to use PhotoShop recently; the moaning & wailing which ensued about such features' absence was incredible. She does professional photography. Her site is at http://www.goldenlight.bur.st/ Ahh! More hidden treasure. Nice feature , shame there is absolutely nothing in a line of - to suggest this actually does something. I always thought it was a gimp oddity and someone had decided to style the menus this way. In fact it is a _menu entry_ . Conclusion: how about giving it a meaningful label rather than "" . "Tear off" would be enough to raise the curiosity and once clicked this excellent feature would be imediately available to all users. Thanks to Saul for explaining it's existance to me. and , yes, I agree about HIG and not nesting menus , that was one of my main points when I started this discussion. The Paste As .. menu is one level too many. Glad we are all agreed. ;) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
Omar <[EMAIL PROTECTED]> wrote: > Saul Goode a écrit : >> The menus that you obtain with a right-click have a dotted line >> across the top. If you click on that dotted line, a menu window >> is created with just that sub-menu. By right-clicking on "Edit" >> and selecting the dotted line at the top of the "Edit->Paste As" >> sub-menu, you will create a menu dialog that will make the >> "Paste As New Image" command just a mouse-click away at >> all times. >> Such tear-offs lose their utility if commands are all clumped >> together on a top-level menu. For this reason, I question the >> wisdom of the GNOME HIG discouraging nesting of menus >> (or at least the idea that three levels is excessive, especially >> if the menu bar is itself to be considered a menu). > DON'T touch/remove "TEAR-OFF menu"! NEVER! :) > This is one of the best Gimp's UI concept here. > ps: sorry to play the intruder in this ML :) I was worth it. (-: My sister-in-law uses that feature extensively. She had to use PhotoShop recently; the moaning & wailing which ensued about such features' absence was incredible. She does professional photography. Her site is at http://www.goldenlight.bur.st/ Cheers; Leon ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
Omar a écrit : Saul Goode a écrit : gg wrote: I assume a "tear-off" menu is the context menu I get from a right-mouse click. I dont see the gain here, it's actually one click more than using the edit menu. If I misunderstood, could you explain what a tear-off is? The menus that you obtain with a right-click have a dotted line across the top. If you click on that dotted line, a menu window is created with just that sub-menu. By right-clicking on "Edit" and selecting the dotted line at the top of the "Edit->Paste As" sub-menu, you will create a menu dialog that will make the "Paste As New Image" command just a mouse-click away at all times. Such tear-offs lose their utility if commands are all clumped together on a top-level menu. For this reason, I question the wisdom of the GNOME HIG discouraging nesting of menus (or at least the idea that three levels is excessive, especially if the menu bar is itself to be considered a menu). DON'T touch/remove "TEAR-OFF menu"! NEVER! :) This is one of the best Gimp's UI concept here. Thank you Regards -Omar ps: sorry to play the intruder in this ML :) ___ 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] [GIMP] Suggestion to simplify user interaction
On Thu, 2006-10-12 at 18:33 -0400, Philip Ganchev wrote: > I would love to make the description more formal, if someone tells me > how. Is that what you mean by "spec things up"? Hi Yea, I meant to write a functional specification of how this is supposed to work. Joel Spolski has written a nice introduction to functional specifications: http://www.joelonsoftware.com/articles/fog36.html Some other issues you raised - I thought tiles would make a better use of space, but having a single column would work just as well as we really need to present just a few results. As for the graphic, I would think a lot of effects can be illustrated with a graphic. An image shouldn't actually get processed (at least not at run-time), but a sample graphic processed with a filter may illustrate its effect better than a description. To emphasize the effect, the thumbnail could be split, with the left side being the original sample image and the right side with the effect applied. cheers -- Jakub Steiner <[EMAIL PROTECTED]> ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
> gg wrote: > I assume a "tear-off" menu is the context menu I get from a right-mouse > click. I dont see the gain here, it's actually one click more than using > the edit menu. > > If I misunderstood, could you explain what a tear-off is? > The menus that you obtain with a right-click have a dotted line across the top. If you click on that dotted line, a menu window is created with just that sub-menu. By right-clicking on "Edit" and selecting the dotted line at the top of the "Edit->Paste As" sub-menu, you will create a menu dialog that will make the "Paste As New Image" command just a mouse-click away at all times. Such tear-offs lose their utility if commands are all clumped together on a top-level menu. For this reason, I question the wisdom of the GNOME HIG discouraging nesting of menus (or at least the idea that three levels is excessive, especially if the menu bar is itself to be considered a menu). Your comments on the enhancements and blurs has some merit, I just think it is important to recognize the development and maintenance process of the GIMP when making such decision. The different blur methodologies are different plug-ins and it seems you are suggesting that they be combined into a generic blur which permits the user to choose different options. Several difficulties would arise with this consolidation which are best summarized as discarding the benefits of the entire plug-in approach to the GIMP's development (division of labor, isolation of bugs, incremental improvements, the project's "bus factor"). In general, I think the greatest benefit to the GIMP's progression would be for there to be more of a focus on organizing and simplifying things from developer's standpoint. There is much more to be gained by facillitating the task of potential contributors working on innovative techniques and algorithms than there is from increasing the GIMP's userbase. "Usability" should not be entirely ignored, but nor should it come at the cost of "develop-ability". > my complaint was exactly that , that from one submenu to another the > submenu can come up left or right which is visually distruptive. > > http://bugzilla.gnome.org/show_bug.cgi?id=358816 Reading the text of a menu item leaves your eyes at the end of the text. If the sub-menu appears to the right, your eyes do not have to "jump" at all -- they are already positioned at the start of the sub-menu's text (this is a Good Thing). If the sub-menu appears to the left of the menu, your eyes must "jump" from the right (end) of the menu text and find the left (start) of the sub-menu (this is a Bad Thing). Your suggestion could be viewed as a preference for the consistency of all Things behaving Badly in the same manner over only having Bad Things occur when the Good Thing is not feasible. I am not saying that your suggestion is entirely without merit but you should not be so "apalled" that others do not share your preference. > There are no rotate operations on the image menu, all are in a submenu. I guess we will have to agree to disagree on submenus. I think that the taxonomic information that is imparted to the commands is valuable enough to justify the inconvenience of descending into them. > >> Some anomolies could be looked at, I can free-rotate a layer but not an > >> image. > > > > Erm, you can. > > > > Can you please clarify what you mean. I look at the Image | Transform and > I only get the simple 90deg and flip options. > > Where do you see rotate image? You are correct in that it is not on the Image menu and also that consistency in the menus' appearances might hold some benefit. However, my own preference would be that consistency in a menu's commands behavior is more vital. A week or two ago, I suggested that Arbitrary Rotation be removed from the Layer menu because it *behaves* anomalously to the other commands on that menu (it honors the selection while most of the other Layer commands ignore the selection and operate on the entire layer). Without such commonality of behavior, the user is forced to memorize (or use trial-and-error) which commands on the Layers menu honor the selection. IMO, this the main reason for grouping tools, operations, and commands into separate categories and should be more rigorously "enforced". > I would suggest "Enhance contrast" makes more sense as an entry in the > color menu than an obscure name of the algorithm used. The hint then gives > the extra info about what method is applied. Your suggestion isn't entirely invalid, I just feel that you are being somewhat solipsistic in wanting to draw the line of what is an "obscure" term in the field of graphics arts. Perhaps *you* are unfamiliar with the term (at this point in time) but would you suggest that if *you* were unfamiliar with the CMYK colorspace (or even RGB, as many newcomers to the field are), the GIMP developers should cater their terminology to the limitations of your vocabulary. At what point is the
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/15/06, [EMAIL PROTECTED] wrote: > Is there a reason you don't use tear-off menus? Having small sub-menus > actually enhances this utility. I assume a "tear-off" menu is the context menu I get from a right-mouse click. Which is wrong ;-) http://www.fifi.org/doc/gnumeric-doc/html/C/figures/tear-off-menu.png Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On Sun, 15 Oct 2006 04:36:53 +0200, Saul Goode <[EMAIL PROTECTED]> wrote: gg wrote: I also find as a user that menus often go too deep. One sub-menu is acceptable , two starts to get unwieldy. Eg. I ofter copy a selection and Paste As New , this is three levels deep. I'd like to see this at the same level as Cut: Cut | Paste | Paste as New. I crated a hot-key as a work around but as others have said , I would rather keep my eyes on the screen except for typing numbers etc. Is there a reason you don't use tear-off menus? Having small sub-menus actually enhances this utility. I assume a "tear-off" menu is the context menu I get from a right-mouse click. I dont see the gain here, it's actually one click more than using the edit menu. If I misunderstood, could you explain what a tear-off is? Another improvement would to clean up some menus. The Blur menu seems to contain several, largely equivalent filters. Two would suffice and could be incorporated into Enhance. Which two would suffice? Personally, I find all of them useful and I wouldn't recommend combining filters that use different algorithms into one interface -- not only would this complicate maintenance and development but menu grouping is a great indicator of a command's function. This menu could use some work, pixise is not a blur, it may be better in distortions menu. Gaussian blur, Selective Gaussian blur and tile seem to do basically the same thing with more or less options on the interface. I have not looked at the source but it seems they could be combined. This may actually reduce any future maintainance. Whether the non-adjustable blur is useful next to these may be worth thinking about. Motion blur clearly is a separate tool. If sharpen is an "enhancement" so is it's complement blur. It would probably be helpful for them to be together in Enhancement menu. I also created a bug about making sure sub-menus did not jump from one side to the other. This is appalling from a usability point of view but the comment did not get a very positive response. If your proposal were accepted, there would be reports submitted complaining that all the submenus appear on the left when there might be only one that's overly-long. My preference is to minimize the number of times that my eyes have to "jump" from the far right of menu text to the far left of sub-menu (much less appalling to just "continue reading left to right"). I'm not sure we're talking the same language here. my complaint was exactly that , that from one submenu to another the submenu can come up left or right which is visually distruptive. http://bugzilla.gnome.org/show_bug.cgi?id=358816 Some real basics like flip and rotating an image to straighten it up should be on the image menu. Erm, they are. I dont know what gimp you are looking at, I refer to 2.3.12 from cvs. There are no rotate operations on the image menu, all are in a submenu. Some anomolies could be looked at, I can free-rotate a layer but not an image. Erm, you can. Can you please clarify what you mean. I look at the Image | Transform and I only get the simple 90deg and flip options. Where do you see rotate image? Colors | Retinex ?? What's that supposed to tell the user? It tells me that it performs an operation called Retinex on the image. If I did not know what the word Retinex meant then, just like any other word with which I was unfamiliar, I would look it up. If Retinex is an inaccurate description of the processing taking place, a change in name might be called for but otherwise I would submit that the purpose of the GIMP is not to serve as a dictionary of graphics terms. The hint is good here. "Enhance contrast with Retinex method" . So what is the key information here? I would suggest "Enhance contrast" makes more sense as an entry in the color menu than an obscure name of the algorithm used. The hint then gives the extra info about what method is applied. Thanks for your detailed reply. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/15/06, Saul Goode <[EMAIL PROTECTED]> wrote: > Some anomolies could be looked at, I can free-rotate a layer but not an> image.Erm, you can.That is true, but it is non-obvious; and particularly, I only just discovered (due to your prompt) that transforms apply to all linked objects, not just the linked objects of the same type as the object that you are visibly transforming. I think it might well be worth adding an additional mode to transform tools, that ignores linked status and simply transforms everything that can be -- layers, channels, paths.For anyone else's interest, the quickest way to transform the image is: * Link all the items (layers, channels, or paths) -- for each kind of item, shift-click on the 'linked' field of any one item until all are linked (max 2 clicks needed per kind of item)* Use the transform tool in Layer or Path transform mode. > Colors | Retinex ?? What's that supposed to tell the user?It tells me that it performs an operation called Retinex on the image. If I did not know what the word Retinex meant then, just like any otherword with which I was unfamiliar, I would look it up. If Retinex is aninaccurate description of the processing taking place, a change in name might be called for but otherwise I would submit that the purpose of theGIMP is not to serve as a dictionary of graphics terms.Agreed. The manual should give a brief overview, which it does in this case: " "Retinex" improves visual rendering of an image when lighting conditions are not good. While our eye can see colors correctly when light is low, cameras and video cams can't manage this well. The MSRCR (MultiScale Retinex with Color Restoration) algorithm, which is at the root of the "Retinex" filter, is inspired by the eye biological mecanisms to adapt itself to these conditions. "Retinex" stands for Retina + cortex. Besides digital photography, Retinex algorithm is used to make the information in astronomical photos visible and detect, in medicine, poorly visible structures in X-rays or scanners." ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
> gg wrote: > > I also find as a user that menus often go too deep. > > One sub-menu is acceptable , two starts to get unwieldy. Eg. I ofter copy > a selection and Paste As New , this is three levels deep. I'd like to see > this at the same level as Cut: Cut | Paste | Paste as New. I crated a > hot-key as a work around but as others have said , I would rather keep my > eyes on the screen except for typing numbers etc. Is there a reason you don't use tear-off menus? Having small sub-menus actually enhances this utility. > Another improvement would to clean up some menus. The Blur menu seems to > contain several, largely equivalent filters. Two would suffice and could > be incorporated into Enhance. Which two would suffice? Personally, I find all of them useful and I wouldn't recommend combining filters that use different algorithms into one interface -- not only would this complicate maintenance and development but menu grouping is a great indicator of a command's function. > I also created a bug about making sure sub-menus did not jump from one > side to the other. This is appalling from a usability point of view but > the comment did not get a very positive response. If your proposal were accepted, there would be reports submitted complaining that all the submenus appear on the left when there might be only one that's overly-long. My preference is to minimize the number of times that my eyes have to "jump" from the far right of menu text to the far left of sub-menu (much less appalling to just "continue reading left to right"). > Some real basics like flip and rotating an image to straighten it up > should be on the image menu. Erm, they are. > Some anomolies could be looked at, I can free-rotate a layer but not an > image. Erm, you can. > Colors | Retinex ?? What's that supposed to tell the user? It tells me that it performs an operation called Retinex on the image. If I did not know what the word Retinex meant then, just like any other word with which I was unfamiliar, I would look it up. If Retinex is an inaccurate description of the processing taking place, a change in name might be called for but otherwise I would submit that the purpose of the GIMP is not to serve as a dictionary of graphics terms. "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] [GIMP] Suggestion to simplify user interaction
On Fri, 13 Oct 2006 12:15:51 +0200, Øyvind Kolås <[EMAIL PROTECTED]> wrote: On 10/12/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: Hi. I have a suggestion for a new and simple way to interact with GIMP. A major difficulty in using GIMP, in my experience, is that the menus are too many and too deep. To invoke an action on an image, or to open a dialog box, the user spends a lot of time and concentration navigating the menus, usually with the mouse. And, despite best efforts to organize the menus, finding the right item for the operation you want can be difficult. A more efficient alternative would be to let the user try to express his intention more freely, and show him a menu of options that might be what he wants. This is in effect search for the right command, and the user sees the list of options *as he types*. A command is any conventional menu item or folder in the current menu hierarchy. I guess you should have a menu or a similar interface in addition/tandem with a query interface. I have implemented a similar solution in my prototypes of more advanced layer interfaces and added one more thing, items can exist in multiple locations in the menu system with the aim to make it easier finding what you are looking for when only browsing the menu as well. http://pippin.gimp.org/tmp/search-menu.gif contains a recorded animation of the UI elements I've been using. /Øyvind K. I also find as a user that menus often go too deep. One sub-menu is acceptable , two starts to get unwieldy. Eg. I ofter copy a selection and Paste As New , this is three levels deep. I'd like to see this at the same level as Cut: Cut | Paste | Paste as New. I crated a hot-key as a work around but as others have said , I would rather keep my eyes on the screen except for typing numbers etc. Another improvement would to clean up some menus. The Blur menu seems to contain several, largely equivalent filters. Two would suffice and could be incorporated into Enhance. I also created a bug about making sure sub-menus did not jump from one side to the other. This is appalling from a usability point of view but the comment did not get a very positive response. Sometimes "logical grouping" of functions takes precedence over usability. Some real basics like flip and rotating an image to straighten it up should be on the image menu. Some anomolies could be looked at, I can free-rotate a layer but not an image. Colors | Retinex ?? What's that supposed to tell the user? It seems to be an enhancment filter to me. Making the menus a bit more usable may reduce the calls for a replacement. my-2c /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/15/06, Alex Pounds <[EMAIL PROTECTED]> wrote: On Sat, Oct 14, 2006 at 04:55:04AM -0400, Philip Ganchev wrote:> I suppose there are ergonomic advantages to one-hand command invocation if> 1. you hold the mouse with the other hand, and> 2. there is a keyboard shortcut for the action you want, and > 3. you know what it is without having to check.This is probably as good a place as any to ask: with this idea, has theimpact on graphics tablet users been considered? If we're talking aboutthis idea as a menu replacement (as opposed to a menu alternative), I think you're going to piss those users off. With menus you never have togo near the keyboard for editing if you don't want to; I'd imagine mosttablet users stay well clear from the keyboard when working, as they tend to be quite bulky (the tablets, not the users). The keyboard gets pushedoff to one side and the tablet comes to the fore.This is true; navigating the menus is quite quick by tablet (or the UI in general; it works far better than a mouse for UI navigation generally) Another issue is tear-off menus. The current functionality can be quite useful when performing a group of similar operations. I would expect the ability to tear off the currently selected search items to be a crucial part of a search feature. I've considered the idea of making keyboard shortcuts modifier-only.. This is not too bad. It does have the following issues: * There is no good reason to prohibit the F1,F2...F12 keys from being assigned without modifier (or the insert/home/end/pageup/pagedown keys), but if this is not done then it is inconsistent. * Requiring modifiers limits the number of keys available for effective keyboard shortcuts.On my keyboard, this means something like123',.aoe;qjon the leftand[]\l/= ns-wvzon the right.I think some, other things can be fixed without much complication. For instance, menu item selection is modal: if there are two conflicting mnemonics in a menu, then pressing that mnemonic the first time will select the first, pressing it again will select the second. The reason qualifies as modal is that it seems to be stored between menu accesses. For an example (with recent cvs) try this:Alt-C-A (then dismiss the menu)Alt-C-A (then dismiss)Alt-C-A (then dismiss) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On Sat, Oct 14, 2006 at 04:55:04AM -0400, Philip Ganchev wrote: > I suppose there are ergonomic advantages to one-hand command invocation if > 1. you hold the mouse with the other hand, and > 2. there is a keyboard shortcut for the action you want, and > 3. you know what it is without having to check. This is probably as good a place as any to ask: with this idea, has the impact on graphics tablet users been considered? If we're talking about this idea as a menu replacement (as opposed to a menu alternative), I think you're going to piss those users off. With menus you never have to go near the keyboard for editing if you don't want to; I'd imagine most tablet users stay well clear from the keyboard when working, as they tend to be quite bulky (the tablets, not the users). The keyboard gets pushed off to one side and the tablet comes to the fore. Although I don't have a tablet, that's how I use the gimp. The only time I go near the keyboard is entering text (rare) and entering numbers (slightly more common). For most tasks I'm entirely mouse-driven. If someone insisted I use the keyboard (and with both hands, if I'm typing full words) I would not be a happy user. -- Alex Pounds (Creature) .~. http://www.alexpounds.com/ /V\http://www.ethicsgirls.com/ // \\ "Variables won't; Constants aren't" /( )\ ^`~'^ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/12/06, David Gowers <[EMAIL PROTECTED]> wrote: [...] On 10/13/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: > On 10/12/06, David Gowers <[EMAIL PROTECTED]> wrote: > > On 10/12/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: > [...] [...] > A single key would definitely be peferable. What is the menu key? Is > it a standard key, found on most keyboards? Unfortunately not. It is a key found on keyboards with the 'Windows' keys or their equivalent. GTK treats it as an indication to pop up the menus (Alt does sort-of the same thing; Shift-F10 does exactly the same thing) You're not suggesting that Shift+F10 is better than Control+F, right? At least Control key and 'F' key are close to each-other. [...] > There is modality in that typing a key in search mode shows you > commands that match that key, while in normal mode it executes a > command. A way to avoid that is to use a quasi-mode, such as > searching only while Alt is pressed, and executing the selected > command when Alt is released. This may work, though I expect it would > be ergonomically hard. > > Instead, I would suggest that the single-keystroke commands be > removed. The search system does the same job in a much more general, > discoverable, understandable way (since it gives feedback). It is I cannot agree with that. I use those commands a lot, to switch paint tools for instance; there is no way that I could get the same speed of workflow if I was *required* to use the search system for basics like that. I think you overlook that, the value of keyboard shortcuts to a user's workflow. The people I know who use Gimp use it only occasionally, and they do not use shortcuts. I did not know they existed until someone mentioned it in reply to my post. I suppose there are ergonomic advantages to one-hand command invocation if 1. you hold the mouse with the other hand, and 2. there is a keyboard shortcut for the action you want, and 3. you know what it is without having to check. How many command shortcuts can a user be expected to remember? 10? 20? So we are choosing between the ergonomic convenience of one-key invocation for 20 commands, and the cognitive convenience of the general search for all commands, current and future. You say that moving your hand from the mouse to the keyboard takes too long. You must edit with lightning speed. For me, moving my hand to the keyboard is negligible compared to choosing the right points on the image to apply the selected tool, choosing the right color, etc. "transform, rotate the layer 90 degrees" That sounds awkward. In general, I think this form would be good VERB NOUN [..] (CATEGORY) where [..] is any additional part; category could be more that one, comma-separated, but would usually be only one.) so in this case Rotate layer 90 degrees (transform) Sounds good. I believe that you will find that leaving out the 'the' is necessary to make some of the longer command descriptions reasonably readable. Perhaps. I thought that using whole sentences would be clearer. For example, "rotate layer 90 degrees" can be taken as a phrase about a kind of layer, a "rotate layer". Clarity is important. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/12/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote offlist:
On Fri, 13 Oct 2006 00:08:29 +0200, Philip Ganchev
<[EMAIL PROTECTED]> wrote:
[...]
> Actually, the pop-up and dissapearance is not modal. The definition
> of "modality" that I know is "a difference in responce to the same
> user gesture depending on the system state, while the current state is
> not the user's locus of attention" (modified from The Humane
> Interface). There is no difference in response with respect to popup.
Glad s.o. brought that up . There is far too much modality in gimp for my
taste. I'm never sure what state I , or rather gimp, is in and what is
going to happen if I click on the image.
I have the same experience, and I agree Gimp is too modal. I have not
looked for any studies, but I think most Gimp users would have this
problem. It can be avoided in various ways.
1. Make the user more aware of the current state:
1.a. print the state in the status bar
1.b. improve the cursor icons that indicate state.
2. Make it easier to change to a familiar state like the "Select
rectangular regions" state,
2.a. for example, allow use of the Escape key, not just the 'r' key
2.b. When the user first changes the state for this session, pop up a
tooltip saying how to get back to the initial state ("Select
rectangular regions")
3. A way to return to the previous state. Currently, "undo" only
ondoes the changes to the image, but not the state.
That there are already a lot of states makes a stronger case for
avoiding keyboard modality. If a key press sometimes invokes a
command and sometimes narrows the search, these are two states and
probably two modes. To avoid that, we can use quasi-modes for one of
the states. A quasi-mode means that you have to keep pressing a key
to stay in the state. Because it is ergnomically awkward to hold a
key while typing, it is better for the quasi-modes to be for the
shortcuts. For example, "Control+R" invokes the "Select rectangular
regions" and "r" on its own starts a search. This is much easier than
holding Alt while typing "select", and only slightly less convenient
than just pressing "r". I think the ergonomic inconvenience is
justified by the cognitive convenience of not having to think about
what state you are in. I think there have neem studies with about
this, and I expect that the vast majority of Gimp users would prefer
it.
This would also make the query interface more discoverable because
simply typing brings it up. This is much more useful to casual users
than if the single key invocation is discoverable.
Some Control-key combinations are already used for other commands, but
you can use Control+Shift+key for the less common commands and no key
combos for the least common.
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/14/06, Philip Ganchev <[EMAIL PROTECTED]> wrote:
> Unfortunately not. It is a key found on keyboards with the 'Windows' keys or> their equivalent. GTK treats it as an indication to pop up the menus (Alt> does sort-of the same thing; Shift-F10 does exactly the same thing)
You're not suggesting that Shift+F10 is better than Control+F, right?At least Control key and 'F' key are close to each-other.Not on my keyboard. 12cm from the corner of ctrl to the corner of F; 13cm from the other ctrl key to the corner of F;
8.5cm from the corner of shift to the corner of F10.However, no, I wasn't suggesting that. Merely that the menu key should be supported for this purpose and indicated as the preferred method when possible. i.e
. 'use the Menu key to access the menu searching function; If you don't have a Menu key on your keyboard, use Ctrl+F'
The people I know who use Gimp use it only occasionally, and they donot use shortcuts. I did not know they existed until someonementioned it in reply to my post.I find it difficult to believe that you are in a position to comment on gimp usability, without experience with such a vital feature. Even the horrific MSPaint has keyboard shortcuts.
I also wonder how you could have possibly missed them, since they are printed right next to the menu items, just as is standard in modern UI design.
I suppose there are ergonomic advantages to one-hand command invocation if1. you hold the mouse with the other hand, and2. there is a keyboard shortcut for the action you want, and3. you know what it is without having to check.
How many command shortcuts can a user be expected to remember? 10?20? So we are choosing between the ergonomic convenience of one-keyI think I have about 40 memorized, of 60-70 I've defined (all custom -- I deleted every default one.); I admit I am atypical, however.
invocation for 20 commands, and the cognitive convenience of thegeneral search for all commands, current and future.
That's true, but tools are -- as their name implies -- used a lot. In particular, I often use the selection tools in combination with each other or with Blend or Bucketfill tools.
You say that moving your hand from the mouse to the keyboard takes toolong. I haven't commented on that subject at all (and it is not normally a problem for me -- I typically have the layout left to right keyboard, tablet, mouse; I draw righthandedly and key lefthandedly, using the mouse without putting down the tablet stylus when needed.)
However, moving a hand from the mouse to the keyboard -- which I remember from the bad old days when I didn't have a tablet -- is indeed a significant speed hit.
You must edit with lightning speed. For me, moving my hand tothe keyboard is negligible compared to choosing the right points onthe image to apply the selected tool, choosing the right color, etc.
All I mean is that I have also memorized many menu mnemonics, which are comparable to this proposed method WRT number of keystrokes, and using them is extremely sluggish compared to keyboard shortcuts.An example of the magnitude of the difference is picking colors by moving through a palette -- '(' and ')' are the shortcuts for that by default -- and manually finding an appropriate spot on the image and eyedropping. It's also directly comparable to your search idea. I say this completely seriously -- if I couldn't do such things as select between palette colors or tools quickly, or swap between FG/BG colors, GIMP would be almost entirely useless to me. I do not intend to work with chains around my wrists.
I use Gimp for creation PRIMARILY; It sounds as if you are thinking of GIMP as a tool for primarily editing and secondarily creation.The factors that you discard the significance of effect revision speed
a lot. Everything that interrupts your workflow is evil. This amounts
to anything more complex than a single-part keypress/mouseclick/tablet
gesture. An exclusive implementation of your scheme requires constant
searching and MANY keypresses.Example: I want to select pencil tool.P (choice of .. a lot of items)PE (choice of .. a lot of items)PEN (choice of 'Open', 'Open Location','Open as Layer', 'Sharpen (selection)','Blur / Sharpen', 'Sharpen (drawable)','Pencil' )
PENC (selects 'Pencil')versus keyboard shortcut'N' (or Shift+P in a vanilla gimp setup)versus menu mnemonics'Alt-T-P-N'That was one of the most conservative examples I could find; at best, it only matches the number of keypresses needed to use the existing menu access methods. Arguably, you could implement it to sort the items by how early the search strings occur; then you might be able to type pe[Enter] -- If you were looking for pencil tool rather than perspective tool.
Another example is UNDO/REDO! I cannot even really take seriously the suggestion of having such a vital feature immediately available.Do you really think that it could justifyably replace the existing system, with such a non-performance?
> I believe that you will find that leaving
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
* Philip Ganchev <[EMAIL PROTECTED]> [061013 23:09]: On 10/13/06, Øyvind Kolås <[EMAIL PROTECTED]> wrote: >http://pippin.gimp.org/tmp/search-menu.gif contains a recorded >animation of the UI elements I've been using. I did not understand what is the purpose of the interface in the animation. I see that you have some searching, but there is a lot of use of the mouse, which is generally inefficient. The purpose of the animation was not to demonstrate search, it is just demonstrating the capabilities of a very rough prototype. Which is also the reason the menu was used for browsing the available operations most of the time. That user interface was not, and still is not in a state where use by normal users would be encouraged; and it is still too early to put too much focus on a GUI for that system anyways since the architechture has many issues that needs to be fixed on a deeper level. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/13/06, Øyvind Kolås <[EMAIL PROTECTED]> wrote: [...] I guess you should have a menu or a similar interface in addition/tandem with a query interface. Yes, that's what I am suggesting. I do think the that the menu is unnecessary. For example, see the Archy project, started by user interface expert Jef Raskin, http://www.raskincenter.org/. But I am afraid that if I suggest replacing the menu, there will be so much opposition that the query interface will never be implemented and integrated into GIMP. World domination will come more sneakily :-) I have implemented a similar solution in my prototypes of more advanced layer interfaces and added one more thing, items can exist in multiple locations in the menu system with the aim to make it easier finding what you are looking for when only browsing the menu as well. Adding an item to more than one menu is probably a good idea. It must have been tried before, and perhaps even user tested, but I haven't researched to know whether it was useful or confusing. http://pippin.gimp.org/tmp/search-menu.gif contains a recorded animation of the UI elements I've been using. I did not understand what is the purpose of the interface in the animation. I see that you have some searching, but there is a lot of use of the mouse, which is generally inefficient. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On Fri, Oct 13, 2006 at 09:19:29AM +0200, Michael Natterer wrote: > On Fri, 2006-10-13 at 01:04 +0200, Michael Schumacher wrote: > > No. You don't want to look at emacs code. Really. Such an interface is > easy enough to implement, should we ever decide to want it. I seriously > doubt its usefullness for the vast majority of GIMP users. Why not??! As a user, I would very much welcome an emacs-style interface. Ctrl-H a (apropos) would logically do what is being discussed here. Ctrl-H c to describe the command associated with a key would be excellent as well. Those commands run lightning-fast in emacs compared with the snail-like workings of the gimp/gtk. But whatever you do, please, please, PLEASE do not do as one poster suggested and eliminate single-keystroke commands!! The ability to assign your own keys to gimp commands on the fly is one of its shining features, IMHO. Scott Swanson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/12/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: Hi. I have a suggestion for a new and simple way to interact with GIMP. A major difficulty in using GIMP, in my experience, is that the menus are too many and too deep. To invoke an action on an image, or to open a dialog box, the user spends a lot of time and concentration navigating the menus, usually with the mouse. And, despite best efforts to organize the menus, finding the right item for the operation you want can be difficult. A more efficient alternative would be to let the user try to express his intention more freely, and show him a menu of options that might be what he wants. This is in effect search for the right command, and the user sees the list of options *as he types*. A command is any conventional menu item or folder in the current menu hierarchy. I guess you should have a menu or a similar interface in addition/tandem with a query interface. I have implemented a similar solution in my prototypes of more advanced layer interfaces and added one more thing, items can exist in multiple locations in the menu system with the aim to make it easier finding what you are looking for when only browsing the menu as well. http://pippin.gimp.org/tmp/search-menu.gif contains a recorded animation of the UI elements I've been using. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
Michael Natterer writes: > No. You don't want to look at emacs code. Really. While talking about Emacsish features, one feature I often miss in GUI apps is something equivalent to Emacs's C-h c (describe-key-briefly). I.e., a way to find out what a certain keypress does. The main use case for this would be when you by accident press the wrong key, and you don't immediately notice anything happening, but you still are afraid that by mistake you have done damage to your document. OK, so in most well-written apps Undo will undo any such inadvertent changes. (But if you don't know if your accidental keypress did anything or not, you don't know what Undo will undo...). It helps a bit if the menu entry for Undo says what the last operation that are to be undone is called. Or if the app has a history feature. But still... --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On Fri, 2006-10-13 at 01:04 +0200, Michael Schumacher wrote: > Philip Ganchev wrote: > > On 10/12/06, Jakub Steiner <[EMAIL PROTECTED]> wrote: > > >> The two major use cases when this would be a more efficient interface is > >> for us GIMPers who already know what functionality they want and don't > >> need to go three levels deep, but also for novice users for who it will > >> perhaps be easier to search for 'replace color' instead of browsing > >> through the menu tree. If filters and functions have some additional > >> metadata, providing for example name of the same functionality in > >> competing graphic packages, things would become easier to discover for > >> novices. > > > > I agree that the commands should be searchable by many terms. But I > > think all terms should be part of the description, not be metadata. > > We should probably check how emacs does this - the M-x whatever-command > is pretty close to this proposal, and there are ways to seach for > specific commands as well. No. You don't want to look at emacs code. Really. Such an interface is easy enough to implement, should we ever decide to want it. I seriously doubt its usefullness for the vast majority of GIMP users. ciao, --mitch ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
Philip Ganchev wrote: > On 10/12/06, Jakub Steiner <[EMAIL PROTECTED]> wrote: >> The two major use cases when this would be a more efficient interface is >> for us GIMPers who already know what functionality they want and don't >> need to go three levels deep, but also for novice users for who it will >> perhaps be easier to search for 'replace color' instead of browsing >> through the menu tree. If filters and functions have some additional >> metadata, providing for example name of the same functionality in >> competing graphic packages, things would become easier to discover for >> novices. > > I agree that the commands should be searchable by many terms. But I > think all terms should be part of the description, not be metadata. We should probably check how emacs does this - the M-x whatever-command is pretty close to this proposal, and there are ways to seach for specific commands as well. HTH, 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] [GIMP] Suggestion to simplify user interaction
On 10/13/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: This can be avoided if the order of commands is predefined. Newcommands would have the least priority, unless they are expliciltymoved relative to others. For example if I add a new command "rotatecolors" and query for "rotate", it would appear after "rotate image" and "rotate layer", even though it comes before them alphabetically.This is a good idea; I cannot comment on what tecnical aspects would be needed to make it work. There is modality in that typing a key in search mode shows youcommands that match that key, while in normal mode it executes acommand. A way to avoid that is to use a quasi-mode, such assearching only while Alt is pressed, and executing the selected command when Alt is released. This may work, though I expect it wouldbe ergonomically hard.A fairly nice way would be like thisAlt-R (release alt) otate layerMore of the initial letters could be typed with alt if it suited the user. And of course, the query should be terminatable by pressing Escape.If there is no menu bar, the query box can pop up over the image. Or it can move the image down to make space when it appears. The first of these suggestions would work well. The second would almost certainly be very irritating. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/13/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: On 10/12/06, David Gowers <[EMAIL PROTECTED]> wrote:> On 10/12/06, Philip Ganchev <[EMAIL PROTECTED]> wrote:[...] > it doesn't map directly to normal menus. For example, there are> layer->transform menus and image->transform menus, both of which contain> identically-named entries. It's more like function-name completion; in that > case, no ambiguity exists because only one function of the same name can> ever be apparent. How do you make it convenient to choose either rotate the> layer 90degrees or rotate the image 90degrees? I reckon that might require > the addition of a separate string to use for completion instead of menu> name.Every command should have a description, such as "transform, rotatethe layer 90 degrees". If you type "rotate" you would see both "transform, rotate the image 90 degrees" and "transform rotate thelayer 90 degrees". If you type "rotate layer" or "layer rotate", youwould not see the former.I would argue that you need the "transform" part of the description above, because "rotate" commands should show up if a user searches for"transform".> It's possible that the menu registration code could address this (generating> unique completable command names); in that case you'd need to avoid the > possibility of newly added menu items causing the existing completion> behaviour to change (ie. where you type the same sequence but now get a> different and likely wrong result.)The descriptions can perhaps be automatically generated from the menu system. But it is probably better to edit them manually, to make surethey are concise and meaningful.How bad would it be if a new command appeared where you are used toseeing an old one? It would be bad mostly if you have habituated to a particular query pattern for a particular command, so that you hitEnter without selecting from the results.This can be avoided if the order of commands is predefined. Newcommands would have the least priority, unless they are explicilty moved relative to others. For example if I add a new command "rotatecolors" and query for "rotate", it would appear after "rotate image"and "rotate layer", even though it comes before them alphabetically. > > The search can be invoked with a key combination like Control+F> >>> > (or> > perhaps just by typing?).>> If this was implemented, I'd expect it to replace the menus, so personally I > would expect to just hit the Menu key and start typing. Ctrl-F is quite> unwieldy (if the function is going to be commonly used, a single key> trigger is highly desireable)A single key would definitely be peferable. What is the menu key? Is it a standard key, found on most keyboards?Unfortunately not. It is a key found on keyboards with the 'Windows' keys or their equivalent. GTK treats it as an indication to pop up the menus (Alt does sort-of the same thing; Shift-F10 does exactly the same thing) > What do you mean by just typing? clearly you cannot just type when the > completion is not yet active -- that would conflict with keyboard shortcuts.> And ifSomething missing here?I may have been thinking about mnemonics, but they shouldn't interfere. > The third option you presented, "appear when the keys are pressed and> dissapear when the command is executed." == modality, which tends to be > confusing and should be avoided if possibleActually, the pop-up and dissapearance is not modal. The definitionof "modality" that I know is "a difference in responce to the sameuser gesture depending on the system state, while the current state is not the user's locus of attention" (modified from The HumaneInterface). There is no difference in response with respect to popup.There is modality in that typing a key in search mode shows youcommands that match that key, while in normal mode it executes a command. A way to avoid that is to use a quasi-mode, such assearching only while Alt is pressed, and executing the selectedcommand when Alt is released. This may work, though I expect it wouldbe ergonomically hard. Instead, I would suggest that the single-keystroke commands beremoved. The search system does the same job in a much more general,discoverable, understandable way (since it gives feedback). It is I cannot agree with that. I use those commands a lot, to switch paint tools for instance; there is no way that I could get the same speed of workflow if I was *required* to use the search system for basics like that. I think you overlook that, the value of keyboard shortcuts to a user's workflow."transform, rotate the layer 90 degrees"That sounds awkward. In general, I think this form would be good VERB NOUN [..] (CATEGORY)where [..] is any additional part; category could be more that one, comma-separated, but would usually be only one.)so in this case Rotate layer 90 degrees (transform) I believe that you will find that leaving out the 'the' is necessary to make some of the longer command descriptions reasonably readable. _
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/12/06, Jakub Steiner <[EMAIL PROTECTED]> wrote: Hi Phillip, The two major use cases when this would be a more efficient interface is for us GIMPers who already know what functionality they want and don't need to go three levels deep, but also for novice users for who it will perhaps be easier to search for 'replace color' instead of browsing through the menu tree. If filters and functions have some additional metadata, providing for example name of the same functionality in competing graphic packages, things would become easier to discover for novices. I agree that the commands should be searchable by many terms. But I think all terms should be part of the description, not be metadata. Auxiliary terms could appear in parentheses and an understated color. Thus the user would be able to see *why* a particular command matches his search. Otherwise it would feel a bit magical, kind of like the current mechanism of invoking commands using a single keystroke. If the auxiliay terms appear in the description, the user would also learn what the given operation is called in Gimp. (And it's easier to implement than metadata.) Additionally this interface would allow to provide not only a brief name of the function, but also a small graphic demonstrating the function where applicable. I envisioned using a tile-based interface for this not unlike the beagle-search tool* but never gotten to mock things up. Feel like speccing things up? ;) [rearranged] * http://upload.wikimedia.org/wikipedia/en/5/54/Beagle-search.png A graphic would be great if this proves not to slow down the display of matches. I think it is imperative that the commands appear as fast as possible, and certainly in no more than 1 second. What do you mean by demonstration -- a thumbnail of the image that has been transformed with the command? Or performing the command on the whole image before the Enter key is hit? This may make it slow to navigate to the desired entry using the keys. Why do you think a tiled arrangement is better than a vertical list? I envisioned it like the Gmail address interface. I would love to make the description more formal, if someone tells me how. Is that what you mean by "spec things up"? This would be a nice summer of code project for next year. Agreed. Is anyone familiar with the process of creating a GSoC project? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/12/06, David Gowers <[EMAIL PROTECTED]> wrote: On 10/12/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: [...] it doesn't map directly to normal menus. For example, there are layer->transform menus and image->transform menus, both of which contain identically-named entries. It's more like function-name completion; in that case, no ambiguity exists because only one function of the same name can ever be apparent. How do you make it convenient to choose either rotate the layer 90degrees or rotate the image 90degrees? I reckon that might require the addition of a separate string to use for completion instead of menu name. Every command should have a description, such as "transform, rotate the layer 90 degrees". If you type "rotate" you would see both "transform, rotate the image 90 degrees" and "transform rotate the layer 90 degrees". If you type "rotate layer" or "layer rotate", you would not see the former. I would argue that you need the "transform" part of the description above, because "rotate" commands should show up if a user searches for "transform". It's possible that the menu registration code could address this (generating unique completable command names); in that case you'd need to avoid the possibility of newly added menu items causing the existing completion behaviour to change (ie. where you type the same sequence but now get a different and likely wrong result.) The descriptions can perhaps be automatically generated from the menu system. But it is probably better to edit them manually, to make sure they are concise and meaningful. How bad would it be if a new command appeared where you are used to seeing an old one? It would be bad mostly if you have habituated to a particular query pattern for a particular command, so that you hit Enter without selecting from the results. This can be avoided if the order of commands is predefined. New commands would have the least priority, unless they are explicilty moved relative to others. For example if I add a new command "rotate colors" and query for "rotate", it would appear after "rotate image" and "rotate layer", even though it comes before them alphabetically. > The search can be invoked with a key combination like Control+F > > (or > perhaps just by typing?). If this was implemented, I'd expect it to replace the menus, so personally I would expect to just hit the Menu key and start typing. Ctrl-F is quite unwieldy (if the function is going to be commonly used, a single key trigger is highly desireable) A single key would definitely be peferable. What is the menu key? Is it a standard key, found on most keyboards? What do you mean by just typing? clearly you cannot just type when the completion is not yet active -- that would conflict with keyboard shortcuts. And if Something missing here? > I am not sure if the query box should be > visible all the time, or appear when the keys are pressed and > dissapear when the command is executed. Personally I'd like it to show in place of the current statusbar message (sort of like an inverted browser URL field). In a program as big as the gimp, eliminating unnecessary widgets is important; so i suggest that probably such a thing would work best with a temporarily visible query box Agreed. The third option you presented, "appear when the keys are pressed and dissapear when the command is executed." == modality, which tends to be confusing and should be avoided if possible Actually, the pop-up and dissapearance is not modal. The definition of "modality" that I know is "a difference in responce to the same user gesture depending on the system state, while the current state is not the user's locus of attention" (modified from The Humane Interface). There is no difference in response with respect to popup. There is modality in that typing a key in search mode shows you commands that match that key, while in normal mode it executes a command. A way to avoid that is to use a quasi-mode, such as searching only while Alt is pressed, and executing the selected command when Alt is released. This may work, though I expect it would be ergonomically hard. Instead, I would suggest that the single-keystroke commands be removed. The search system does the same job in a much more general, discoverable, understandable way (since it gives feedback). It is useful for all commands, and is better for both novices and advaned users. > If it is the latter, it can replace the menu bar, to save window It can, maybe.. personally I don't have a menu bar, but I do have a status bar. I expect there will be some who have a menu bar, but not a status bar. It warrants some thought. True. I suggested menu bar because the search essentially replaces its function. At any time, if you are using the command search, you don't need the menus, so they are taking up space. A status bar has a different function and may be useful to tell you what to do with the search mechanism, such as "S
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/12/06, Marc Lehmann <[EMAIL PROTECTED]> wrote: On Thu, Oct 12, 2006 at 01:41:50AM -0400, Philip Ganchev <[EMAIL PROTECTED]> wrote: > For example. if the user types "size", he sees the options "Scale > image - resize the image", "Set canvas size", and "Print size". > Selecting the first option invokes resize mode, as if the item "Image > / Scale image" had been selected from the conventional menu. [...] But both gtk+ and gimp go towards beginner users in their UI: well-known interface design targetted at non-professional users that prefer the mouse over the keyboard (see for example the re-occurring discussion about the file chooser and its lack of efficient and simple completion). It is intended to be useful for beginners, in being efficient to find that they need. When I first tried to use Gimp years ago, it already had a large menu system that baffled me. Most of the time I had to search through menus for a way to do what I wanted with the image. I would take guesses and try the menu that seemed most promising, but often traversed half of the menus, and sometimes all the menu items twice! This repeated the next time I wanted to do the same thing! And still does today! I can't learn the menus, because they are too many (and the names are cryptic to me since I am not a design artist). > The search can be invoked with a key combination like Control+F (or > perhaps just by typing?). Just typing is better, but in GIMP you have too many (important) functions on your keyboard. [...] I had not realized this! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
Hi Phillip, The two major use cases when this would be a more efficient interface is for us GIMPers who already know what functionality they want and don't need to go three levels deep, but also for novice users for who it will perhaps be easier to search for 'replace color' instead of browsing through the menu tree. If filters and functions have some additional metadata, providing for example name of the same functionality in competing graphic packages, things would become easier to discover for novices. Additionally this interface would allow to provide not only a brief name of the function, but also a small graphic demonstrating the function where applicable. I envisioned using a tile-based interface for this not unlike the beagle-search tool* but never gotten to mock things up. Feel like speccing things up? ;) This would be a nice summer of code project for next year. * http://upload.wikimedia.org/wikipedia/en/5/54/Beagle-search.png -- Jakub Steiner <[EMAIL PROTECTED]> Novell, Inc. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [GIMP] Suggestion to simplify user interaction
On 10/12/06, Philip Ganchev <[EMAIL PROTECTED]> wrote: Hi.I have a suggestion for a new and simple way to interact with GIMP.A major difficulty in using GIMP, in my experience, is that the menusare too many and too deep. To invoke an action on an image, or to open a dialog box, the user spends a lot of time and concentrationnavigating the menus, usually with the mouse. And, despite bestefforts to organize the menus, finding the right item for theoperation you want can be difficult. A more efficient alternative would be to let the user try to expresshis intention more freely, and show him a menu of options that mightbe what he wants. This is in effect search for the right command, and the user sees the list of options *as he types*. A command is anyconventional menu item or folder in the current menu hierarchy.A query matches substrings of names or descriptions of commands. Thenames and descriptions of matching commands appear in a drop down box underneath the query box. The user can hit Enter to select the firstentry, or use the arrow keys to select another entry, then pressEnter. Thus the selection of actions and menus shrinks as the usertypes. If a query contains multiple words, they are matched as a conjunction (not as a string).For example. if the user types "size", he sees the options "Scaleimage - resize the image", "Set canvas size", and "Print size".Selecting the first option invokes resize mode, as if the item "Image / Scale image" had been selected from the conventional menu.I really like this kind of interface. Consider this, though:it doesn't map directly to normal menus. For example, there are layer->transform menus and image->transform menus, both of which contain identically-named entries. It's more like function-name completion; in that case, no ambiguity exists because only one function of the same name can ever be apparent. How do you make it convenient to choose either rotate the layer 90degrees or rotate the image 90degrees? I reckon that might require the addition of a separate string to use for completion instead of menu name. It's possible that the menu registration code could address this (generating unique completable command names); in that case you'd need to avoid the possibility of newly added menu items causing the existing completion behaviour to change (ie. where you type the same sequence but now get a different and likely wrong result.) The search can be invoked with a key combination like Control+F (orperhaps just by typing?). If this was implemented, I'd expect it to replace the menus, so personally I would expect to just hit the Menu key and start typing. Ctrl-F is quite unwieldy (if the function is going to be commonly used, a single key trigger is highly desireable) What do you mean by just typing? clearly you cannot just type when the completion is not yet active -- that would conflict with keyboard shortcuts. And if I am not sure if the query box should bevisible all the time, or appear when the keys are pressed anddissapear when the command is executed.Personally I'd like it to show in place of the current statusbar message (sort of like an inverted browser URL field). In a program as big as the gimp, eliminating unnecessary widgets is important; so i suggest that probably such a thing would work best with a temporarily visible query boxThe third option you presented, "appear when the keys are pressed and dissapear when the command is executed." == modality, which tends to be confusing and should be avoided if possible If it is the latter, it can replace the menu bar, to save windowIt can, maybe.. personally I don't have a menu bar, but I do have a status bar. I expect there will be some who have a menu bar, but not a status bar. It warrants some thought. space. The the list should not obscure too much of the image. So,the size of the results box should be constrained, and a scrollbar should appear if needed.The history of executed commands (and their descriptions) appears inreverse order the results box, if the user clicks on or presses theDown arrow key in an empty query box. sounds okay. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] [GIMP] Suggestion to simplify user interaction
Hi. I have a suggestion for a new and simple way to interact with GIMP. A major difficulty in using GIMP, in my experience, is that the menus are too many and too deep. To invoke an action on an image, or to open a dialog box, the user spends a lot of time and concentration navigating the menus, usually with the mouse. And, despite best efforts to organize the menus, finding the right item for the operation you want can be difficult. A more efficient alternative would be to let the user try to express his intention more freely, and show him a menu of options that might be what he wants. This is in effect search for the right command, and the user sees the list of options *as he types*. A command is any conventional menu item or folder in the current menu hierarchy. A query matches substrings of names or descriptions of commands. The names and descriptions of matching commands appear in a drop down box underneath the query box. The user can hit Enter to select the first entry, or use the arrow keys to select another entry, then press Enter. Thus the selection of actions and menus shrinks as the user types. If a query contains multiple words, they are matched as a conjunction (not as a string). For example. if the user types "size", he sees the options "Scale image - resize the image", "Set canvas size", and "Print size". Selecting the first option invokes resize mode, as if the item "Image / Scale image" had been selected from the conventional menu. The search can be invoked with a key combination like Control+F (or perhaps just by typing?). I am not sure if the query box should be visible all the time, or appear when the keys are pressed and dissapear when the command is executed. If it is the latter, it can replace the menu bar, to save window space. The the list should not obscure too much of the image. So, the size of the results box should be constrained, and a scrollbar should appear if needed. The history of executed commands (and their descriptions) appears in reverse order the results box, if the user clicks on or presses the Down arrow key in an empty query box. What do you think? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
