Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issues to implement at WormBase #2918

Closed
scottcain opened this issue Apr 15, 2022 · 2 comments
Closed

Issues to implement at WormBase #2918

scottcain opened this issue Apr 15, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@scottcain
Copy link
Member

In order to implement JBrowse 2 at WormBase, I need a few items implemented:

Need to have:

  1. A lib that provides programmatic access to the functions that make jb2export work. This is needed to create a web service that can return an SVG for inlining in feature pages.
  2. Ability to resize track height in response to the “internal” height of the track. (Essentially Auto-adjust track heights to their current layout height #534) I would like to have this for both:
  • LGV so that the embedded view could optionally automatically scale in height.
  • For the lib that would be used for a svg web service.

Nice to have:

  1. “Universal” NClist support (LGV and lib that would be used for a web service); probably useful for other sites looking to migration from 1 to 2.
  2. Track content filtering (Allow custom filtering expressions to be applied to state or configuration of tracks #1988); would allow more general GFF use rather than requiring a GFF per track (example: at WormBase, we have multiple “Gene” tracks (all, coding, noncoding, pseudo, and historical) and it would nice to just use one GFF all of these tracks).
  3. A final thing that I just thought about and don’t know much about is plugin support for LGV and the web service lib: I’d like to be able to use the simple jexl plugin that generates score-based color gradients.

For (2), I don't know that it has to be a complete, system wide option. I imagine that, somewhere in the code, it is known what the height of the internal track is (during layout of features, you can keep the largest value, right?). Couldn't this be passed back up the chain to somewhere that it could be exposed via a method call? Then one could issue the command to draw the layout again, but this time with the height that was determined before. It might be nice if the previous layout were cached, but that can be a problem for later.

@scottcain scottcain added the enhancement New feature or request label Apr 15, 2022
@cmdcolin
Copy link
Collaborator

probably the (2) we will make a specialized flag for the exporter that makes it adjust the height of the tracks to the layout height

@cmdcolin
Copy link
Collaborator

I think these features all refer to other issue threads, if interested can tag them

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants