[Qgis-developer] 'File' versus 'Project'

[Larry Shaffer]

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 <larrys at dakotacarto.com>wrote:

> Hi,
>
> On Wed, Apr 24, 2013 at 9:24 AM, Nathan Woodrow <madmanwoo at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20130424/bda47dd5/attachment.html>