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
On Tue, Feb 4, 2014 at 4:35 AM, Xavier Raynaud
<xavier.rayn...@kalray.eu <mailto:xavier.rayn...@kalray.eu>> wrote:
Hi,
I've some question about the way bookmarks are managed in TMF.
When playing with an experiment, a special resource is created to
store bookmarks (TmfExperimentElement.createBookmarksFile()).
And the same with a single trace
(TmfTraceElement.createBookmarksFile()).
However:
1) TmfExperiment has an API to retrieve bookmark
(TmfExperiment.getBookmarksFile()) but not ITmfTrace.
Is it intentional ?
What about having #getBookmarksFile() API at ITmfTrace interface
level ?
2) Moreover, when a user creates bookmarks on a experiment, they
are not retrieved when opening a single trace of this experiment
(and vice-versa).
I already had some questions from users on this topic.
Do you think we can improve this behaviour ?
Xavier
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@eclipse.org <mailto:linuxtools-dev@eclipse.org>
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
