Open zeptonaut opened 8 years ago
One interesting problem: if we want to be able to pin tracks, then we presumably also want to be able to unpin tracks. When we unpin one, we presumably want it to go back to where it was in the ordering before being pinned. But how do we know where it was in the ordering?
A couple of ideas:
Alright - after thinking a little bit more about this, I think that option 3 might be our best bet.
One concern that I had was with track nesting. Suppose that we had 3 tracks, nested like so:
Suppose that we start out by pinning track a. The tracks now look like this:
Pinned tracks
Normal tracks
Now suppose that we pin track 1. The end result that I think we should see is this:
Pinned tracks
Normal tracks
(empty)
In order to do this, when we go to pin track 1, we need to check if any of the already-pinned tracks have it as an ancestor. We do this by checking the originalParent
field of the pinned track, then following the DOM up, looking for the track currently being pinned. If we don't find it, great: just go ahead and pin the new track. If we do find it, that's okay too: we just have to unpin the existing track (moving it back to its original location in the DOM), then pin the new track, and everything should look like we want it to above.
This bookkeeping is definitely a little annoying, but I'm not sure I see any obvious ways around it. I also think that we should be able to keep all of it within some sort of a PinnableTrack
base class. This base class is necessary, anyhow, because not all tracks should be pinnable (pinning a single rect-track within an async-slice track would be silly).
Would it be useful to separate out the class hierarchy that creates the tracks, from the layout of the tracks? I think the 1:1 relationship between tracks and the containers is really problematic for future ui that we want anyway...
Basically I'm wondering if this is one of those cases where "the simple feature ends up being jut as hard as doing the right thing, so lets figure out the right thing instead."
On Tue, Mar 8, 2016 at 7:05 AM, Charlie Andrews notifications@github.com wrote:
Alright - after thinking a little bit more about this, I think that option 3 might be our best bet.
One concern that I had was with track nesting. Suppose that we had 3 tracks, nested like so:
- Track 1
- Track i
- Track a
Suppose that we start out by pinning track a. The tracks now look like this:
Pinned tracks
- Track a (With 'originalParent' set to 'Track i')
Normal tracks
- Track 1
- Track i
Now suppose that we pin track 1. The end result that I think we should see is this:
Pinned tracks
- Track 1
- Track i
- Track a
Normal tracks
(empty)
In order to do this, when we go to pin track 1, we need to check if any of the already-pinned tracks have it as an ancestor. We do this by checking the originalParent field of the pinned track, then following the DOM up, looking for the track currently being pinned. If we don't find it, great: just go ahead and pin the new track. If we do find it, that's okay too: we just have to unpin the existing track (moving it back to its original location in the DOM), then pin the new track, and everything should look like we want it to above.
This bookkeeping is definitely a little annoying, but I'm not sure I see any obvious ways around it.
— Reply to this email directly or view it on GitHub https://github.com/catapult-project/catapult/issues/1790#issuecomment-193816351 .
I'm not sure I understand. I totally get the separation of the view and model . But aren't tracks a view-only concept? Shouldn't the only representation of them be in the view?
Right now tracks are 1:1 to DOM elements and to model objects, so the DOM embodiment, layotu etc are all entangled.
I was muttering about maybe we should have a thing that walks the model to generate a list of actual renderable tracks and some potential grouping, e.g. rect_tracks tagged with a process name as a group. Etc.
Then we have another system that consumes that list, maybe shufffles it around if people have dragged or pinned, then creates the DOM entities that lay the actual track tree out.
On Tue, Mar 8, 2016 at 10:10 AM, Charlie Andrews notifications@github.com wrote:
I'm not sure I understand. I totally get the separation of the view and model . But aren't tracks a view-only concept? Shouldn't the only representation of them be in the view?
— Reply to this email directly or view it on GitHub https://github.com/catapult-project/catapult/issues/1790#issuecomment-193896495 .
Looking through the code, I'm not super concerned about the entanglement between the tracks and the DOM elements being a major blocker to the implementation of any track pinning logic. The bigger blockers that I've noticed are more around cleanliness of the track view code. For example, a logical place to put some sort of a "pin this track" icon would be in the track heading next to the title of the track. I think it's a decently safe assumption that any track that's important enough to have a heading should be pinnable. However, it turns out that every track has a heading, but it's just empty for a lot of tracks. We do this because we use the heading as a means of making the track title area blue with a black right border.
I think that there were some other strange structural problems like this that I've run into while trying to pin tracks as well. IMO, when implementing track pinning, we'd reap more rewards from fixing these track-view annoyances than taking a more major detour to change the track model altogether.
Tracks in trace viewer should be "pinnable", in a similar way that Chrome tabs are pinnable:
position:fixed
on the track.