add a border between contigs / scaffolds / features so it is obvious to users (JBrowse changes)

[nathandunn]

TODO

• support padding #996
• fix initial scaling issue on load #996
• add general color-coded label
• can the "overview" be colored, but the direct version not be colored?
• [x] fix grid for genes
  • [x] fix for individual genes
• [x] add a searchbox for names back
• [x] pin to very top
• [x] set always on (if projection)
• [x] add track for index for relative location where we are at (REST-backed)
  • [x] extend custom type use (or be like) LocationScale or develop type
  • [x] align all of the grid marks so that there is no 0-20K-25K . . should be 0-20-40
  • [x] adjust for zoom by rendering inner-ticks in fillBlock (instead of renderFeatures) or just remove those blocks from the store and re-ping
  • [x] should be an ending AND beginning of each track
  • [x] track label should be the current projection
  • [x] set height
• Bookmark should go over annottrack as well (should not matter)
  • [x] set permanent label (and remove other track)
• [x] add global track for what we are currently looking at (REST-backed)
  • [x] color by region and make pretty (subclass track)
  • [x] remove this one as redundant
• [x] remove ref-seq drop-down and leave remaining empty (using empty)
• [x] remove block-based labels (or make them explicit)

  Mockup

Older Notes

Add a border between contigs.
Route now . . the border between contigs is seamless (but still awesome).
We should give SOME indicator of where the different contigs are. GB50290-RA and GB55506-RA are on different contigs, but one would not know.

Possibilities: 1 - a line and arrow on opposite sides of the track, indicating what is there 2 - different shading on the bottom of the tracks with a label (so you always know where you're at) . . maybe via a combo track 3 - like 2 above, but as a separate track (maybe the best way to start)

I could just return an array or arrays (or an array of objects): 1 - [[min,max,label],[min,max,label] . . etc. etc. ]

[nathandunn]

• [ ] @nathandunn will add a startbp/endbp and oldstartbp/oldendbp to each object in the sequenceList array
• [ ] @enuggetry will add something (after being sketching something out)

[cmdcolin]

I was thinking that the highlight function could be extended to show something like this.

Highlights are the best way to draw a big vertical line through all the tracks and they don't necessarily hve to be yellow.

We did something like this for a lab project that I think could be relevant

[nathandunn]

I think that would be a good start.

Would there be any way to notate which is which?

More importantly . . how would the server relate this to the client? We could leave it in the sequence URL (does not show location) for now or have it be inserted into the refSeq.json.

If we could float that above (in) the UcA that might be good. . .

Nathan

On Nov 24, 2015, at 9:48 AM, Colin Diesh notifications@github.com wrote:

I was thinking that the highlight function could be extended to show something like this.

Highlights are the best way to draw a big vertical line through all the tracks and they don't necessarily hve to be yellow.

We did something like this for a lab project that I think could be relevant

— Reply to this email directly or view it on GitHub https://github.com/GMOD/Apollo/issues/673#issuecomment-159353888.

[nathandunn]

@cmdcolin As we talked about yesterday . . can you work on this with @enuggetry based on those other designs.

My preference:

[nathandunn]

If for some reason this won't work . . I have some mobkcups in the "doc" section. If additional information needs to come through the JSON let me know. Also if you look in the ApolloLabelProc client plugin you can see what sort of manipulations its doing (I just did a quick hack . . . I'm sure that there are better things to do.

[nathandunn]

I just wanted to reiterate the stuff on the dev list. Pieces to add:

1 - the ability to specify the line color and thickness 2 - making the label show up somewhere 3 - making sure that if the back-ground color is not specified that it should transparent (this background piece is already there).

On the server side we just need a hook that handles the JSON for that, which Colin is writing, that taps in my projection engine, which should be pretty quick to do. Should include:

• start, end, color (background color), border-width (something like that), border-color, refseq (this is the label).

Quick question for @cmdcolin :

How does JBrowse get configured to use the Apollo URL? Do we define that in the annot.json?

[cmdcolin]

Went ahead and tried to get that vertical text thing working.

Kind of tricky, but it is possible

[nathandunn]

Looks okay - making text vertical with CSS, etc. can be a bit of a time-suck (having tried it before). If it doesn't work that's fine - horizontal text will work, esp. if we have some way to style it and make it "permanent" somewhere.

More important is getting the background color to be transparent and have a border.

[cmdcolin]

I don't really know what you mean like a empty box? Or just a line?

[nathandunn]

I mean . . if the highlights have a transparent background and a thick line they will look like this:

https://github.com/GMOD/Apollo/issues/673#issuecomment-162037010

[cmdcolin]

Alrighty. Horizontal added. It should be pretty easy to use now and has more reliable positioning

Should be able to be styled pretty much as needed

[nathandunn]

Excellent.

If we are not at the border, does it still give an indication of where you are at?
e.g., if I am off to the left at 1K, do I know I am in ctgA and ctgB is off to the right?

[cmdcolin]

I think apollo proc plugin should take care of that. I imagined it just changes what the location bar says depending on what scaffold you are in

[nathandunn]

I thought about that . . something that looks like this where the numbers correspond to scaffolds:

It definitely would not hurt.

What I would like to see, however, is the Blue (cyan?) part of the mockup in the upper-left that implies permanency (fancy region label XY). It might have to permanently float to the left until you get to a border area, though. Conversely putting the label at the very top might be okay, but I like the blue label the most. Thoughts?

[cmdcolin]

Hmm....well, I'm not sure. I kind of feel like just doing the minimal thing is best. Our users aren't clueless, they just want the extra bonus functionality here

Anyways, I opened PR here https://github.com/GMOD/jbrowse/pull/668 if anyone wants to review

[nathandunn]

I think the consensus is that we want to get as close to the mockup as possible so user's don't have to work harder to use our interface. If we can't add the persistent label via a highlight then we need to add an extra track or somehow annotate the track interface.

I'm sure the pull request is fine, but I'll let @enuggetry take a look.

[nathandunn]

We also need a way to add coordinates to the label somehow:

[nathandunn]

It looked like you were having issues using per CSS to replicate Eric’s mockup above. I also think that straight SVG makes more sense then using the dojo library (as you inferred). D3 might make sense, but probably not for this.

The goal for this is to demonstrate that we can replicate what Eric has suggested using any method. We can definitely add data to what the client receives from the server. We can possibly move this into the client later, but its kind of moot if we don't have a way to draw it.

[nathandunn]

http://documentup.com/wout/svg.js#plugins

http://svgjs.com/

[nathandunn]

I added some SVG code into my branch. Its still garbage (zooming and alignment needs work) but gets the point across: https://github.com/GMOD/jbrowse/commit/13c6a5620cd18e208f68111122891fb422021bd6

I think you end up with a lot more flexibility. Clearly we also need to grab other projected values from the backend as well and hide the track numbers.

[nathandunn]

Added some demo code mockups with the goal of supporting the following mechanisms:

• we can tell where we are at at any point
• we can tell what projection operations have been applied
• we can tell quickly find the original projection values
• we can tell how far away we are from the next value
• we know relatively where we are globally (i.e., the original track coordinates are unchanged)

The solution to this is three-fold:

• use the block-based region as we have it now to indicate borders locally and globally
• add a track to highlight regions, so that it is ALWAYS in scope
• add a track to highlight original coordinates and indicate projection. If there is overlap, this track will stack automatically

My thought (initially) is to use the REST feature store API to add two tracks to add these two custom tracks and then integrte it in similar to AnnoTrack.js (into annot.json).

Original mockup, the first one is working, and the second one is @enuggetry

These are the suggested ones here:

This is from an older mockup, for reference:

[nathandunn]

Made text smaller and added small carats:

[nathandunn]

The folding parameters (padding only really) should be configurable / removable by clicking on the icon directly.

[nathandunn]

From discussion with @selewis Added some additional screenshots.

[nathandunn]

Note to self: I think that top part (between the two scales with the "settings" icon can be moved to the bookmark panel and settings can be configured and set over there. All of this can come in via REST as well as functions. Conversely, we can pre-load everything at the start. Not sure what will require more rewrite.

[nathandunn]

So, there are two approaches for displaying the internal tick-marks and getting the correct numbers. We want Left label (and number), Right label (and number) and internal grid lines. The left and right labels can come out of REST. The internal grid marks can either be (1) calculated on the fly using the current projection engine (with a subclassed SVGTrackBase) or (2) grabbed via REST or (3) we can over-ride fillBlock instead or (4) eliminate the cached region.

The requirements to support are reiterated from above: 1 - zoom in / zoom out without clutter 2 - region always in view 3 - labeled edges and coordinates 4 - grid coordinates are relevant to the current zoom level and relative coordinates

Tried doing this with a cache . . but you have to erase SVG components . . which is what showRange does. That could be combined with REST as a first-pass. However, you can delete the elements at a pass, as well.

[nathandunn]

I think that 3/4 are out as deletion is messy at best. Will try 1. I think we need to get back both the region, the start / end and the current region for each coordinate.

The goal being to get the grid (red lines in green text) to zoom in and out properly. However, we need to see if the blue text can be properly formatted for density.

[nathandunn]

Actually, I can just do a linear interpolation if I know the start and end and where the last fold is.

[nathandunn]

Fixed by bringing in projection code from the client.

[nathandunn]

[nathandunn]

After a number of problems usi ght estore, I thought that just listing the groups made more sense: