Oops, links for last post:
[0] https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/art/mn_dualtoggleditems.jpg [1] http://drive.dakotacarto.com/qgis/layer_datasource_submenu.png Larry On Wed, Apr 24, 2013 at 10:46 AM, Larry Shaffer <lar...@dakotacarto.com>wrote: > Hi, > > On Wed, Apr 24, 2013 at 9:24 AM, Nathan Woodrow <madman...@gmail.com>wrote: > >> William, >> >> I can understand the concern, it was the same thing that went though my >> mind when I change the composer menu. In the end most people didn't care, >> or adapted. There are a lot of applications that don't use a file menu >> and work quite well, I would say better in fact. >> >> http://i.imgur.com/t0QZeJK.png Chrome and Firefox >> >> http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg >> AutoCAD >> >> Regarding the Edit menu, you will notice that the tools in there are not >> related to text or documents they only refer to the current feature, or >> selection of features. If you have a dialog open you can't use that menu, >> unless the dialog is non model and in that case still doesn't help you as >> there are no tools to use on text. >> >> If the Edit menu is to stay, that is fine however I would suggest a new >> menu called Feature/s which houses all the current tools in the edit menu >> minus the Undo/Redo and Copy/Paste Feature. >> > > While the Mac HIG clearly states that changing the name of the File menu, > or removing the File menu, is fine, the following are definitely not a good > idea in my opinion: > > * Having anything except Edit to the right of File/Project > That would not only be unconventional and confusing to users, it gains > very little compared to the significance of the change. IMO it should > absolutely be avoided. Clearly the Mac convention here is to have File, > Edit, [View], [Main Component], [Lesser Component], etc. (older Mac > conventions had View more towards right end of bar) This is shown in > Apple's Mail program [0], where the main component is a mailbox and the > lesser a message. In Photoshop it is: File, Edit, Image, Layer... > Following these conventions any Feature menu should be located just right > of the Layer menu, and the Layer menu just right of Edit or View. > > * Moving Layer items into Project menu > While using almost all Mac software the File menu is visited only when > initiating, saving, exporting, printing, or ending a work session, > regardless of whether it is file-based in nature. While working within the > session, almost always component menus are used. For example, a similar > layer-based program, Photoshop, places all it layer-related actions under > the Layer menu, not the Image menu. IMO the Layer menu actions should stay > where they are > > However, the menu could be cleaned up a bit. Having a submenu for adding > data sources, and sub-grouping by type with separators, will allow growth > of the submenu without cluttering the main Layer menu [1]. > > * Moving editing function out of Edit menu > The main editing currently done in QGIS is on features, aka 'Digitizing' > for the toolbar, so it is logical for those editing functions to be under > the Edit menu. I agree with William in that undo/redo should always be > located there, as well as copy/cut/paste and delete functions. Currently > copy/cut/paste refers to only 'features,' which makes no sense if you are > not editing features. Those should be generic and only be Copy/Cut/Paste > and Delete or Clear, or be dynamic and change relative to what is being > edited (that would be more work, though). > > So, maybe there should be a Digitizing submenu under Edit. Other items > that programs commonly place under the Edit menu (some not currently > implemented in QGIS) are spell-checking, text manipulations (upper, lower, > etc.), special character inserts, select functions (currently under View), > find/search functions, and others. So there is functionally room to grow in > that menu, outside of just feature editing actions, i.e. Edit menu should > not be considered for removal. > > > As a separate suggestion: if we wanted to minimize our menus better and > prepare for unknown future functionality grouping and expansion, we could > create a Tools main menu, which could have Vector, Raster, Database and > Analysis submenus. This would make room for a Feature main menu, for > example, and allow future growth within Tools without forcing yet more > horizontal growth of the menubar. Downside is that it adds an extra layer > of submenu mousing to get to commonly used actions. > > Regards, > > Larry >
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer