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
