draggable (Yao) gene models

[nathandunn]

The goal behind this is to have gene models that look good:

• [x] make draggable (Yao) gene models from canvas tracks shown below into HTMLFeatures
• [x] add to evidence track
• [ ] make evidence draggable
• [ ] make annotation track also draggable
• [ ] show by adding / calculate stop codons as in images below from desktop apollo
• [ ] make sure we can configure color schemes

[nathandunn]

The issue with what @enuggetry did (which look great I might add), is that they are done in canvas, which is currently not draggable. Individual exons as well as introns must be draggable (as you grab them they move).

Solutions: 1 - make canvas draggable. To do this you have to assign objects to each exon / transcript location and create a special handler manager. From that you have to redraw the canvas as you drag (yuck).
2 - create an SVG track that does the same. Has added bonus that can use CSS, as well.

The major advantages of canvas are A) its already there and B) is optimized for a very large number of elements.

However, the more I think about this, the more I think that B) is not necessarily good. If you are looking at 10K individual elements on a screen you are already doing something wrong and you need to roll up your data somehow to increase the signal to noise ratio (a common theme in our conversations).

Additionally, I'm worried about the ability to ever make Canvas cleanly draggable in the same way as SVG. When you drag a div, you are simply dragging those div elements. When you drag a Canvas object, you are dragging the outer-most canvas block in a square. I don't believe you can animate out of that canvas, either, so you would have to convert that to something else.

Would be very curious to get thoughts from @enuggetry @cmdcolin and @selewis . Will be fun either way.

[enuggetry]

I've been looking at htmlfeatures code. I think it should be easy to add svg toy, theoretically. Next week, I'll give it a go, time permitting. On Jul 15, 2015 12:02 PM, "Nathan Dunn" notifications@github.com wrote:

The issue with what @enuggetry https://github.com/enuggetry did (which look great I might add), is that they are done in canvas, which is currently not draggable. Individual exons as well as introns must be draggable (as you grab them they move).

Solutions: 1 - make canvas draggable. To do this you have to assign objects to each exon / transcript location and create a special handler manager. From that you have to redraw the canvas as you drag (yuck).

2 - create an SVG track that does the same. Has added bonus that can use CSS, as well.

The major advantages of canvas are A) its already there and B) is optimized for a very large number of elements.

However, the more I think about this, the more I think that B) is not necessarily good. If you are looking at 10K individual elements on a screen you are already doing something wrong and you need to roll up your data somehow to increase the signal to noise ratio (a common theme in our conversations).

Additionally, I'm worried about the ability to ever make Canvas cleanly draggable in the same way as SVG. When you drag a div, you are simply dragging those div elements. When you drag a Canvas object, you are dragging the outer-most canvas block in a square. I don't believe you can animate out of that canvas, either, so you would have to convert that to something else.

Would be very curious to get thoughts from @enuggetry https://github.com/enuggetry @cmdcolin https://github.com/cmdcolin and @selewis https://github.com/selewis . Will be fun either way.

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

[selewis]

Thanks Eric, (regarding evaluation of doing these with SVG)

Eric & Nathan - have either of you taken a look at what it would take to do reverse complement?? Rob always repeated "need canvas for reverse complement". This doesn't make sense to me. (It's just rev-comp after all, just a lot of coord changes). If SVG is the decision would one of you look at doing this for rev-comp as well.

-S

On Wed, Jul 15, 2015 at 2:26 PM, enuggetry notifications@github.com wrote:

I've been looking at htmlfeatures code. I think it should be easy to add svg toy, theoretically. Next week, I'll give it a go, time permitting. On Jul 15, 2015 12:02 PM, "Nathan Dunn" notifications@github.com wrote:

The issue with what @enuggetry https://github.com/enuggetry did (which look great I might add), is that they are done in canvas, which is currently not draggable. Individual exons as well as introns must be draggable (as you grab them they move).

Solutions: 1 - make canvas draggable. To do this you have to assign objects to each exon / transcript location and create a special handler manager. From that you have to redraw the canvas as you drag (yuck).

2 - create an SVG track that does the same. Has added bonus that can use CSS, as well.

The major advantages of canvas are A) its already there and B) is optimized for a very large number of elements.

However, the more I think about this, the more I think that B) is not necessarily good. If you are looking at 10K individual elements on a screen you are already doing something wrong and you need to roll up your data somehow to increase the signal to noise ratio (a common theme in our conversations).

Additionally, I'm worried about the ability to ever make Canvas cleanly draggable in the same way as SVG. When you drag a div, you are simply dragging those div elements. When you drag a Canvas object, you are dragging the outer-most canvas block in a square. I don't believe you can animate out of that canvas, either, so you would have to convert that to something else.

Would be very curious to get thoughts from @enuggetry https://github.com/enuggetry @cmdcolin https://github.com/cmdcolin and @selewis https://github.com/selewis . Will be fun either way.

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

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

[nathandunn]

I well second thanking @enuggetry. Also don’t hesitate to pull me in for any of it.

@selewis The reverse compliment would just be for the UcA, right (at least for right now) . . or are we looking at the Desktop Apollo version?

Nathan

On Jul 15, 2015, at 2:41 PM, selewis notifications@github.com wrote:

Thanks Eric, (regarding evaluation of doing these with SVG)

Eric & Nathan - have either of you taken a look at what it would take to do reverse complement?? Rob always repeated "need canvas for reverse complement". This doesn't make sense to me. (It's just rev-comp after all, just a lot of coord changes). If SVG is the decision would one of you look at doing this for rev-comp as well.

-S

On Wed, Jul 15, 2015 at 2:26 PM, enuggetry notifications@github.com wrote:

I've been looking at htmlfeatures code. I think it should be easy to add svg toy, theoretically. Next week, I'll give it a go, time permitting. On Jul 15, 2015 12:02 PM, "Nathan Dunn" notifications@github.com wrote:

The issue with what @enuggetry https://github.com/enuggetry did (which look great I might add), is that they are done in canvas, which is currently not draggable. Individual exons as well as introns must be draggable (as you grab them they move).

Solutions: 1 - make canvas draggable. To do this you have to assign objects to each exon / transcript location and create a special handler manager. From that you have to redraw the canvas as you drag (yuck).

2 - create an SVG track that does the same. Has added bonus that can use CSS, as well.

The major advantages of canvas are A) its already there and B) is optimized for a very large number of elements.

However, the more I think about this, the more I think that B) is not necessarily good. If you are looking at 10K individual elements on a screen you are already doing something wrong and you need to roll up your data somehow to increase the signal to noise ratio (a common theme in our conversations).

Additionally, I'm worried about the ability to ever make Canvas cleanly draggable in the same way as SVG. When you drag a div, you are simply dragging those div elements. When you drag a Canvas object, you are dragging the outer-most canvas block in a square. I don't believe you can animate out of that canvas, either, so you would have to convert that to something else.

Would be very curious to get thoughts from @enuggetry https://github.com/enuggetry @cmdcolin https://github.com/cmdcolin and @selewis https://github.com/selewis . Will be fun either way.

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

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

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

[selewis]

When you rev-comp your entire perspective changes.

Everything (and I mean everything) is affect.

It is quite impossible to just do one track (including the writable region). They all have to be switched!

Nota bene: Please don't use UcA! I never have any idea what on earth you're talking about. Have to stop reading to translate, ugh. Generally no acronyms. If you want something short call it the edit-track.

-S

On Wed, Jul 15, 2015 at 2:45 PM, Nathan Dunn notifications@github.com wrote:

I well second thanking @enuggetry. Also don’t hesitate to pull me in for any of it.

@selewis The reverse compliment would just be for the UcA, right (at least for right now) . . or are we looking at the Desktop Apollo version?

Nathan

On Jul 15, 2015, at 2:41 PM, selewis notifications@github.com wrote:

Thanks Eric, (regarding evaluation of doing these with SVG)

Eric & Nathan - have either of you taken a look at what it would take to do reverse complement?? Rob always repeated "need canvas for reverse complement". This doesn't make sense to me. (It's just rev-comp after all, just a lot of coord changes). If SVG is the decision would one of you look at doing this for rev-comp as well.

-S

On Wed, Jul 15, 2015 at 2:26 PM, enuggetry notifications@github.com wrote:

I've been looking at htmlfeatures code. I think it should be easy to add svg toy, theoretically. Next week, I'll give it a go, time permitting. On Jul 15, 2015 12:02 PM, "Nathan Dunn" notifications@github.com wrote:

The issue with what @enuggetry https://github.com/enuggetry did (which look great I might add), is that they are done in canvas, which is currently not draggable. Individual exons as well as introns must be draggable (as you grab them they move).

Solutions: 1 - make canvas draggable. To do this you have to assign objects to each exon / transcript location and create a special handler manager. From that you have to redraw the canvas as you drag (yuck).

2 - create an SVG track that does the same. Has added bonus that can use CSS, as well.

The major advantages of canvas are A) its already there and B) is optimized for a very large number of elements.

However, the more I think about this, the more I think that B) is not necessarily good. If you are looking at 10K individual elements on a screen you are already doing something wrong and you need to roll up your data somehow to increase the signal to noise ratio (a common theme in our conversations).

