Community
Participate
Working Groups
Let's say I do a run that gathers data for the statistical view. Then I do another one. Now I have two runs in my Profiling Navigator. Every time I bring up the statistical view, the horizontal (time) slider resets so its right edge is the current time. That's not what I want: if the run I'm viewing is a historical run (and has terminated), all the data is off the screen to the left someplace. When the statistical view opens for the first time or changes the run whose data it's showing, a much more sensible behavior would be to "Snap to associated graphs," especially if the run in question has terminated. This doesn't involve storing any per-run or per-view state: it is something you can do based only on the run whose data you're viewing. Even better would be to remember the last scroll/zoom state of the slider(s) on a per-run basis. Imagine: I have two runs in my Profiling Navigator. I examine the statistical view of one, and scroll/zoom to the interesting spot. Then I click on the other run (with the "Link With Viewer" button pressed), and I scroll and zoom to the corresponding part of that one. Click back to the first, and wham! I've lost the scroll and zoom I did.
This is a problem with the view rather than the editor. When we originally designed StatCon we made it an editor specifically because if you set up a lot of state looking at a statistical model and you wanted to keep it you had to have a file to keep it in, much like a PerfMon configuration file (either that or store it in the models themselves but the statistical models don't have anywhere to store viewer state). The editor never resets its scales because its allowed to keep state. Viewing two runs in the editor is easy because you can add references to two statistical models and even have them on different horizontal scales. However, the statistical view could snap to the associated graphs as suggested.
I would suggest opening with good defaults (snap to associated graphs). I'm not sure I like the idea of modal behavior for editors/viewers in general where it is based on the data being viewed. For example, when you open a Word document, Word preserves the settings and look of the editor used to create the document; so if you get two documents from two different people, your Word looks completely different, which I think is bad. I think it's a generally accepted UI principle to avoid modal behavior if at all possible.
Curtis, this is a problem only with the statistical view. The editor shouldn't change its existing configuration when a statistical model is added because there may already be other statistical models which the user has configured their view over (the editor's configuration should be stable while users add and remove statistical models). Given this this addition should not be made to the underlying graphing components but to the view code. If you want the view to snap to associated graphs then in the view code where a statistical model is loaded it should call the snap to associated graphs function on the relevant time slider.
This will be addressed as part of enhancement 78509
This will be taken into account in enhancement 78509 *** This bug has been marked as a duplicate of 78509 ***
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
