Rendering full width chart

[mazzazzam]

Hi folks!

I'm trying to use the JQuery.Gantt with some basic functionality in a project. In my case, I just need the scale fixed on Weeks. That's easy.

But I was wondering how can I make the chart render with 100% width without having any task/operation over the year.

The chart render according the tasks date range, but I need to make it render all width long (inside my parent div) even without any task loaded.

I've tried to make this with CSS but no success. I was taking a look into .js and tried some modifications but it mess out everything.

Does anyone know how can I make this work?

[usmonster]

Hi @mazzazzam ! Thanks for reporting the issue. This has definitely been thought about for a while (see #6). Something similar was also briefly discussed on a pull request a while back, though the context was more related to the scrollToToday behavior. It's a good topic to bring up again, though.

I think nobody likes the empty space. :] It seems pretty reasonable to fill the chart to the visible width of its container, though there are some situations where knowing the actual desired behavior could be tricky. I imagine this behavior could end up becoming an option to the plugin (fillChart: true maybe?), but it's definitely worth discussion. @taitems, any thoughts on what to do about empty space (style vs. filling the chart vs. other options?).

In any case, for your own use, adding the following to the end of the init function might get you started:

//...
element.dateStart = tools.getMinDate(element);
element.dateEnd = tools.getMaxDate(element);

// fill available right panel width
var msInCurrentRange = element.dateEnd - element.dateStart;
var daysPerUnit = (function () {
    switch (settings.scale) {
        case 'months':
            return 31;
        case 'weeks':
            return 7;
        default:
            return 1;
    }
})();
var msPerUnit = 8.64e7 * daysPerUnit;
var totalUnitsNow = Math.ceil(msInCurrentRange / msPerUnit) + 1;
var totalUnitsNeeded = Math.ceil($(element).width() / tools.getCellSize());
var unitsToAdd = totalUnitsNeeded - totalUnitsNow;
if (unitsToAdd > 0) {
    element.dateEnd.setDate(element.dateEnd.getDate() + (unitsToAdd * daysPerUnit));
}

/* core.render(element); */
//...

Hope this helps!

[mazzazzam]

I would pay you a beer if you lived here in Brazil @usmonster! Thanks a lot! It works like a charm!

I'm 1+ for this behavior becomes a plugin option! Like you said, I think nobody likes that empty space too.

Congrats from Brazil for the good work on this amazing plugin!

[jeffutter]

I was wondering about this issue too. The above code renders nicely for me.

[usmonster]

Glad it's working for some folks! Can you make sure it also works for the hours scale? I don't remember if I tested it for that.

[jeffutter]

I am using it with hours. Looks good. Shows today (which is all it showed before), tomorrow and a sliver of the first hour of the next day.

[jeffutter]

One thing I noticed. The controls show up centered under where the chart would have ended before the above code is added. It should be centered under the whole frame

[usmonster]

@jeffutter Can you post a couple before & after jsfiddles?

[jeffutter]

yup:

original: http://jsfiddle.net/n7M3N/
new: http://jsfiddle.net/6ybfv/1/

You will probably have to grab the frame and resize it to see what happens when the graph is wider than just one day.

[usmonster]

@jeffutter Sorry for the delay getting back to you, but I'm not sure I understand the issue. For me, it looks like the chart controls left-aligned under the right panel, which is how it normally looks. Did I misunderstand something?

[jeffutter]

@usmonster I see your point. I think that is fine on smaller width charts. On a wide page width though I think it looks better for the controls to be centered. That is just my opinion though... and a small detail.

[usmonster]

@jeffutter Agreed that's a separate issue. Feel free to file it!

[jeffutter]

Since the location of the controls is a separate issue. Can we get this issue merged?

[usmonster]

@taitems, what do you think? I'm slightly worried that the var msPerUnit = 8.64e7 * daysPerUnit; line might yield some buggy edge cases for daylight savings time, but this feature doesn't really call for exact precision, so it could be fine.

I can make a pull request with essentially what I put in the first comment. Merging it would also likely supersede #6.