[patch][ccla] Fixing gauge rendering on GFX canvas render + some gauges enhancement

[tissandier]

Description: The AnalogGauge? and BarGauge? widgets code supposes that the GFX renderer is SVG or VML. This patch fixes this so that any GFX renderer is supported, in particular the canvas renderer, so that the Gauges can be rendered on Android 2 where only canvas is available.

Some enhancement are also proposed to the Gauge package:

-new 'strokeColor' properties for the indicators to specify a different stroke color for needles or arrows.

• Improved layout for the labels in the circular scale, with the ability to draw the labels and ticks inside or outside the scale circle.
• New orientation property for the AnalogGauge? to have the gauge drawn 'clockwise' or 'counter-clockwise'.
• New valueChanged method on the indicators can be used with dojo.connect to know when the value of the indicator changes.

[Chris Mitchell]

patch appears to be out of date with trunk

[tissandier]

I am adding a new patch file (that works with trunk) and contains additional work: -Touch support for mobile devices -Gauges do not use _Templated, _Container and Contained anymore -New indicators : TextIndicator? and AnalogCircleIndicator? -new test files to show the new features.

[tissandier]

Gauge patch as of March 18, 2011

[tissandier]

I have completed the new Glossy Horizontal, Circular and Semi Circular Gauges . They are now available in the patch named ​http://bugs.dojotoolkit.org/attachment/ticket/12315/12315.patch.

This patch contains all the enhancements for the Gauges, no need to apply the previous patches.

[Tom Trenka]

Hi tissandier--

Finally got to take a look at the patch (at least in its general overview), and I'd like to see a couple of changes (for the moment)...

• It looks to me like the patch puts all of the gauges within dojox.widget. Considering the size of the patch (and the number of files within it), I'd very much prefer if you went ahead and created a new "project" for this instead; I would like to see it under the namespace "dojox.guages". With that, you could probably rename your "guage" directory/sub-namespace to something else that makes a bit more sense when this is standalone.
• This is a minor nitpick, and if you have reasons for not wanting to do this, that's fine...but I'd like to see you rename your "draw" methods to "render". The main reason is to bring the API a little more in-line with dojox.charting, which seems to me to be the closest project to what you've been doing.

There's also some style nits that I'm not going to worry about for now, but I'll probably fix once I finally commit the patch to trunk...and I still need to go over the code in-depth. For now, I'd prefer to wait until you have a revised patch with the namespace suggestions from above.

(NB The reason for the namespace change has more to do with the clutter of dojox.widget than anything else; plus it will make it a *lot* easier for developers to find and use your code.)

[Tom Trenka]

One other thing...one thing that we do consistently with gfx and charting is that any public-facing method that does not return a value (i.e. return void) with always end with:

return this;

We do this (no pun intended) to allow for chaining methods when it seems appropriate. If you'd be willing to take a look through your code and see where something like this would be applicable, please do. It makes it *very* convenient, particularly when working programmatically.

[tissandier]

Hello ttrenka, Thanks for taking the time to look at this patch. I think you are right dojox.gauges would be better than dojox.widget but I would prefer to use the dojox.gauges for a new gauge framework that I am starting to prototype (Maybe for 2.0).

Using 'draw' would really be better than 'render' but I choose 'draw' because it was used all over the place in the gauge code already. I have no problem to change it, but changing it in all places will break the compatibility.

I have found many place where to add the 'return this', thanks for the suggestion..

[Tom Trenka]

tissandier--

No worries on the draw vs render; you're the principle author, and that's your choice. It was only a suggestion =)

On moving to dojox.gauges (sorry for the typo above)...I think it would be ok to do that anyways, since we're looking to move to Packages for 2.0; you can create your new framework and release it as a "sanctioned" package, and we'll do our best to promote it. But for the 1.x line I think it'd still be better to move to dojox.gauges, mostly because I really think this needs to be split out from dojox.widget (you have a lot of code there, and once I applied the patch I had a hard time trying to figure out where and how to implement any of your gauges).

No problem on the "return this" suggestion, I'd made it to Eugene a long time ago when he was first starting to write what became dojox.gfx, and it has really changed the way we develop certain libraries.

[tissandier]

ttrenka,

I have updated the ticket with the change to dojox.gauges... The patch also contains the 'return this' suggestion as well as changes in the original files for compatibility issue. I leave it to you to decide if it is necessary to keep the compatibility with the old namespace.

[tissandier]

ttrenka, The new patch is too big, it is now zipped in ​http://bugs.dojotoolkit.org/attachment/ticket/12315/12315.zip

[Tom Trenka]

(In [24402]) Initial commit of Emmanuel Tissandier's gauges project, en route to 1.7. Refs #12315 !strict

[tissandier]

ttrenka, Just to mention that I forgot to move a few images from dojox/widget/tests/images to dojox/gauges/tests/images. These are the gaugeOverlay.png and flare.png

[Chris Mitchell]

fixed in [24575]

[tissandier]

I am attaching a patch that removes the gauge code in dojox.widget.gauges and replaces it by compatibility to dojox.gauges (​http://bugs.dojotoolkit.org/attachment/ticket/12315/oldGaugesCompatibility.patch)

[Tom Trenka]

(In [24854]) Compatibility patch from tissandier, refs #12315 !strict

[Chris Mitchell]

(In [24973]) refs #12315 animation rendering bug in gauges \!strict