Re: [linuxtools-dev] Using the Time Graph Viewer and contributing to the

[Generoso Pagano <generoso.pagano@xxxxxxxx>]

Hi Alexandre,

Thanks a lot for the fast reply!

> In our framework, we have the notion of signals (TmfSignal, etc.), and a
> common one is the TmfTimeSynchSignal, which is sent by any view where an
> active time range can be selected. That way, other views can react to
> the new time range. This is how the time range selection can be
> synchronized across views.
> 
> I don't know your specific use case, I'd be tempted to suggest you use
> something like the TmfTimeSynchSignal directly. But if you want to other
> view to react *only* to a selection from the Time Graph view, you could
> implement a new signal which is sent by the time graph view and only
> listened by the component your want.
> 
> Of course this would imply also importing the notion of TmfSignal's in
> your application, which you may or may not want to do ;)  But if you
> plan to use the time graph view, this time-selection part would work as-is.

Thanks for pointing me towards the Tmf signal mechanism. If my understanding
is correct, currently the TmfTimeSynchSignal is sent only at the *end* of a 
selection: e.g., I click on the Time Graph, I move the mouse, I release the 
mouse button, and only at this moment the signal is sent.

My need is slightly different, since I'd like to be notified about the current 
selection *while* it is changing (during the mouse move, which is handled by
the TimeGraphControl). 
For this reason, in my patch, I introduced the ITimeGraphDragSelectionListener, 
which is called in the TimeGraphControl.mouseMove() in the case 
(DRAG_SELECTION == fDragState).

It is maybe not necessary to introduce a new type of listener and event 
(ITimeGraphDragSelectionListener and TimeGraphDragSelectionEvent) as I did, 
since the ITimeGraphTimeListener and the TimeGraphTimeEvent already existing 
can do the job. However, the modifications to the TimeGraphControl (fire the 
listener call during mouse move), are in my opiniong still necessary to provide
the functionality I need.

If I'm missing something, thanks for putting me on the right path! :)

> That sounds great! That filter dialog could really use some love.
> Interestingly, on Linux one can search the entries by using GTK's native
> search-as-you-type in this window. But it is still quite limited. A
> better, cross-platform solution would be a nice improvement.

Yes, I was thinking about a line, on top of the dialog, with:
- a simple text field for the filter
- two buttons to navigate (previous, next)
- maybe a checkbox to enable showing only the matching items (instead of all 
  the items).

> This sounds interesting too. Sometimes a user might want to look for
> something at a given time, without having to scroll through the whole
> thing up and down.
> However, I am not sure how this could easily be done within SWT. Mainly
> because of the "tree" part, on the left of the view, which is
> implemented using a SWT TreeViewer, which in turn defers to the native
> widgets, which usually have a fixed size. Patrick can probably give more
> details (and correct me) here. If you have some ideas we'd be glad to
> hear them though!

I agree. I think that to have the vertical zoom a custom reimplementation of
the tree viewer will be necessary...
Indeed, vertical dezooming could be very usefull to get a global overview 
of the system execution, expecially to indentify synchronization points (e.g., 
barriers) among several entities (it is often the case with parallel/HPC 
applications, which are important for our project).

> Don't hesitate and let us know if you have any questions. Hope to see
> some collaboration in the future!

I find your project really interesting and well done, so I'm eager to provide
some contribution :)

Cheers,
Generoso