|Re: [tracecompass-dev] Ideas about pin and new view features|
Hi, On 2016-12-07 03:20 PM, Patrick Tasse wrote:
Hi,On Wed, Dec 7, 2016 at 9:45 AM, Jonathan Rajotte Julien <Jonathan.rajotte-julien@xxxxxxxxxxxx <mailto:Jonathan.rajotte-julien@xxxxxxxxxxxx>> wrote:As said in the previous status meeting, the proposed patches are restrictive so we can work our way up while providing a basic solid way for users to actually compare traces/time range. We are looking at this feature as a first step in a marathon not the last one.For some parts at least, it seems to be more work to be restrictive so it might be a wasted effort if it's not going to be part of the end solution.
Yes it might be, again this provide a solid base with minimal quirks.
That being said, I think it might be a good idea to separate the concept of pinning the 'trace' and pinning the 'time' (for this discussion pinning 'time' refers to synchronizing both the window range and the time selection). When you create a new view instance, it's not really useful to have the new instance unconstrained by both time and trace. Otherwise you have two views that show exactly the same thing (well, you could scroll up and down and have different filters, but that will be still be possible with my following suggestion...). So there is a basic value even without the pin feature. Those two things are not possible as of today (in the same TC instance). What I would suggest is that a new view instance should be pinned by 'trace' permanently. "pinned by 'trace' permanently.". I would like to disagree here. By doing that you prevent user from controlling their work flow. It also add complexity and does not fit in the actual paradigm of TC (view update based on the active trace).I wasn't suggesting to make all existing views pinned to a trace, just the new (cloned?) instances.
Another specific behavior. Less specific behavior more uniform behavior.
It would still have been possible to have a view unpinned (e.g. following the active trace), but only for one instance of the view.So let's see how it goes with the current proposal to allow multiple unpinned view instances.
There is value there, not for all views but for all those that have vertical/internal states.
However, I'm still thinking that we might want to decouple the controls for pinning (to a trace) and synchronizing (to time). More below.Furthermore, all such views pinned to the same 'trace' should be 'time' synchronized together permanently. Again "permanently". This does not look very "flexible".This requirement I feel should stay, as it seems intuitive and in line with the current design. The trace manager has a context per trace instance (which has the window range and time selection), and all views and editors that show that trace instance (whether they are pinned to the trace or unpinned while that trace is active) are time-synchronized.It make this probably common use case easy for the user: If you create new CFV and RV instances and pin them to Trace B, then they are time-synchronized together, and with their corresponding trace event table.
Not sure what is the use case here. Could you illustrate it ?
This is actually the use case that triggered me to start this thread... So for example if you have two traces opened, Trace A and Trace B. Trace A is the active trace and Control Flow view (CFV) and Resources view (RV) show Trace A. If you create a new instance of CFV, you somehow have to decide which trace it should be pinned to, let's say Trace B in this example. What would be the "somehow" ? In the proposed feature it is simple: it always sync with the global context since a new view instance is not pinned.I was thinking a "New View" sub-menu or subsequent dialog, but let's try it as proposed with a togglable pin to trace.Now you have CFV-B and you pin it in 'time' so that it is no longer synchronized with Trace A. CFV-B is linked with Trace B but synchronized in time with trace A ? This all boils down to the discussion going on here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=508332 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=508332> Having multiple traces that are not part of an experiment synchronized in time is confusing.I disagree that it's confusing if it's what you want, but perhaps it is not what *you* (or some users) want or expect. I'm open to the idea of having this synchronization off by default, but I think it should always be an option available to the user, without having to create experiments.If you then create a new instance of Resources view RV-B pinned in 'time', I don't think we want to have three independent time selections. You just hit the main problem. Multi-selection is an out-of-your-mind idea for the current Trace Compass paradigm. Some part always query the global state and would not care about the pin notion. A solution to that is to mutate the notion of global context to a notion of last encountered context and provide a list of possible selections when it is necessary. This is no small changes but can be done incrementally and is one the main reason that the proposed features are restrictiveI don't share or understand your concerns here. In the current implementation each trace has its own time range and selection. Those that overlap are synchronized automatically. What is global is the current active trace. So views that show the global active trace can get that specific trace's time range and selection, it is not a random or undetermined (i.e. confusing) selection. You currently can have two trace editors opened side-by-side and they each have their own selection (if they do not overlap).
"If they do not overlap" is the major problem here. You start by saying: "In the current implementation each trace has its own time range and selection" but you follow with "if they overlap" you share the selection for both of them. What I'm having a problem with is that selection can influence trace context that do not belong to the active trace. It may or may not happen (intersect or not).
You would have to manually browse in CFV-B and RV-B separately to keep them aligned. Hence the proposal to have CFV-B and RV-B permanently time-synchronized. And they would also be time-synchronized with their pinned trace Trace B so that you could correlate the trace events with the selection in those views. Then what happens to the pinning by 'time'? I think this should be a state of that trace instance. Trace B is either pinned to its own time, or it is time-synchronized with the other unpinned traces. I will reiterate my disagreement here regarding time synchronization across intersecting traces/experiments. There is little reasons for two experiments/traces to synchronize themselves in time if one is considered inactive (not shown to the user) and the other active. It is simply confusing for users that most of the time do not work on intersecting traces and expect a state for one trace/experiment and a separate state for the non active traces/experiments. The day they get intersecting traces and try to do dual selection on both to compare, all of a sudden they get the same state for both trace. This is simply complicated.Keep in mind that the inactive traces can still be shown to the user through the trace editor. It's just the graphical views that currently only show the active trace.
Let's hope this get resolved ASAP and we find a way toward showing multiple trace at the same time in multiple views. It might be just the graphical view but they are 98% of the reason users use trace compass otherwise they would be using Babeltrace (regarding ctf and lttng).
So automatic trace synchronization is apparently not something you want, but you have to be open to the idea that for some users it might be the only reason they use the tool. They might have two custom text logs that create no graphical view whatsoever, they just want to open them both and browse them together, keeping the trace editors synchronized. They currently can do this without having to bother about experiments.
No it is not something I want when they are not under an experiment. What is the purpose of an experiment?
From the user doc:
"An experiment consists in an arbitrary number of aggregated traces for purpose of correlation. In the degenerate case, an experiment can consist of a single trace. The experiment provides a unified, time-ordered stream of the individual trace events."
Seems like a good fit here. Maybe the experiment part of Trace Compass is missing some love ?
I hope they heard of vim, emacs and other text viewer that most probably do a better job than TC at having split view for text, they even support offset scroll binding these day!
This propagates to all the views that are trace-pinned to that trace instance. The control of time-pinning should be available also from the trace editor and kept in consistent state with the views. One future possible incremental change was to introduce the notion of pinning groups. In a pinned group you receive signal and broadcast to the group.This would change the behavior of TC in a major way. Here we are doing baby steps while fulfilling a basic user need: comparing two or more CFV/RV visually in the same eclipse instance and at possibly two or more different visual time ranges.It sounds like a good feature to allow customizing the pinning groups. The current implementation behaves a bit like an automatic pinning group: traces that overlap are in the same pinning group and this cannot be avoided. The proposed pin feature now allows the user to opt-out of that pinning group.I would propose to have a change of terminology to go along with my suggestions: if we restrict 'pinning' to the trace (e.g. pinning is fixing the trace for that view), we can have a separate control to 'synchronize' the trace in time with other traces. And perhaps synchronizing could be an opt-in instead of an opt-out. However this would be a change of default functionality for current users.Let us now consider the case of a user that wants to view two different window ranges of the same trace. When creating a new view instance, the user would choose the same trace that is currently shown in the original view. This would create a new instance of the trace and open it in its own editor. This would allow the user to view and synchronize the trace events of the two examined regions concurrently, e.g. CFV-A(1) synchronized with Trace A(1) and CFV-A(2) synchronized with Trace A(2).I wasn't sure how to handle this now, but I thought of a simple solution: Currently when we 'open' a trace that is already opened, it only makes that editor active. All that would be required if a user wants to browse two different areas of a trace, would be to open it twice (and get two editors). Then each trace instance has its own context, and each instance's views are synchronized together. Obviously here it would make sense to have time synchronization off by default in the new instance...A use case that this allows, is a user that wants to view two different areas of the same trace in CFV for example, might also want to concurrently see the corresponding trace events for each area. Having two separate trace editors opened allows that.With regards to the ongoing discussion about time synchronization, now that we are implementing a pin feature we could have time-synchronization being an opt-in instead of an opt-out. All that is required is to have the pinned state set by default when opening a trace (or it could be a user preference). Wasn't time synchronization a promoted feature ? " Because this time synchronization of two or more opened traces is a promoted feature of the tool since the very beginning (before it was Trace Compass)."My point was that time synchronization shouldn't be removed as a feature because some users still want it. I'm trying to accommodate both sides by perhaps having it off by default. I'm not sure what your point was?
The point was: one second time-synchronization is a promoted feature the other it become an opt-in.
Some other ideas that the above design could enable (the devil is in the details): Actually there is code currently that most probably deal with 80 to 90 % of use case regarding all of this without reimplementing TC. The main problem regarding the pin feature is actually how to deal with multi selection in multiple pinned view. Otherwise other features regarding visual time range can be enabled. More infos in the RFC email.I think my suggestions deal nicely and intuitively with time selection of multiple trace instances: one trace instance = one time selection, and the 'synchronization' toggle controls whether these time selections affect each other.
Must have missed the "'synchronization' toggle controls" the first time. Could be a solution. I still believe this a feature for an experiment/trace collection.
When opening a view from the Window > Show View menu, you would get the unconstrained view (the one without a secondaryId) that follows the active trace. But when you open a view from the Project Explorer 'Views' subtree under the trace, you would get a view that is automatically pinned to that trace. When closing a trace it would automatically close all views that are pinned to that trace. Moving away from the eclipsy/ide paradigm. Bold move.That seemed like the only option that made sense in my original suggestion where cloned views were permanently pinned to a trace instance.Otherwise, there are more options, I'm not sure which is more intuitive? - Close the pinned views- Unpin the pinned views unconditionally (possibly leaving multiple unpinned views showing the same trace) - Unpin the pinned views if there exists no corresponding unpinned view instances, otherwise close the pinned views (leaving at most one unpinned view)With a togglable pin it would always be possible to have multiple unpinned views, so it's really just a question of automatically cleaning up the workbench or not.Thinking about the future enhancement of having a common container for all views related to a trace instance, then closing the pinned views would mean that closing the trace would be akin to closing that future container.
Starting with the container might be the way to go here.
We can put the current patch set on hold while you prepare a working prototype of all this. I'm having a hard time picturing all of this. I'll still make sure to provide multiple versions of the proposed pin feature: restrictive and one with all features except those touching the current selection.I would propose as a first step to have a patch set where pinned views are isolated from external synchronization but without any navigation restrictions.
Will try my best to it. But selection is still a challenge.
Then the possible next steps could be (I'm not sure in which order): - Split trace-pinning and time-synchronization control- Have time-synchronization from same trace instance apply unconditionally (I guess this requires trace instance in the signal)- Allow multiple trace instances of same trace opened at same time
From a meeting this morning here at EfficiOS:Let's say we draw the final form we would like: http://donot.review/up/tc/rfc/tc-ui-per-trace.txt
Lots of missing scenario but most of them should work okai and we think it addresses most of your concern.
As you probably observed we share a common goal and maybe other aspects: a sort of container. Here a trace but could be a trace collection, notebook, workgroup. Interactions do change based on what is the container. "Trace" limits the content to view showing information about the trace, same for experiment/trace collection. Notebook and workgroup could be more flexible and allow multiple views showing different traces data etc.
In all cases signals would be restricted to the container. The event table become another view.
Where does pin fit in this scenario? A pinned view inside the container would simply stay under the container and act on its own (time wise) under the container. How to deal with multi selections is an open question. One solution is to allow selection inside a pinned view and all views not pinned sync to it (as usual). A selection made outside of pinned view (another pinned view or any view) would update the selection inside of the pinned view but does not update the visual time range (for visual windows base view). You end up with always one selection.
So from this end goal what do we do now with the current proposed features.Pin become a view state like filters and other view states. On trace change we simply fetch the previous state related to this view/trace tuple and if it was pinned simply populate the pin state (signal blocking etc.) This allow user to have multiple views of the same type (Control flow view, resource view) on different visual time range etc. but does not allow comparison between traces. It remove ambiguity regarding what belongs to what and would fit better in the end goal. It prevent us from exposing a feature to a user that will probably not be useful in the end.
So for short term goals:"I would propose as a first step to have a patch set where pinned views are isolated from external synchronization but without any navigation restrictions."
-> Investigate the most permissive pinning policy for CFV and RV.-> Change the pin behavior regarding trace changes. Migrate the pin to a per trace view state.
-> Figure out how to handle selection in a pinned view. Obviously I will postpone the introductory email a little bit. Cheers
Patrick _______________________________________________ tracecompass-dev mailing list tracecompass-dev@xxxxxxxxxxx To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/tracecompass-dev
-- Jonathan R. Julien Efficios
Back to the top