-
Notifications
You must be signed in to change notification settings - Fork 1.5k
Handle ranges with small lengths but large text lengths #1
Conversation
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.
I'm not sure about this "nice overflow". The |
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. |
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. |
I'm not sure my javascript is up to the task, but would some mashup of both range and box/point be ideal? |
Thanks for the clear image. Your idea may indeed be the best solution: create a new item type (probably extending from 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. |
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. |
I haven't looked at it yet either, but I think you could adjust the 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. |
Fixed and resubmitted in #20 |
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.