Additionally, I'm worried about the ability to ever make Canvas cleanly draggable in the same way as SVG. When you drag a div, you are simply dragging those div elements. When you drag a Canvas object, you are dragging the outer-most canvas block in a square. I don't believe you can animate out of that canvas, either, so you would have to convert that to something else.

Would be very curious to get thoughts from @enuggetry https://github.com/enuggetry @cmdcolin < https://github.com/cmdcolin> and @selewis https://github.com/selewis . Will be fun either way.

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

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

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121758556>.

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

[nathandunn]

Okay thanks. That does make sense. We’ll keep that in mind while looking through. Its almost a separate, unrelated problem. I kind of think that the genometry stuff might help for this, as well.

I added a bug to sort of fork this.

Agreed on UcA, I have to do the same thing. I like calling it the annotation track.

Nathan

On Jul 15, 2015, at 2:53 PM, selewis notifications@github.com wrote:

When you rev-comp your entire perspective changes.

Everything (and I mean everything) is affect.

It is quite impossible to just do one track (including the writable region). They all have to be switched!

Nota bene: Please don't use UcA! I never have any idea what on earth you're talking about. Have to stop reading to translate, ugh. Generally no acronyms. If you want something short call it the edit-track.

-S

On Wed, Jul 15, 2015 at 2:45 PM, Nathan Dunn notifications@github.com wrote:

I well second thanking @enuggetry. Also don’t hesitate to pull me in for any of it.

@selewis The reverse compliment would just be for the UcA, right (at least for right now) . . or are we looking at the Desktop Apollo version?

Nathan

On Jul 15, 2015, at 2:41 PM, selewis notifications@github.com wrote:

Thanks Eric, (regarding evaluation of doing these with SVG)

Eric & Nathan - have either of you taken a look at what it would take to do reverse complement?? Rob always repeated "need canvas for reverse complement". This doesn't make sense to me. (It's just rev-comp after all, just a lot of coord changes). If SVG is the decision would one of you look at doing this for rev-comp as well.

-S

On Wed, Jul 15, 2015 at 2:26 PM, enuggetry notifications@github.com wrote:

I've been looking at htmlfeatures code. I think it should be easy to add svg toy, theoretically. Next week, I'll give it a go, time permitting. On Jul 15, 2015 12:02 PM, "Nathan Dunn" notifications@github.com wrote:

The issue with what @enuggetry https://github.com/enuggetry did (which look great I might add), is that they are done in canvas, which is currently not draggable. Individual exons as well as introns must be draggable (as you grab them they move).

Solutions: 1 - make canvas draggable. To do this you have to assign objects to each exon / transcript location and create a special handler manager. From that you have to redraw the canvas as you drag (yuck).

2 - create an SVG track that does the same. Has added bonus that can use CSS, as well.

The major advantages of canvas are A) its already there and B) is optimized for a very large number of elements.

However, the more I think about this, the more I think that B) is not necessarily good. If you are looking at 10K individual elements on a screen you are already doing something wrong and you need to roll up your data somehow to increase the signal to noise ratio (a common theme in our conversations).

Additionally, I'm worried about the ability to ever make Canvas cleanly draggable in the same way as SVG. When you drag a div, you are simply dragging those div elements. When you drag a Canvas object, you are dragging the outer-most canvas block in a square. I don't believe you can animate out of that canvas, either, so you would have to convert that to something else.

Would be very curious to get thoughts from @enuggetry https://github.com/enuggetry @cmdcolin < https://github.com/cmdcolin> and @selewis https://github.com/selewis . Will be fun either way.

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

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

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121758556>.

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

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

[selewis]

Yep, genometry will help. It's all about coordinate transforms.

On Wed, Jul 15, 2015 at 3:14 PM, Nathan Dunn notifications@github.com wrote:

Okay thanks. That does make sense. We’ll keep that in mind while looking through. Its almost a separate, unrelated problem. I kind of think that the genometry stuff might help for this, as well.

I added a bug to sort of fork this.

Agreed on UcA, I have to do the same thing. I like calling it the annotation track.

Nathan

On Jul 15, 2015, at 2:53 PM, selewis notifications@github.com wrote:

When you rev-comp your entire perspective changes.

Everything (and I mean everything) is affect.

It is quite impossible to just do one track (including the writable region). They all have to be switched!

Nota bene: Please don't use UcA! I never have any idea what on earth you're talking about. Have to stop reading to translate, ugh. Generally no acronyms. If you want something short call it the edit-track.

-S

On Wed, Jul 15, 2015 at 2:45 PM, Nathan Dunn notifications@github.com wrote:

I well second thanking @enuggetry. Also don’t hesitate to pull me in for any of it.

@selewis The reverse compliment would just be for the UcA, right (at least for right now) . . or are we looking at the Desktop Apollo version?

Nathan

