Added filtering and other options to SampleView of Databrowser

[thomas1028]

This PR includes multiple changes to the SampleView of the Databrowser.

1. SampleView contextmenu can move it's pane up or down if someone prefers to view the samples and property tab simultaneously.
   
   

2. Item selection includes option for "All Items", which displays the samples of all visible PVItems. Selecting this option also adds a "PV" Column to differentiate between the sources
   

3. Additional Columns in the Properties Tab for setting a kind of Filter and a value for it.
   This allows users to only view samples that fulfil a condition.

• Alarm Up: the alarm value has increased from previous sample
• Alarm Change: the alarm value has changed at all compared to previous sample
• Threshold Up: The sample value has increased compared to previous sample and passed threshold. Threshold set in "Threshold Value" column
• Threshold Change: The sample value has passed the threshold value compared to previous sample. Threshold set in "Threshold Value" column
  

The Threshold filter types can be applied to all numeric PVItems, including enums. For enums it needs the index of the desired enum value.

4. Sample Count displays total and visible amount
   Samples can be hidden through the filter or by hiding the source item. Hiding the source item only hides samples when viewing samples from All Items.
   

[georgweiss]

Works as described, but I have some comments on usability:

• The "Move Samples View Up/Down" feels a bit superfluous. After all, you can drag the divider to set the vertical size of the samples view.
• To set/unset/change filter you need to switch between samples view and properties view. It would be easier if filter controls would be added to the samples view. Since user selects a trace in the dropdown, the filter UI controls could be updated when selection changes (and disabled when user selects "all"). Also, if the filter selection is moved to the samples view, an update can be triggered automatically, currently user needs to click Refresh.
• Filters "Threshold Up" and "Threshold Change" overlap a bit. Is "Threshold Down" not a relevant use case?

[thomas1028]

Thank you for the comment. Having the Filters in the Sample View is a good idea.
I'll work on implementing that, as well as your other notes, and will update the PR when ready.

In our use-case it would be helpful to to be able to view the Sample View in addition to the Properties. Our goal was to have a kind of log view of archiver data as an alternate view to the plot.
By moving up the divider we still leave the Data Browser toolbar as well as the tab bar which isn't quite ideal.

I'll work on implementing the rest of the notes and try to think of a more elegant approach for the sample view, since we would prefer to have that as an option.

[georgweiss]

@thomas1028, sorry for slow feed-back.
I have tested your PR and it seems to work as expected. However...

I've had a discussion with another developer about this feature. Our joint conclusion is that we should maybe consider a separate Phoebus application that would be designed around inspecting and analyzing archiver data. Putting the filters in the samples view of the Data Browser feels a bit odd as filters do not affect the plots, only the table of samples. After all, plotting PV values is the primary purpose of the Data Browser.

Any thoughts?

[kasemir]

separate Phoebus application that would be designed around inspecting and analyzing archiver data

I like the idea of keeping the data browser as a tool to plot samples over time.
The sample view is mostly meant to debug the data browser, to maybe explain why the plot looks the way it does, to see the values of enumerated or string samples which aren't too useful for a plot.
Further analysis of the data is a wide open field. You might want to count changes of some PV, see how often a value exceeds some threshold, accumulate the time a PV was within a range of values. There are many use cases, and I think that's best handled by scripts or the like outside of the data browser. That's one reason why here at SNS we keep the archived data in an RDB, making it available to many tools. For the archive appliance I assume it's also relatively easy to get data from the web service into for example a python script where you can then do whatever's necessary for the task at hand.