Hi Patrick,
Many thanks for your answers.
1) Retrieving bookmark through
trace->editorInput->editor->bookmark is OK, but a bit
clunky, isn't it ?
Yes, I've a use-case for needing the bookmarks file for a
trace.
For my product, the time chart view is the most important:
- it gives a clear overview of the program execution. In
other words, most of the added-value is contained in this view.
Users often focus on this view only. They want to control
everything from this view.
Therefore, I've added a command to add bookmarks directly from
the time-chart.
For now, this command uses TmfExperiment.getBookmarksFile().
2) Hummm... it's perhaps time to enhance that...
On the same topic, I think the standard bookmark view is a bit
poor.
In my product, I provide an "enhanced" bookmark view,
displaying the following content:
Name
|
Timestamp
|
Delta to next
|
Source
|
Type
|
File
|
Content
|
bookmark1
|
1,234,567
|
1,000,000
|
src1
|
type1
|
file1
|
arg1=value1
|
bookmark2
|
2,234,567
|
n/a
|
src2
|
type2
|
file2
|
|
It's similar to the Event editor, but displays only bookmarks, and
has 2 additional columns:
- one with the bookmark name.
- one with the "Delta to next". It's very efficient to calculate
durations.
Xavier
On 02/05/2014 04:52 PM, Patrick Tasse wrote:
Hi Xavier,
1)
I had to go back far to remember when
TmfExperiment.getBookmarksFile() was introduced. It is a
leftover from when we had an Events view that needed to get
the file from its experiment to pass it to the embedded events
table. The Events view did not support traces, only
experiments, that is why the method is not in TmfTrace.
We have removed the Events view since and improved the
bookmarks file handling along the way so this method is no
longer used. It could probably be removed, unless you have a
use case for needing the bookmarks file for a trace? Now the
bookmarks file is always the file passed to the editor init()
method in the Tmf/FileEditorInput, so there is no need to get
it from the trace or experiment directly.
If you have the file you can find the matching editor, look
at for example how TmfOpenTraceHelper.findEditor() is used. If
you have the editor you can get the file from its editor input
and the trace from the ITmfTraceEditor interface. I notice
there is also a getBookmarksFile() in that interface but I
think this could also be removed, we can use getEditorInput()
cast to IFileEditorInput instead...
2)
That is the intended behavior (for now) probably because
there is no obvious solution for the alternative behavior...
The bookmarks location is the rank in the trace/experiment. In
the case of an experiment, when you have an event and its
experiment rank, how do you know its underlying trace event
rank? Similarly, if you have a trace rank how do you get the
corresponding rank in an experiment? There might be a solution
but we haven't taken the time to figure it out yet. But I
agree that your alternative behavior might be better,
especially if that is intuitively what users expect.
Since 3.0 the ITmfLocation is serializable so that might be
an option to use this as location in the bookmark. But finding
the rank from a location takes some processing/parsing time.
Patrick
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