On Jul 15, 2015, at 2:41 PM, selewis notifications@github.com wrote:

Thanks Eric, (regarding evaluation of doing these with SVG)

Eric & Nathan - have either of you taken a look at what it would take to do reverse complement?? Rob always repeated "need canvas for reverse complement". This doesn't make sense to me. (It's just rev-comp after all, just a lot of coord changes). If SVG is the decision would one of you look at doing this for rev-comp as well.

-S

On Wed, Jul 15, 2015 at 2:26 PM, enuggetry <notifications@github.com

wrote:

I've been looking at htmlfeatures code. I think it should be easy to add svg toy, theoretically. Next week, I'll give it a go, time permitting. On Jul 15, 2015 12:02 PM, "Nathan Dunn" notifications@github.com wrote:

The issue with what @enuggetry https://github.com/enuggetry did (which look great I might add), is that they are done in canvas, which is currently not draggable. Individual exons as well as introns must be draggable (as you grab them they move).

Solutions: 1 - make canvas draggable. To do this you have to assign objects to each exon / transcript location and create a special handler manager. From that you have to redraw the canvas as you drag (yuck).

2 - create an SVG track that does the same. Has added bonus that can use CSS, as well.

The major advantages of canvas are A) its already there and B) is optimized for a very large number of elements.

However, the more I think about this, the more I think that B) is not necessarily good. If you are looking at 10K individual elements on a screen you are already doing something wrong and you need to roll up your data somehow to increase the signal to noise ratio (a common theme in our conversations).

Additionally, I'm worried about the ability to ever make Canvas cleanly draggable in the same way as SVG. When you drag a div, you are simply dragging those div elements. When you drag a Canvas object, you are dragging the outer-most canvas block in a square. I don't believe you can animate out of that canvas, either, so you would have to convert that to something else.

Would be very curious to get thoughts from @enuggetry https://github.com/enuggetry @cmdcolin < https://github.com/cmdcolin> and @selewis https://github.com/selewis . Will be fun either way.

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121714090>.

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

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121758556>.

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

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121761017>.

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

[enuggetry]

Rbuels is probably referring to the fact that canvas allows for complete reverse transform of the coordinate system for canvas elements Here's an example: http://www.html5canvastutorials.com/advanced/html5-canvas-mirror-transform-tutorial/ There's some light here, but I think there's a LOT of other things to consider.

Re: dragging into Apollo Just some thoughts: What if, when you drag canvas tracks into apollo, you convert into an HTMLFeatures track? I think there's a good chance I can make HTMLFeatures look almost exactly like "my new" canvas features; if not, near.

Alternatively, I could pass you box coordinates for the canvas features. So, you could create transparent divs to latch on to while in Apollo. (Here's where I don't really know how Apollo operates, so I don't know if this is feasible at all.) You can also build the box coordinates from the same data that I use to build the intron hats. I think every thing operates in position=absolute.

I would say the former makes more sense, since you already support HTML features.

On Wed, Jul 15, 2015 at 3:14 PM, Nathan Dunn notifications@github.com wrote:

Okay thanks. That does make sense. We’ll keep that in mind while looking through. Its almost a separate, unrelated problem. I kind of think that the genometry stuff might help for this, as well.

I added a bug to sort of fork this.

Agreed on UcA, I have to do the same thing. I like calling it the annotation track.

Nathan

On Jul 15, 2015, at 2:53 PM, selewis notifications@github.com wrote:

When you rev-comp your entire perspective changes.

Everything (and I mean everything) is affect.

It is quite impossible to just do one track (including the writable region). They all have to be switched!

Nota bene: Please don't use UcA! I never have any idea what on earth you're talking about. Have to stop reading to translate, ugh. Generally no acronyms. If you want something short call it the edit-track.

-S

On Wed, Jul 15, 2015 at 2:45 PM, Nathan Dunn notifications@github.com wrote:

I well second thanking @enuggetry. Also don’t hesitate to pull me in for any of it.

@selewis The reverse compliment would just be for the UcA, right (at least for right now) . . or are we looking at the Desktop Apollo version?

Nathan

On Jul 15, 2015, at 2:41 PM, selewis notifications@github.com wrote:

Thanks Eric, (regarding evaluation of doing these with SVG)

Eric & Nathan - have either of you taken a look at what it would take to do reverse complement?? Rob always repeated "need canvas for reverse complement". This doesn't make sense to me. (It's just rev-comp after all, just a lot of coord changes). If SVG is the decision would one of you look at doing this for rev-comp as well.

-S

On Wed, Jul 15, 2015 at 2:26 PM, enuggetry <notifications@github.com

wrote:

