Skip to content
This repository has been archived by the owner on Nov 20, 2023. It is now read-only.

Event table should allow range selection of events #67

Open
PSRCode opened this issue Feb 16, 2018 · 4 comments
Open

Event table should allow range selection of events #67

PSRCode opened this issue Feb 16, 2018 · 4 comments
Labels
design Ongoing design discussion

Comments

@PSRCode
Copy link
Contributor

PSRCode commented Feb 16, 2018

No description provided.

@ghost
Copy link

ghost commented Feb 19, 2018

Should it really?

Right now the single-event-selection binds to a framework-level range selection of a single timestamp, corresponding to the event's timestamp. If we allow multi-selection in the table, then should we bind it to a corresponding framework-level range selection? Probably, so it stays consistent, no?

But if we do that, then comes the weird part: that means we have to bind framework-level range selections to multi-selections in the event table. Which in turns means that every time you select a time range in any view, you end up with an event table that shows all its events highlighted. When everything is highlighted, nothing stands out.

I'd be tempted to allow the table to only support single selections, and to have a range-selection in the framework to simply select the event at the start time of the selection, not the whole range. I'm of course very open to suggestions, but we should keep the framework-time-range <-> event table multi-select duality in mind.

@PSRCode
Copy link
Contributor Author

PSRCode commented Feb 19, 2018

All other widget allow a range selection but the event table should not ?

Isn't the value of the current selection paradigm to "highlight" across the board the selected time range?

Which in turns means that every time you select a time range in any view, you end up with an event table > that shows all its events highlighted. When everything is highlighted, nothing stands out.

This depends on the visible range of the event table widget. You could say the same for the thread widget with a small visible range inside a larger selection. Everything will be blue.

@ghost
Copy link

ghost commented Feb 26, 2018

You could say the same for the thread widget with a small visible range inside a larger selection. Everything will be blue.

Very true. However with a time-based widget you can zoom out. With the event table, you cannot zoom out, you are confined to a very very limited range. This fundamentally different to other zoomable time-based view, which is why I'm tempted to think range selections should behave differently.

@PSRCode
Copy link
Contributor Author

PSRCode commented Feb 26, 2018

Following IRL discussion:
A partial solution here could be the introduction of a format style (light blue or the color of the selection in all opther widget) for rows comprised inside the current global selection.

This would decouple us from the "selection" paradigm of the table.

A follow-up could be to have a "commit selection to global state" for the event table allowing a user to move around and click/select inside the table without disturbing all other widget. This would go hand in hand with the support of multi selection/zone of interest.

@ghost ghost added the design Ongoing design discussion label Apr 5, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
design Ongoing design discussion
Projects
None yet
Development

No branches or pull requests

1 participant