param for width of each column

[vogel00s]

it would be nice, if the size of every column could be changed

[Chris Nelson]

Yes, it would. Care to suggest a naming scheme for the column width parameters?

[Ryan J Ollos]

Hi Chris, I'd find this very useful as well. In the meantime, I'd just like to change the width of the first column so that I can see more of the ticket description. I'm a bit lost looking at the codebase. Could you point me to the code that controls the column width?

[Ryan J Ollos]

Replying to rjollos:

... In the meantime, I'd just like to change the width of the first column so that I can see more of the ticket description. I'm a bit lost looking at the codebase. Could you point me to the code that controls the column width?

Found I can already do this with the lwidth parameter. There are already so many options! Thanks for your effort on this plugin.

[Ryan J Ollos]

I think this might be approaching the point of too many options, but my suggestions for a naming scheme would be:

res = 1
res.width = ...
res.title = ...

... and as shown, also add the ability to customize the column title.

[Patrick Schaaf]

The too-many-options would be a problem mostly for the repeated use in macro invocations, I think.

Extending the approach I chose in #8961 to make all macro arguments configurable in trac.ini (overriding the plugin builtin defaults), I propose being able to configure in trac.ini something like this:

[trac-jsgantt]
style.foo.res = 1
style.foo.res.width = 128
style.bar.res = 0

and then use a macro argument [[TracJSGanttChart(style=foo, ...)]] to select which of these styles to apply.

Maybe even a style-inherit.bar = foo , if we want to get maximally fancy.

If you (and Chris) like the idea, and if Chris promises to teach the JS code to observe the column widths and titles :) - I'd be happy to code the configuration logic / inheritance!

[Chris Nelson]

Replying to rjollos:

... Found I can already do this with the lwidth parameter. There are already so many options!

So many things are Yogi Berra problems: "when you get to a fork in the road, take it!" I want it one way someone else wants it another. The answer is to make it configurable. As long as there are sane defaults, many options isn't a big deal.

Thanks for your effort on this plugin.

I'm glad others are finding it useful. I got 5 patches this week and had 30 messages overnight last night.

[Chris Nelson]

Replying to bof:

The too-many-options would be a problem mostly for the repeated use in macro invocations, I think.

I agree.

Extending the approach I chose in #8961 to make all macro arguments configurable in trac.ini (overriding the plugin builtin defaults), I propose being able to configure in trac.ini something like this:

[trac-jsgantt]
style.foo.res = 1
style.foo.res.width = 128
style.bar.res = 0

and then use a macro argument [[TracJSGanttChart(style=foo, ...)]] to select which of these styles to apply.

That's an interesting idea.

Maybe even a style-inherit.bar = foo , if we want to get maximally fancy.

So bar is all of foo except anything bar specifies explicitly?

If you (and Chris) like the idea, and if Chris promises to teach the JS code to observe the column widths and titles :) - I'd be happy to code the configuration logic / inheritance!

I'd prefer this was implemented in a "configuration management" plugin that the Gantt chart used than hide this generally-useful feature in my plugin.

For me, the ideal would be if this overrode the existing configuration get() method so you could do:

self.milestoneType = self.config.get('trac-jsgantt',
                                     'res', 
                                     default=0,
                                     style='foo')

and it would handle inheritance, etc. If style was omitted, it would work as the existing configuration management does. I don't know enough about the Python and Trac object model to know if that's practical.

[Patrick Schaaf]

Replying to ChrisNelson:

I'd prefer this was implemented in a "configuration management" plugin that the Gantt chart used than hide this generally-useful feature in my plugin.

Initial implementation is done, see TracMacroConfigPlugin.

I opened a new ticket, #8979, with a use-it patch and for further discussion.