Three Dot Menu Prototype

[charlesh88]

Overview

• Replaced placeholder inline styling;
• Style for menu's c-menu __section-separator and __section-hint refined;
• Defined default color for c-icon-buttons;
• Changed many buttons from c-button to c-icon-button;
• Make button labels hide/show based on frame size in Layout, and hidden when in a Flexible Layout;
• Changed Snapshot-related buttons and menus to use icon-camera;
• Normalized padding for c-icon-buttons;
• Added a CSS class c-so-view--<domainObject.type> to allow sub-layouts with hidden frames to completely hide their headers and buttons - this is needed to avoid overlap collisions with further sub-objects;
• Changed button styling in main view to be more in line with 'iconic' approach used elsewhere, enabled button labels where applicable;
• Better, more consistent hover approach for c-button and c-icon-button controls;
• Changed Snow theme constant hover filter value for better color matching;
• Fixed c-object-label type-icon opacity;
• Changed Snow theme constant for object name to fix inline editing of object name being too dark;

Todos

• @charlesh88 Make all frames within a Flexible Layout hide frame control labels by default. File issue for enhancement to make this a dynamic evaluation on resize.
• Menu actions should be edit and browse-specific. Example: "Remove" for an object being edited.

- [ ] Some menu actions, while properly disabled in the menu, shouldn't be disabled as buttons. Example: "Unmark All Rows"

[akhenry]

This is looking super cool. This is going to make the user experience SO much nicer, awesome work both of you.

@deeptailor I have some ideas on ways we might be able to simplify the API a little from the developer's perspective. Interested to hear your thoughts.

1. It would be great if there was just one way of registering an action, irrespective of whether it's an object action or a view action (because it could be both):

openmct.actions.register(actionDefinition);

The appliesTo method would then have the object path and view context passed to it:

appliesTo(objectPath, viewContext) {
}

2. We should try to find a way of ensuring that views themselves do not have any responsibility for the lifecycle of actions. It will lead to memory leaks.
   One way to do this is to have actions registered once, by the plugin, rather than the view. The view would just hide/show enable/disable the actions as needed.

eg.

// Returns an `ActionCollection` that is scoped to this view instance
let actionsForView = openmct.actions.get(objectPath, viewContext);
actionsForView.disable(['export-marked-rows']);
actionsForView.enable(['unmark-all-rows']);
actionsForView.hide(['expand-columns']);
actionsForView.show(['autosize-columns']);

The object frame could then use the same .get() function to get an ActionCollection:

let actionCollectionForView = openmct.actions.get(objectPath, viewContext);
let listOfActions = actionCollectionForView.list();
let statusBarActions = listOfActions.filter(action => action.showInStatusBar);

The disable, enable, hide, show functions could then trigger an event on the actionCollection
eg.

actionCollection.view.on('change', (updatedListOfActions) => { ... });

The object frame would need to clean up this listener, but that's in platform code (ObjectFrame.vue), view developers would not have to deal with cleaning it up.

[akhenry]

@deeptailor If you can resolve the conflicts I'll merge this today

[deeptailor]

Closes #3298

[deeptailor]

Author Checklist

Changes address original issue? Yes
Unit tests included and/or updated with changes? Yes
Command line build passes? Yes
Changes have been smoke-tested? Yes
Testing instructions included? Yes, in Issue

[akhenry]

Reviewer Checklist

1. Changes appear to address issue? Y
2. Appropriate unit tests included? N/A - followup
3. Code style and in-line documentation are appropriate?
4. Commit messages meet standards? Three dot menu needs unit tests #3525
5. Has associated issue been labelled unverified? (only applicable if this PR closes the issue)