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

Configurable Y offset for features relative to track label #901

Closed
dmgood11 opened this Issue Jun 19, 2017 · 12 comments

Comments

Projects
None yet
5 participants
@dmgood11

dmgood11 commented Jun 19, 2017

We like having track labels displayed, but could an option exist to offset the label from the features in the track? We often have very deep tracks so the additional depth from having the label Y-offset from the topmost feature is a very small price to pay compared to not being able to read a feature label or click on a feature without scrolling over horizontally to clear the track label.

@cmdcolin

This comment has been minimized.

Contributor

cmdcolin commented Jun 22, 2017

Possible dupe #490

Hiding track labels is one way this has been "solved" with HideTrackLabels but I agree it would be better to just have at least the option to move the features out of the way (kind of what I wanted to say on that issue with "reconfiguring the UI")

@dmgood11

This comment has been minimized.

dmgood11 commented Jun 22, 2017

Yes, it's a dupe (my search for similars wasn't extensive enough to find #490). But I haven't come across any of our end users who consider it "solved" by clicking the HideTrackLabels button. IMO it's a significant UX issue.

@cmdcolin

This comment has been minimized.

Contributor

cmdcolin commented Jun 22, 2017

I guess just conceptually, it could either be solved where every track is given an offset, or each track type could implement an offset, or maybe both. I am not sure which would be easier.

The calculation of track heights is pretty fundamental to how the genome browser works also so it might have to dig into some internals

@scottcain

This comment has been minimized.

Member

scottcain commented Oct 12, 2017

This is related to an issue raised at WormBase: WormBase/website#5900
A plugin to allow the tracklabel to be "raised up" relative to the track so that it can't obscure features in the track would be great.

enuggetry added a commit that referenced this issue Oct 14, 2017

Add config feature to move track labels/menus above the features so a…
…s not to obscure the features. Adds a little more spacing between tracks and between the first track and the genome view. Activated with trackLabels: "no-block" in trackList.json.

Addresses issues #901 #490
@enuggetry

This comment has been minimized.

Contributor

enuggetry commented Oct 14, 2017

Add config feature to move track labels/menus above the features so as not to obscure the features. Adds a little more spacing between tracks and between the first track and the genome view. Activated with trackLabels: "no-block" in trackList.json.

trackList.json
{
   tracks: [
      ...
   ],
   ...
   "dataset_id" : "volvox",
   "trackLabels":"no-block",
   "formatVersion" : 1
}
@rbuels

This comment has been minimized.

Collaborator

rbuels commented Jan 28, 2018

Sorry about the delay.

Have you tried setting a larger trackPadding @dmgood11? Something like trackPadding: 70 in the configuration?

@rbuels rbuels added the needs review label Jan 28, 2018

rbuels added a commit that referenced this issue Jan 28, 2018

Merge pull request #936 from GMOD/fix_tracklabel_spacing
Make the trackPadding attribute use config for issue #901

@rbuels rbuels modified the milestones: 1.12.4, 1.12.5 Jan 30, 2018

@cmdcolin

This comment has been minimized.

Contributor

cmdcolin commented Feb 15, 2018

I think the new "no-block" option could be applicable here. The trackLabels: no-block is a nice feature, and should be made easy for users to find. Here is how it looks with it on

screenshot-localhost-2018 02 15-12-05-43

With view.trackPadding=70 it doesn't move the track label out of the way

screenshot-github com-2018 02 15-12-07-29

Note that the "no-block" feature is sort of awkward to enable. Why not just be a true/false instead of set to specific string? Secondly, no-block works with trackPadding and sets it manually to 35. Kind of hardcoded

@rbuels

This comment has been minimized.

Collaborator

rbuels commented Feb 20, 2018

@cmdcolin @dmgood11 So would you guys say this issue is satisfactorily solved by the no-block configuration value available in the new JBrowse 1.12.4?

@cmdcolin

This comment has been minimized.

Contributor

cmdcolin commented Feb 20, 2018

I think it works pretty well but my wishlist for the feature would be

a) didn't have hardcoding for tracklabel pixel height in no-block
b) that no-block didn't move the tracklabel upwards but rather moved track content downwards
c) enable it by default or have a checklist in UI to enable it (biggest concern, since it seems like such a common request from users, and users might want it even if admins don't realize)
d) make the config value a boolean instead of string

sort of lengthy and bikesheddy but could close in interest of triaging issues

@rbuels

This comment has been minimized.

Collaborator

rbuels commented Feb 20, 2018

Well, the global track label toggle is the primary thing that was meant to address c), don't you think that's enough for now?

The rest of the stuff is the kind of thing to worry about in the 2.x series.

@cmdcolin

This comment has been minimized.

Contributor

cmdcolin commented Feb 20, 2018

Should be sufficient then :) it is a good workaround

@rbuels rbuels closed this Feb 21, 2018

@dmgood11

This comment has been minimized.

dmgood11 commented Feb 21, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment