Hi Alexandre, Thanks for the answers (and sorry for the late reply!).
> Ok I see. Indeed the signal is not sufficient here, you want to be > notified whenever the user is dragging. Wiring a listener here would > make sense. > > You could push this patch to Gerrit, we'd be happy to look at it. I'll do it, thanks. > Sounds good! Just wondering, what do you mean by previous/next here? > > Also, I'm not sure if a checkbox would be really needed. You often see > "filter text fields", which are text fields with a <[X] "button" on the > right side. If there is something written in the box, only the maching > elements are displayed. The user can either remove the text or click the > button to remove the filter and see all the entries again. > > I'm not even sure if there is such a widget in SWT, but I feel it would > work well here. Thoughts? I admit I've been a bit cryptic here :) I was thinking about not necessarily hiding the non-matching elements: you can highlight the matching elements instead, and use a next/prev button to navigate through the highlighted elements. Finally, the checkbox would state if the non-matching elements are actually displayed or not. By the way, your solution seems simpler and more intuitive for the user. The expected behavior should be something like: if there is something written in the text box, only the maching elements (and possibly their parents or sons nodes in the tree) are displayed. > We may revisit the whole notion of the time graph viewers and > TimeGraphCombo in the upcoming months. One feature request that we get > more and more often is to be able to "align" the width of different time > graph viewers, so that their X-axes are all the same. Right now, every > view can have a different width, so even if their time range are > synchronized with the TimeSynchSignal's, the position is not the same in > every view, which is annoying. > > This means we could drop the notion of TimeGraphCombo completely then > (the extra information for each label could go in the Properties view, > for example). Which means we wouldn't use TreeViewer widgets, which > means it would become doable/easier to also zoom those viewers > vertically. Stay tuned! > This sounds great! I'll stay tuned. Cheers, Generoso _______________________________________________ linuxtools-dev mailing list linuxtools-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
