Hide selected elements via context menu/keyboard shortcut

[lwrage]

[lwrage]

Also provide simple way to show a hidden element again?

[philip-alldredge]

The behavior of this operation will need to be fleshed out a bit.

Currently, determining what elements appear is an additive process. The user can use filters so that elements are automatically added. The default values of these filters are driven by the diagram type. However, individual business objects can be selected if desired.

The graphical editor has menu shortcuts for adjusting the filters without using the configure diagram dialog. It also has a shortcut that will take the user to the appropriate location in the configure diagram for manually selecting elements. The latter option makes it easy to show a hidden element and it similar to other modeling tools.

Since determining the contents of a diagram is an additive process, hiding an element may be a non-trivial operation. For example: if the user selects to hide a feature when all features are configured to be shown, what should happen?

• Should the appropriate filters be disabled and then the appropriate elements manually selected? That will achieve the result but may not be what is intended. At that point additions to the model may not appear on the diagram because some of the filters will be disabled.
• Should the graphical editor maintain a list of elements that are hidden? This is the most flexible implementation and the one that can capture the intent of the user is more cases. However, it adds additional complexity to something that can already be confusing to users.

This complexity is the reason why there isn't a context menu option. The highlighting in the configure diagram dialog provides some feedback about what the result of the change will be. For example: if the user unchecks something and it is still highlighted, it means there it is covered by a filter.

[philip-alldredge]

Implementation note: this will need to include enhancements to the diagram configuration system. Ideas were discussed with Lutz via email in October 2018.

[philip-alldredge]

This is an early version of the final design. See later comments for update.

In order to implement this and similar features, the diagram configuration system needs to be adjusted. The current system is additive and does not allow the concept of "hiding". There have been multiple occasions where the diagram configuration system is not intuitive to users. Merely adding element hiding to the current user interface will likely result in additional confusion depending on exact implementation. The goal is to simplify the user interface and provide a consistent way of customizing the diagram without removing capabilities.

User Visible Changes

• Rework context menu as the following:
  • Show Contents [Selecting will show specified elements but will not automatically add elements in the future.]
    • All [All contents. Will add elements which are not included in any filter]
    • Subcomponents
    • Features
    • ...
    • Other... [Alias for Configure Diagram...]
  • Show Contents Automatically [Toggles. Replaces the current "filters". Once applied, only affects new elements. Enabling should override previously hidden elements. Disabling should prevent future automatic additions].
    • All [All contents. Will add elements which are not included in any filter]
    • Subcomponents
    • Features
    • ...
  • Hide [Hide the selected element and descendants]
  • Hide Contents [Hide children that match the specified criteria.]
    • All [All contents. Will hide elements which are not included in any filter]
    • Subcomponents
    • Features
    • ...
    • Other... [Alias for Configure Diagram...]
• Remove "Filters" section from "Configure Diagram" dialog. [Is it beneficial for it to be there? Functionality will be available through context menu. It seems to be a source of confusion and complicates the dialog.]
• Add context menu to model tree in "Configure Diagram" dialog. Context menu will match the portion of the diagram editor's context menu for hiding/showing contents. Allow selecting multiple elements.
• Allow user to explicitly show and hide Generalization and Subprogram call order elements. Add appropriate elements to such elements.
• Update User Guide

Backend Changes

• Add All filter or equivalent.
• Only use auto content filters to set the visibility of new elements.
• If an element passes filters but the user has hidden it, store somehow. Either has a flag on the element or as a separate list. In any case, will need to keep up to date when diagram is refactored, etc. When to purge? Could purge such elements on save if they no longer pass the filters?
• Consider renaming auto content filters.
• Increment file format version.

Compatibility Considerations

• This change will add additional data to the diagram file. There will not be any known backward compatibility issues. However, forward compatibility should be considered. Need to ensure that opening a file with a hidden element results in a warning but does not fail. It is acceptable for the hidden element to be shown. Need to consider potential issues when considering serialization format.

If this is implemented as described. Will also resolve #1216.

[lwrage]

@philip-alldredge

• Is show contents automatically intended as a setting per element or per diagram?
  My first reaction is that it should be per diagram to keep things simple. Per element may be more flexibile but likely confusing.

• Hide/show contents could be a single entry with checkboxes (initially populated from show contents automatically). That way the user can check what should be shown (if it's in the model).

[philip-alldredge]

@lwrage
Thanks for bringing this up. The comments below are not meant to be dismisive but to explain the rationale to promote additional discussion.

Show Contents Automatically - Per Element vs Per Diagram

Show contents automatically is intended as a per element configuration. With the exception of being able to essentially override it by hiding an element, it identical to the current functionality of the Show menu/filters. The name change is to clearly reflect its modified behavior after the ability to hide an element is added. Adjusting it to be a per diagram setting would reduce functionality which is not necessairly a bad thing if the functionality is not needed, but I believe it is needed.

Besides flexibility, the reason why it currently implemented as a per-element setting is that to do otherwise renders is unusable for larger models. For example if the user selected subcomponents, features, and connections in a diagram of a top level system implementation in a large model, then an unreasonably large number of elements would be shown. Since the subcomponents filter is enabled, it would be recursive. The user would be forced to avoid use of the Show Automatically feature. With the new "Show" menu, this wouldn't be quite as large of a burden as in the current version of the editor but it does hinder flexibility.

On the other hand, if it was implemented as a per diagram setting, a warning could be shown when a large number of elements would be added due to recursion.

Additionally, the current diagram type system sets filters on a per element basis. It cannot function without this capability being available internally.

Checkboxes for Hide/Show contents

That was something I had considered but decided against. The reason why I am proposing making them separate menu items is to make them explicit and unambigious. I don't believe the checkbox allows the user to express what they would like to do clearly.

Given an inital model/diagram:

• ExampleSystem(Classifier) - Visible
  • sc1(Subcomponent) - Visible
  • sc2(Subcomponent) - Visible

Having a single menu item in that case would work fine. The ExampleSystem->Show/Hide->Subcomponents would be checked and the user can easily hide them by unchecking it. However, if the user disables "sc2" manually the following diagram results:

• ExampleSystem(Classifier) - Visible
  • sc1(Subcomponent) - Visible
  • sc2(Subcomponent) - Invisible

Since only a subset of the subcomponents are being shown, then we would need to either decide to represent it as checked/unchecked/gray(tri-state). However, we would have to decide whether activating the menu item should hide or show all the components. Since there are cases where each one is a reasonable thing for the user to do, I am proposing having them as separate menus.

An alternative would be to show separate menu items when both options are possible but that would require checking what model elements are available and would result in a dynamic number of menu items. The latter is not prefered because I believe it makes it more difficult for the user to find the desired menu item.