Skip to content
This repository has been archived by the owner on Jul 29, 2019. It is now read-only.

Handle ranges with small lengths but large text lengths #1

Closed
wants to merge 1 commit into from
Closed

Handle ranges with small lengths but large text lengths #1

wants to merge 1 commit into from

Conversation

Gillingham
Copy link
Contributor

Change range content to overflow nicely if the range width is smaller than the width of the text. This prevents range items with longer text lines from being completely hidden.

Also update the stacking collision check to handle this case so that the overflowed text is not hidden by another item.

If you want this against develop instead of master let me know and I'll resubmit.

than the width of the text. This prevents range items with longer text
lines from being completely hidden.
Also update the stacking collision check to handle this case so that the
overflowed text is not hidden by another item.
@josdejong
Copy link
Contributor

I'm not sure about this "nice overflow". The overflow: hidden was there on purpose. I would rather turn to other solutions than introducing overflowing text. I suppose you are dealing with many very short ranges with large gaps in between them? Maybe it makes sense to make the text visible on a mouse hover (either with some fancy tooltip or by adjusting css overflow and background on mouse hover).

@Gillingham
Copy link
Contributor Author

Yes, if anything it would have to be a tooltip since just making overflow visible on hover would semi-break layout unless you also update the stack algorithm as I did to take into account the overflow size when stacking.
Would you take this if maybe I updated this to be a configurable option? I would like to not have to maintain my own branch to use this if possible and figured some people may have the same request as they did with the chaps-link-library

@josdejong
Copy link
Contributor

Well, it would be nice to somehow improve the Timeline for this type of data, however I don't think the overflow solution is the way to go, so we should look further.

With the chap-links-library we have been adding just about every feature someone asked for. With vis.js we will try to be a little bit more strict, and only add features which have a broad, generic use. This to keep the library concise and focussed. At the same time, the library is built up in a modular way which makes it easier for die-hard hackers to tune and extend it to exactly meet their needs.

Maybe a pragmatic solution is acceptable as well: when dealing with events having short ranges on a large time scale, maybe you shouldn't display them as ranges but as points or boxes? Maybe even use two zoom levels: when zoomed out, display events as points, and when zoomed in enough, display events as ranges.

@Gillingham
Copy link
Contributor Author

I'm not sure my javascript is up to the task, but would some mashup of both range and box/point be ideal?
For example the text of the event is in a box/point bubble but the range is still displayed via maybe a start and end point down to the timeline, even better there would be an automatic change between this range type and normal range type if the text would fit within a normal range without overflowing/hiding.

@Gillingham
Copy link
Contributor Author

If it helps to visualize the kind of data I'm dealing with:
Timeline

I'm prototyping a timeline tool showing events from various file datasources for spacecraft on one page to assist in scheduling/general planning.

@josdejong
Copy link
Contributor

Thanks for the clear image. Your idea may indeed be the best solution: create a new item type (probably extending from range), which has the behavior as you implemented for this pull request.

The Timeline (and stacking algorithm) should be type agnostic so you can extend the Timeline with new types without having to hack into the Timeline itself.

@Gillingham
Copy link
Contributor Author

I'm wondering how to do this without breaking the rendering, as if I just extend range i need to modify the components width in order for it to properly stack, I'm just wondering if that wont also break the drawing of the range itself as the width is not set to the text width instead of the width of the div we should be drawing as the range.

Perhaps stack needs to be adjusted to call something else other than just item.width? Maybe a function that can be extended a bit more to return either the items real width or in this case it's text contents width?

I've only briefly looked at the code and haven't played with it yet, was just wondering if you had any idea of what else all relies on the components.width before I go changing how it's defined.

@josdejong
Copy link
Contributor

I haven't looked at it yet either, but I think you could adjust the Item.reflow function to calculate this.width and this.height based on an other DOM element (the text instead of the frame).

But besides that, I think the Items and Components need a clear API which can be used for example by the stacking algorithm. Right now properties like width, height, frame, parent, etc are just supposed to be there. Defining an API consisting of functions like getSize(), getFrame(), getParent() will help decoupling item properties from their implementation, and remove the need to know about the type of item when addressing this API.

@Gillingham
Copy link
Contributor Author

Fixed and resubmitted in #20

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants