Extend the list of resource usage items, and also enable user-selection for items to show in the bar

[andreww-msft]

At present, when the user targets an app, we not only add the app icon + name, but also the CPU usage of that app. We also arbitrarily include the overall system resource usage items for CPU, memory and disk. These were never intended to be fixed items. Rather, the intention was to illustrate the kinds of information we could provide, and that these would be user-configurable. Also at present, we show the per-app CPU usage on the left in the bar, three system usage items on the right in the bar, and three per-app items (including the CPU usage) at the bottom of the expanded mode window. Having multiple locations, duplicated items, and arbitrarily selected items is confusing, and for many users will not be useful. These need to be rationalized.

Proposal

1. All resource usage items should be user-selectable.
2. They should be selectable from the complete list that we offer in the main Resource Usage tab.
3. The user can select 0..N items.
4. The user can select per-app items, or system-wide items, or both. All items of both kinds go in the Resource reports panel.
5. Resource items that the user selects to pin to the bar are only pinned to the bar; they are not duplicated anywhere else outside the main Resource reports panel in the bar.
6. Each selected item must have a tooltip. We will differentiate per-app vs system-wide items in the tooltip. Eg “FooApp CPU%” vs “System CPU%”.
7. Each item on the Resource Usage tab should include a description that is sufficiently detailed so the user can understand and can distinguish it from other similar items, eg: Name | Value | Description.
8. The item descriptions must be precise. Right now, we have simplified labels: for example, right now we say “Memory usage”, whereas the per-app value is actually the private working set, and the system-wide value is the committed bytes. Going forward, we must use strictly accurate labels where possible, and strictly accurate descriptions at all times.
9. For each item value, we will use formatting similar to what TaskManager uses (for example, report memory in MB rather than bytes).
10. For each item we include, as part of validation, we must compare with TaskManager. Where TaskManager lists the same item, the value reported in PI and TaskManager must be the same (within reasonable tolerances).
11. We must use the same naming as TaskManager for the same item.
12. As we expand the list of items, we can consider each potential candidate on its usefulness. For example, instead of simply listing one memory item for the target app, we could list all the individual memory items that are available. Not all of them are necessarily useful, so we’ll be judicious in selecting a suitable subset.
13. The tooltip for an item on the Resource reports panel can be a shorter summary of the Resource Usage tab description, where necessary – long tooltips for bar items can be problematic, especially when the bar is in collapsed mode.
14. When the user is not targeting an app, we remove the app’s icon & name from the bar. Similarly, we will also remove any per-app resource items – these only show up when the user is targeting an app.
15. The list of items in the main Resource Usage tab will be extended to many more resource types and sensor readings.
16. The list of items in the main Resource Usage tab will be divided into two categories: per-app and system-wide, and each category will be presented as an Expander. Note some items will appear in both categories, eg “Per-app CPU%” and “System CPU%”.
17. We’ll do the work to notify the user if she accidentally tries to pin multiple instances of the same item – this will not be allowed.
18. We will continue to provide three items by default, just to illustrate to the user that this is an option: system-wide CPU, memory, disk usage.
19. As the set of resource/sensor items increases, we will provide some useful structure, rather than a flat list. In early prototypes, we used a LibreHardwareMonitor component which offered a tree of menu-items, so we might need some similar tree layout. We could group items into meaningful categories.
20. Where the set of resource/sensor items is big enough, we will consider the performance implications, and perform updates on background threads, etc to ensure we don’t degrade the UX, and don’t degrade either PI startup or rendering of the Resource usage page.
21. (Lower priority): offer a “pause/resume all updates” toggle-switch on the Resource usage page.
22. (Lower priority): offer a right-click “un-pin” menu on each item that the user has pinned to the bar. They will be able to remove each item by going to the Resource usage page and changing their settings – so this is a nice-to-have.
23. Consider a maximum number of items.

[xhan65]

Investigating

[andreww-msft]

Closed by #3755

[jaholme]

Needed to revert due to problems with Librehardwaremonitor