Feature: time blocks can start and end at some number of minutes/seconds past the hour

[dgallagh-litle]

Our team uses jQuery.Gantt to plot timelines that represent work being done on a system. Some are very short, some long, and sometimes multiple of them start and finish within an hour, so, we wanted the visualization to be more exact than nearest-hour.

This update adds a chart option called showFractionalHours. When set to true, and when the scale value is "hours", bars will start and end at some pixel distance from the hour mark, proportional to the minutes/seconds/milliseconds past. This involved a slight change in the CSS classing applied to header elements. There is a test page for the feature.

[rgriffogoes]

Nice! I was starting to study the code to make that change! Thanks!

[usmonster]

Thanks, @dgallagh-litle ! This little enhancement has been on the list for a bit (see related bug #47 and feature request #108). I'll try to take a look at the PR this weekend. It may actually be nice to just have this as default behavior instead of an option--@taitems, what do you think? Should we just proportionally scale the width of chart items for all timescales?

[dmromanov]

@dgallagh-litle Don't forget to update docs: index.html

[smiller393]

Hey, Was this ever merged in? If not, then this is something that I need for a new project I'm starting up.

[usmonster]

Looks like this was never merged, but a new PR would be welcome. I'd say this should be implemented by default and not as an option. If there is minute/second information in given start/end times, then that should probably be reflected in how the chart is displayed.

[smiller393]

Currently working on reworking (say that 10x fast...), and resubmitting this.

@dgallagh-litle , If you're still active, do you have any comments on the state of your commits? Were they fully working in your tests? Thanks.

[smiller393]

@usmonster What is the best way to ask minor questions about the code? Is there someone to message? I'm going through leaving comments as I learn sections of the code, and want to make sure they are accurate. Thanks!

[dgallagh-litle]

@smiller393, @usmonster Apologies - I haven't actually signed in to github in a long time now, and I guess some of these messages either ended up in junk or got lost among inbox clutter. I am not a frequent contributor here, and I sort of figured I was done when I set up the PR, since the code and tests worked at the time. I'd be happy to try and explain the changes if that's still useful - you might try reaching me directly at dgallagher at litle dot com for specifics.

As I recall, I found that the bar positioning worked by finding the nearest date for which there was a gridline and rounding off to it, and using that time in milliseconds as the html id of the element against which you'd position your bar. It worked well and I didn't want to mess with it. However - if you subtracted the rounded-off date value from the unrounded date value, you could set up a proportion with the size of the cell (in pixels) and the time span represented by those pixels, which gives the additional pixel displacement needed to show precise start and end times.

[smiller393]

@dgallagh-litle Thanks for the comment! I sent you an email after seeing that.
@usmonster How should I go about merging in my changes? Any particular testing process that's recommended? And do I just create a new pull request?

[usmonster]

@dgallagh-litle Thanks for the insights, and sorry your original PR never made it in. There were a lot of commits to the plugin around that time, and a clean merge quickly became impossible.

@smiller393 I would strongly recommend forking and working off of the develop branch, though be warned, it is a moving target. To avoid potential headaches, in addition to following the guidelines in the CONTRIBUTORS.md file, please also make sure not to change more than is minimally necessary to implement the feature.

It would be nice if the PR also addresses concerns from the comments in #47 (for the hours scales at least). It would also be nice if this was made the default behavior for the hours scale, or at least an "on by default" option.

For now there's unfortunately no testing framework used, but you can either create a new version of the manual test from this PR or link to a jsFiddle with an hour-scaled Gantt that includes several test items, e.g. one or two that overlap daylight savings time boundaries (specify which time zone(s)), some that cross year boundaries, and other basic test items. Please also make sure other scales are not affected.

You can make the pull request when you think things are good, or comment on your branch beforehand if you have questions. Feel free to @-mention anyone directly on specific lines of any commits you make.

I might be forgetting some things, but hope this helps in the meantime. Thanks again for taking this on!

[smiller393]

@usmonster Thanks for the guidelines. I created the tests, and they passed, so it looks like the changes were successful. One problem though.... It looks like I had forked from mbial's master branch originally, which from the looks of it, is too different from taitems's dev branch to just do a merge. Ill have to take my changes, insert them into the dev branch, and re-test ASAP.

[smiller393]

Hi @usmonster ,
I just created pull req #164 to inplement this feature. Please let me know if there are any issues, but it seems to align with the latest devlop revision.

[usmonster]

Whoops! For anyone subscribed to this issue (PR, really), it was automatically closed after I did some branch cleanup--there is no longer a develop branch. Please instead subscribe to #47, which will also address this issue. Thanks!