Qt Mainwindow skeleton done. [focus on menus]

[Dirk Hohndel]

Amit Chaudhuri <amit.k.chaudhuri at gmail.com> writes:

> Hi,
>
> here's a proposed outline of a remodelled set of menus.

Thank you. It's good to see this get some structured design for a change :-)

> Top level entries are marked with asterix. Menu items are prefixed '>'.
>
> I don't think we need sub-menus, but for the view stuff (relating to the
> main 3 GUI elements only) I think an additional context menu might be worth
> it.  Qt menu stuff makes that very easy.
>
> Square brackets around the main rationale for each section.
>
> Various comments added inline.
>
> * File * [All major app, config & file operations]
>
>> New
>> Open
>> Save
>> Save As
>> Close
> ----------
>> Import
>> Export
> ----------
>> Print
> ----------
>> Preferences       // zoom toggle moves to here; so does filter events &
> autogroup

I guess filter is so rarely used (and should be accessible from a
context menu on the profile - instead of just being able to "delete this
event" we should also add "filter out all similar events") that I can
see moving this to preferences.
Zoom toggle is also less critical now with the profile zoom, but in
general it's not a good choice for a preference as this is something
that a user might want to toggle when looking at one dive...
Autogroup has intentionally been moved out of the preferences a while
back. That was mostly because we had BOTH, preferences and the menu
function... So this might work, too.

> ----------
>> Quit
>
>
> * Dive Computer * [Dive computer operations or equivalent]
>
>> Download
>> Edit device names
>> Renumber
> ----------
>> Add dive

Add dive and Renumber are both not really functions of the dive
computer, right?

> * Web * [All web operations]
>
>> Web Download
>> ..??                // what else might we do with the web service?

We do the Companion App sync
We do sync with divelog sites (not sure, but I think this needs to be
"import from" and "export to" as a 'real' sync is a major pain in the
rear to implement (what happens if you made changes to the same dive on
both sides...)
We should have "open map with this dive / all dives in browser"

> * Planner * [All planning stuff]
>
>> New plan
>> ..Copy plan         // if we need new plan features they live here
>> ..Delete plan       // these two [copy, delete] sprung to mind as examples
>
>
> * View * [Window & view management]
>
>> Info               // maybe add Ctrl+F6 & shift Ctrl-F6 to cycle through
> these 4?
>> Profile            // Plus context menu..?
>> List
>> All
> ----------
>> Statistics
> ----------
>> Locations          // the map stuff (or maybe move to Web section?)

Map displayed in the app should be here, maps displayed in a browser
window go into the Web menu?

> ----------
>> Next Computer      // what do these two do - maybe move to Dive Computer
>> Previous Computer  // if these relate to dives grouped by DC?

If you have multiple dive computers you rotate through them (in the
profile window). Linus initially added them as menu entries, I added key
bindings and I think that the menu entries are kind of odd for this.
Open to suggestions.

> * Help * [User help & info]
>
>> About subsurface
>> Help
>> ..Report bugs      //

I like the "report bugs" entry. I should add this on the Gtk side for
our next (and maybe final?) Gtk release.

> I wonder about an alternative scheme which has an explicit 'edit' top level
> menu.  In that scheme one might group the preferences and any editing
> functions here.  Edit / add dive / plan / locations / preferences....but
> not sure that's necessary/desireable if the gui elements allow in place
> editing nicely.

Well, Edit could have 

* Edit
 > Renumber Dives
 > Add Dive
 > Plan Dive

On some OSs the Preferences can be here (on Mac they are in the Apple
menu).
Not sure what location related things would fit here

/D