<div dir="ltr"><div>Oops,<br><br></div>links for last post:<br><br>[0] <a href="https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/art/mn_dualtoggleditems.jpg">https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/AppleHIGuidelines/art/mn_dualtoggleditems.jpg</a><br>
[1] <a href="http://drive.dakotacarto.com/qgis/layer_datasource_submenu.png">http://drive.dakotacarto.com/qgis/layer_datasource_submenu.png</a><br><div><div><div class="gmail_extra"><br clear="all">
</div><div class="gmail_extra">Larry<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 24, 2013 at 10:46 AM, Larry Shaffer <span dir="ltr"><<a href="mailto:larrys@dakotacarto.com" target="_blank">larrys@dakotacarto.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Hi,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Apr 24, 2013 at 9:24 AM, Nathan Woodrow <span dir="ltr"><<a href="mailto:madmanwoo@gmail.com" target="_blank">madmanwoo@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">William,<div><br></div><div>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.</div>
<div><br></div><div><a href="http://i.imgur.com/t0QZeJK.png" target="_blank">http://i.imgur.com/t0QZeJK.png</a> Chrome and Firefox<br></div><div><a href="http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg" target="_blank">http://images.autodesk.com/adsk/images/autocad_context_sensitive_presspull_large_900x577.jpg</a> AutoCAD<br>
</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div></div></div></blockquote><div><br></div><div>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:<br>
<br></div><div>* Having anything except Edit to the right of File/Project<br>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.<br>
</div><div><br></div><div>* Moving Layer items into Project menu<br></div><div>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<br>
<br></div><div>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].<br>
</div><div><br></div><div>* Moving editing function out of Edit menu<br></div><div>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).<br>
<br></div><div>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.<br>
</div><div><br><br></div><div>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.<br>
</div><div><br></div><div>Regards,<br><br></div><div>Larry <br></div></div></div></div></div></blockquote></div></div></div></div></div>