> 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 line drawn? My own preference is to tend towards the wishes of the developer of the command (Fabien Pelisson), out of respect for his contribution. -------- "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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