I've been looking at htmlfeatures code. I think it should be easy to add svg toy, theoretically. Next week, I'll give it a go, time permitting. On Jul 15, 2015 12:02 PM, "Nathan Dunn" notifications@github.com wrote:

The issue with what @enuggetry https://github.com/enuggetry did (which look great I might add), is that they are done in canvas, which is currently not draggable. Individual exons as well as introns must be draggable (as you grab them they move).

Solutions: 1 - make canvas draggable. To do this you have to assign objects to each exon / transcript location and create a special handler manager. From that you have to redraw the canvas as you drag (yuck).

2 - create an SVG track that does the same. Has added bonus that can use CSS, as well.

The major advantages of canvas are A) its already there and B) is optimized for a very large number of elements.

However, the more I think about this, the more I think that B) is not necessarily good. If you are looking at 10K individual elements on a screen you are already doing something wrong and you need to roll up your data somehow to increase the signal to noise ratio (a common theme in our conversations).

Additionally, I'm worried about the ability to ever make Canvas cleanly draggable in the same way as SVG. When you drag a div, you are simply dragging those div elements. When you drag a Canvas object, you are dragging the outer-most canvas block in a square. I don't believe you can animate out of that canvas, either, so you would have to convert that to something else.

Would be very curious to get thoughts from @enuggetry https://github.com/enuggetry @cmdcolin < https://github.com/cmdcolin> and @selewis https://github.com/selewis . Will be fun either way.

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121714090>.

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

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121758556>.

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

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121761017>.

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

[selewis]

Sounds like HTML features are the way to go.

Especially since the canvas "build-in reverse transform of the coordinate system for canvas elements" doesn't solve all our problems/challenges. We have to have a generalized solution here. Even if just considering one strand we want to a) show the same feature on genomic, transcript, and protein coordinates b) accordion the genome (folding) for multiple contigs or eliding introns, c) ... d) and so forth.

-S

On Wed, Jul 15, 2015 at 3:50 PM, enuggetry notifications@github.com wrote:

Rbuels is probably referring to the fact that canvas allows for complete reverse transform of the coordinate system for canvas elements Here's an example:

http://www.html5canvastutorials.com/advanced/html5-canvas-mirror-transform-tutorial/ There's some light here, but I think there's a LOT of other things to consider.

Re: dragging into Apollo Just some thoughts: What if, when you drag canvas tracks into apollo, you convert into an HTMLFeatures track? I think there's a good chance I can make HTMLFeatures look almost exactly like "my new" canvas features; if not, near.

Alternatively, I could pass you box coordinates for the canvas features. So, you could create transparent divs to latch on to while in Apollo. (Here's where I don't really know how Apollo operates, so I don't know if this is feasible at all.) You can also build the box coordinates from the same data that I use to build the intron hats. I think every thing operates in position=absolute.

I would say the former makes more sense, since you already support HTML features.

On Wed, Jul 15, 2015 at 3:14 PM, Nathan Dunn notifications@github.com wrote:

Okay thanks. That does make sense. We’ll keep that in mind while looking through. Its almost a separate, unrelated problem. I kind of think that the genometry stuff might help for this, as well.

I added a bug to sort of fork this.

Agreed on UcA, I have to do the same thing. I like calling it the annotation track.

Nathan

On Jul 15, 2015, at 2:53 PM, selewis notifications@github.com wrote:

When you rev-comp your entire perspective changes.

Everything (and I mean everything) is affect.

It is quite impossible to just do one track (including the writable region). They all have to be switched!

Nota bene: Please don't use UcA! I never have any idea what on earth you're talking about. Have to stop reading to translate, ugh. Generally no acronyms. If you want something short call it the edit-track.

-S

On Wed, Jul 15, 2015 at 2:45 PM, Nathan Dunn <notifications@github.com

wrote:

I well second thanking @enuggetry. Also don’t hesitate to pull me in for any of it.

@selewis The reverse compliment would just be for the UcA, right (at least for right now) . . or are we looking at the Desktop Apollo version?

Nathan

On Jul 15, 2015, at 2:41 PM, selewis notifications@github.com wrote:

Thanks Eric, (regarding evaluation of doing these with SVG)

Eric & Nathan - have either of you taken a look at what it would take to do reverse complement?? Rob always repeated "need canvas for reverse complement". This doesn't make sense to me. (It's just rev-comp after all, just a lot of coord changes). If SVG is the decision would one of you look at doing this for rev-comp as well.

-S

On Wed, Jul 15, 2015 at 2:26 PM, enuggetry < notifications@github.com

wrote:

I've been looking at htmlfeatures code. I think it should be easy to add svg toy, theoretically. Next week, I'll give it a go, time permitting. On Jul 15, 2015 12:02 PM, "Nathan Dunn" < notifications@github.com> wrote:

The issue with what @enuggetry https://github.com/enuggetry did (which look great I might add), is that they are done in canvas, which is currently not draggable. Individual exons as well as introns must be draggable (as you grab them they move).

Solutions: 1 - make canvas draggable. To do this you have to assign objects to each exon / transcript location and create a special handler manager. From that you have to redraw the canvas as you drag (yuck).

2 - create an SVG track that does the same. Has added bonus that can use CSS, as well.

The major advantages of canvas are A) its already there and B) is optimized for a very large number of elements.

However, the more I think about this, the more I think that B) is not necessarily good. If you are looking at 10K individual elements on a screen you are already doing something wrong and you need to roll up your data somehow to increase the signal to noise ratio (a common theme in our conversations).

Additionally, I'm worried about the ability to ever make Canvas cleanly draggable in the same way as SVG. When you drag a div, you are simply dragging those div elements. When you drag a Canvas object, you are dragging the outer-most canvas block in a square. I don't believe you can animate out of that canvas, either, so you would have to convert that to something else.

Would be very curious to get thoughts from @enuggetry https://github.com/enuggetry @cmdcolin < https://github.com/cmdcolin> and @selewis https://github.com/selewis . Will be fun either way.

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121714090>.

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

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121758556>.

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

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121761017>.

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

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

[nathandunn]

Agreed. On the call today (notes coming) it sounded like we could embed SVG into the HTMLFeature track if needed. Excited to see what is coming down the pipe.

Feel free to change the name (though I personally like the name Yao genes).

Nathan

On Jul 15, 2015, at 4:21 PM, selewis notifications@github.com wrote:

Sounds like HTML features are the way to go.

Especially since the canvas "build-in reverse transform of the coordinate system for canvas elements" doesn't solve all our problems/challenges. We have to have a generalized solution here. Even if just considering one strand we want to a) show the same feature on genomic, transcript, and protein coordinates b) accordion the genome (folding) for multiple contigs or eliding introns, c) ... d) and so forth.

-S

On Wed, Jul 15, 2015 at 3:50 PM, enuggetry notifications@github.com wrote:

Rbuels is probably referring to the fact that canvas allows for complete reverse transform of the coordinate system for canvas elements Here's an example:

http://www.html5canvastutorials.com/advanced/html5-canvas-mirror-transform-tutorial/ There's some light here, but I think there's a LOT of other things to consider.

Re: dragging into Apollo Just some thoughts: What if, when you drag canvas tracks into apollo, you convert into an HTMLFeatures track? I think there's a good chance I can make HTMLFeatures look almost exactly like "my new" canvas features; if not, near.

Alternatively, I could pass you box coordinates for the canvas features. So, you could create transparent divs to latch on to while in Apollo. (Here's where I don't really know how Apollo operates, so I don't know if this is feasible at all.) You can also build the box coordinates from the same data that I use to build the intron hats. I think every thing operates in position=absolute.

I would say the former makes more sense, since you already support HTML features.

On Wed, Jul 15, 2015 at 3:14 PM, Nathan Dunn notifications@github.com wrote:

Okay thanks. That does make sense. We’ll keep that in mind while looking through. Its almost a separate, unrelated problem. I kind of think that the genometry stuff might help for this, as well.

I added a bug to sort of fork this.

Agreed on UcA, I have to do the same thing. I like calling it the annotation track.

Nathan

On Jul 15, 2015, at 2:53 PM, selewis notifications@github.com wrote:

When you rev-comp your entire perspective changes.

Everything (and I mean everything) is affect.

It is quite impossible to just do one track (including the writable region). They all have to be switched!

Nota bene: Please don't use UcA! I never have any idea what on earth you're talking about. Have to stop reading to translate, ugh. Generally no acronyms. If you want something short call it the edit-track.

-S

On Wed, Jul 15, 2015 at 2:45 PM, Nathan Dunn <notifications@github.com

wrote:

I well second thanking @enuggetry. Also don’t hesitate to pull me in for any of it.

@selewis The reverse compliment would just be for the UcA, right (at least for right now) . . or are we looking at the Desktop Apollo version?

Nathan

On Jul 15, 2015, at 2:41 PM, selewis notifications@github.com wrote:

Thanks Eric, (regarding evaluation of doing these with SVG)

Eric & Nathan - have either of you taken a look at what it would take to do reverse complement?? Rob always repeated "need canvas for reverse complement". This doesn't make sense to me. (It's just rev-comp after all, just a lot of coord changes). If SVG is the decision would one of you look at doing this for rev-comp as well.

-S

On Wed, Jul 15, 2015 at 2:26 PM, enuggetry < notifications@github.com

wrote:

I've been looking at htmlfeatures code. I think it should be easy to add svg toy, theoretically. Next week, I'll give it a go, time permitting. On Jul 15, 2015 12:02 PM, "Nathan Dunn" < notifications@github.com> wrote:

The issue with what @enuggetry https://github.com/enuggetry did (which look great I might add), is that they are done in canvas, which is currently not draggable. Individual exons as well as introns must be draggable (as you grab them they move).

Solutions: 1 - make canvas draggable. To do this you have to assign objects to each exon / transcript location and create a special handler manager. From that you have to redraw the canvas as you drag (yuck).

2 - create an SVG track that does the same. Has added bonus that can use CSS, as well.

The major advantages of canvas are A) its already there and B) is optimized for a very large number of elements.

However, the more I think about this, the more I think that B) is not necessarily good. If you are looking at 10K individual elements on a screen you are already doing something wrong and you need to roll up your data somehow to increase the signal to noise ratio (a common theme in our conversations).

Additionally, I'm worried about the ability to ever make Canvas cleanly draggable in the same way as SVG. When you drag a div, you are simply dragging those div elements. When you drag a Canvas object, you are dragging the outer-most canvas block in a square. I don't believe you can animate out of that canvas, either, so you would have to convert that to something else.

Would be very curious to get thoughts from @enuggetry https://github.com/enuggetry @cmdcolin < https://github.com/cmdcolin> and @selewis https://github.com/selewis . Will be fun either way.

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121714090>.

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

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121758556>.

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

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-121761017>.

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

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

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

[childers]

Can I add a request for a colorblind-friendly alternative for the red/green tags? I liked the visual cues, maybe it could be a toggle between color schemes.

[nathandunn]

@childers I updated the todo-list to reflect this. They should absolutely be configurable. I think that will be the easier part.

[childers]

( = Thank you! Accessibility is a good thing.

[nathandunn]

@enuggetry I guess I can assign this to you while you're looking into it. I can take a look at the stop codons and/or other minutiae whenever you feel like you want to hand it off. Whatever works for you. Thanks.

[enuggetry]

Should be fun. Yao genes: IDK

On Thu, Jul 16, 2015 at 2:00 PM, Nathan Dunn notifications@github.com wrote:

@enuggetry https://github.com/enuggetry I guess I can assign this to you while you're looking into it. I can take a look at the stop codons and/or other minutiae whenever you feel like you want to hand it off. Whatever works for you. Thanks.

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

[enuggetry]

Sorry, this took a bit longer than expected. It was a bit trickier than expected due to various technical reasons. In this implementation I create an SVG object for each intron that is interpolated. To test, rename HTMLFeaturesEx.js to HTMLFeatures.js (will create a better plugin solution later).,

https://github.com/GMOD/jbrowse/blob/master/src/JBrowse/View/Track/HTMLFeaturesEx.js

Haven't worked out all the kinks yet. Let's see how far it goes with Apollo, first.

I haven't gotten to improving the subfeatures look yet.

Demo here: http://jbrowse.org/code/sandbox-113/?data=sample_data%2Fjson%2Fvolvox&loc=ctgA%3A513..25104&tracks=DNA%2CReadingFrame%2CEST&highlight=

[nathandunn]

@cmdcolin Got it it in the EvidenceTrack as an HTMLFeature, but not yet draggable. Just copying it straight over didn't seem to do anything:

[cmdcolin]

The WebApollo code transforms HTMLFeatures tracks to DraggableHTMLFeatures using TrackConfigTransformer, so it is just probably not transforming the HTMLFeaturesEx

[nathandunn]

Yeah, something else is going on. If I replace HTMLFeatures entirely with HTMLFeaturesEx same thing. I saw the trackConfigTransfer as well. Not sure if its not transforming or just clashing.

Anyway, when you have time.

Nathan

On Jul 27, 2015, at 2:26 PM, Colin Diesh notifications@github.com wrote:

The WebApollo code transforms HTMLFeatures tracks to DraggableHTMLFeatures using TrackConfigTransformer, so it is just probably not transforming the HTMLFeaturesEx

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

[enuggetry]

Maybe somehow interfering with the event trap.

On Mon, Jul 27, 2015 at 3:03 PM, Nathan Dunn notifications@github.com wrote:

Yeah, something else is going on. If I replace HTMLFeatures entirely with HTMLFeaturesEx same thing. I saw the trackConfigTransfer as well. Not sure if its not transforming or just clashing.

Anyway, when you have time.

Nathan

On Jul 27, 2015, at 2:26 PM, Colin Diesh notifications@github.com wrote:

The WebApollo code transforms HTMLFeatures tracks to DraggableHTMLFeatures using TrackConfigTransformer, so it is just probably not transforming the HTMLFeaturesEx

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-125347379>.

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

[nathandunn]

Maybe. But its still drawing the older HTMLFeatures. Not sure if its cached somewhere or there is some namespace issue. Anyway, I’m sure its tractable. I’ll try to finish optimizations today and look at that.

Nathan

On Jul 27, 2015, at 4:00 PM, enuggetry notifications@github.com wrote:

Maybe somehow interfering with the event trap.

On Mon, Jul 27, 2015 at 3:03 PM, Nathan Dunn notifications@github.com wrote:

Yeah, something else is going on. If I replace HTMLFeatures entirely with HTMLFeaturesEx same thing. I saw the trackConfigTransfer as well. Not sure if its not transforming or just clashing.

Anyway, when you have time.

Nathan

On Jul 27, 2015, at 2:26 PM, Colin Diesh notifications@github.com wrote:

The WebApollo code transforms HTMLFeatures tracks to DraggableHTMLFeatures using TrackConfigTransformer, so it is just probably not transforming the HTMLFeaturesEx

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-125347379>.

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

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

[enuggetry]

I've created a jbrowse plugin (and checked in) called NeatFeatures. It specifically deals with the new feature structures in Apollo. Give it a shot.

IMPORTANT: get my latest HTMLFeatures.js update (necessary bug fix to allow NeatFeatures to work)

[nathandunn]

@enuggetry This looks great. I'm not seeing this plugin in the master branch, though. Where should I be looking / how should I use it?

[enuggetry]

Hey it's in the eric work branch. Still needs a little ironing. Please do test drive. On Sep 5, 2015 7:55 AM, "Nathan Dunn" notifications@github.com wrote:

@enuggetry https://github.com/enuggetry This looks great. I'm not seeing this plugin in the master branch, though. Where should I be looking / how should I use it?

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

[nathandunn]

When its ready can you issue a pull request and I can mess with it then (also helps me review changes)?

Thanks,

Nathan

On Sep 5, 2015, at 8:23 AM, enuggetry notifications@github.com wrote:

Hey it's in the eric work branch. Still needs a little ironing. Please do test drive. On Sep 5, 2015 7:55 AM, "Nathan Dunn" notifications@github.com wrote:

@enuggetry https://github.com/enuggetry This looks great. I'm not seeing this plugin in the master branch, though. Where should I be looking / how should I use it?

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

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

[nathandunn]

In retrospect that might be a bad idea (the pull request). I'll take a look when I have a moment.

[enuggetry]

I may not be qualified to fully test under Apollo, is the only thing.

[nathandunn]

How are you configuring in in trackList.json?

Nathan

On Sep 8, 2015, at 2:35 AM, enuggetry notifications@github.com wrote:

I may not be qualified to fully test under Apollo, is the only thing.

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

[enuggetry]

I put a read me file in the plugin directory. There are Apollo instructions. On Sep 8, 2015 7:55 AM, "Nathan Dunn" notifications@github.com wrote:

How are you configuring in in trackList.json?

Nathan

On Sep 8, 2015, at 2:35 AM, enuggetry notifications@github.com wrote:

I may not be qualified to fully test under Apollo, is the only thing.

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-138496031>.

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

[nathandunn]

So this kicks ass. Drags up and everything. We should show this off on Thursday.

This will DEFINITELY work.

Only request is that we choose something darker than that yellow.

Question, should I use your branch while I’m doing genome folding development or just stick to master?

Nathan

On Sep 8, 2015, at 12:08 PM, enuggetry notifications@github.com wrote:

I put a read me file in the plugin directory. There are Apollo instructions. On Sep 8, 2015 7:55 AM, "Nathan Dunn" notifications@github.com wrote:

How are you configuring in in trackList.json?

Nathan

On Sep 8, 2015, at 2:35 AM, enuggetry notifications@github.com wrote:

I may not be qualified to fully test under Apollo, is the only thing.

— Reply to this email directly or view it on GitHub < https://github.com/GMOD/Apollo/issues/481#issuecomment-138496031>.

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

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

[enuggetry]

Great. Re: the yellow. Because of the method I use now, I'm able to inherit the color that is defined in config script. However, let me think about how I can better handle lighter colors like yellow.

My own general preference is to keep things in a branch until it's relatively solid, particularly if it's main-line code.

[nathandunn]

Sounds good. I’m also working off of a branch.

Nathan

On Sep 8, 2015, at 4:31 PM, enuggetry notifications@github.com wrote:

Great. Re: the yellow. Because of the method I use now, I'm able to inherit the color that is defined in config script. However, let me think about how I can better handle lighter colors like yellow.

My own general preference is to keep things in a branch until it's relatively solid, particularly if it's main-line code.

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

[nathandunn]

I think that this is working pretty well right now. Can re-open or open another bug if it comes back.