Closed nathandunn closed 8 years ago
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
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.
@cmdcolin As we talked about yesterday . . can you work on this with @enuggetry based on those other designs.
My preference:
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.
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:
Quick question for @cmdcolin :
How does JBrowse get configured to use the Apollo URL? Do we define that in the annot.json?
Went ahead and tried to get that vertical text thing working.
Kind of tricky, but it is possible
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.
I don't really know what you mean like a empty box? Or just a line?
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
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
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?
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
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?
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
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.
We also need a way to add coordinates to the label somehow:
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.
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.
Added some demo code mockups with the goal of supporting the following mechanisms:
The solution to this is three-fold:
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:
Made text smaller and added small carats:
The folding parameters (padding only really) should be configurable / removable by clicking on the icon directly.
From discussion with @selewis Added some additional screenshots.
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.
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.
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.
Actually, I can just do a linear interpolation if I know the start and end and where the last fold is.
Fixed by bringing in projection code from the client.
After a number of problems usi ght estore, I thought that just listing the groups made more sense:
TODO
support padding #996fix initial scaling issue on load #996add general color-coded labelcan the "overview" be colored, but the direct version not be colored?Bookmark should go over annottrack as well (should not matter)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. ]