GChart 2.0 Released. Now with pie, line, and area charts.

[John Gunther]

Client-side GChart 2.0 adds support for pie, line, and area charts,
baseline-based bar charts, and more:

http://gchart.googlecode.com

With this release, GChart supports all the basic chart types while
remaining an Apache-licensed, 100% pure GWT-Java library without
requiring JSNI, browser plug-ins, or server round trips.

Below I'll share some technical aspects of GChart 2.0's implementation
I hope you'll find interesting.

* Squaring the Pie Slice

Some of you may recall the original GChart 1.1 post/discussion:

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/1b14846ee6b91f41/a2ba97266f2fe041?#a2ba97266f2fe041

Reading this, you may wonder how I ended up implementing pie slices
and arbitrary angled connecting lines. Did I use the "transparent
border triangle trick" and/or clever algorithms from walterzorn.com?

Though I tried to use these, I reverted to something a lot simpler:
dotted connecting lines and banded-filled pie slices. Two new Symbol
class properties, fillSpacing and fillThickness, let you control the
spacing of the dots/bands and their size/thickness.

Though this approach means you may sometimes have to choose between
visual chart quality and speed, these new properties make it easy for
you to control this tradeoff. Besides, I like to think that dotted
connecting lines and banded fill pie slices really don't look all that
much worse than the solid fill variety. But then again, I could never
understand why no one ever used square pie charts...

In any case, the whole point of GChart is to layer the chart on top of
standard GWT Widgets, so, since those Widgets can only really draw
rectangles efficiently, I decided to make a virtue of necessity and
whole-heartedly embrace this dotted/banded look.

* CSS Convenience Methods: A cure for "CSS anxiety disorder"?

For many months I suffered from "CSS anxiety disorder": a condition
arising from one's desire to use CSS to specify an attribute (and thus
conform to a GWT best practice) while simultaneously wanting the same
property in the Java API (so that it would not be unnaturally
segregated from closely related features).

To address this (possibly imaginary) problem, the GChart 2.0 Java API
includes "CSS convenience methods" that can (optionally) override
traditionally CSS-based attribute specifications for certain selected
CSS attributes.

To some, this may seem like a fine point, since you could easily do
the same thing via a GWT DOM class method call, but to me, once you
invoke a DOM method you are thinking of the GChart as an HTML element,
and for some usage scenarios, that just isn't logical.

For example, for some applications, the background color of a GChart
is mainly about how the color-scheme of the chart blends in with the
surrounding page, and for these applications a CSS-based specification
makes good sense. Yet, for other applications, it is mainly all about
how well background color matches with, say, with the pie slice
shading pattern. That is, in some cases, background color is better
viewed as a feature of the GChart considered as a Java object
independent of its connection to any web page. So why can't you just
call GChart.setBackgroundColor in such cases? With GChart, you can.

To assure that the two specification methods can exist harmoniously
together, GChart recognizes a special property value, GChart.USE_CSS,
which instructs GChart to stand aside and allow the traditional CSS
cascade to define the attribute. For all such "dual access" GChart
Java properties (which are simultaneously also CSS attributes),
USE_CSS is the default property value. This assures that you can use
CSS just as you would with a standard GWT Widget whenever it makes
more sense to control that attribute from the "GChart as HTML element"
perspective.

Thanks to these CSS convenience methods, I have attained inner peace
through Java/CSS redundancy. I recommend the same treatment for anyone
else suffering from "CSS anxiety disorder". See the GChart.USE_CSS
javadoc comment for more information.

The following post by Peter Blazejewicz (thanks!) provided key
insights and a valuable Adobe Flex link that finally allowed me
resolve this problem to my satisfaction:

http://groups.google.com/group/Google-Web-Toolkit/msg/d8db5c7d56929c38

* GAME (GWT Ant Macros for Eclipse)

GChart 1.1 used an interactive build from Eclipse. GChart 2.0 is the
first version to use an ant-based build, as recommended to me by Ian
Petersen (http://roughian.com) and Isaac Truett in this thread:

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/e59ca3641ad2888f/39a1ac1184e81dd6?#39a1ac1184e81dd6

Not having used Ant before and being rather slow at transferring the
syntax of GWT compiler commands into the syntax required by ant, I
found the conversion very painful. Plus, I was aggravated by the
thought "since so many other GWTers have already done this, why do I
have to do it again?". So I tried to put what I learned from the above
post and looking at other ant based builds in various open source
projects into a small set of reusable ant macros, targeted at someone
making the Eclipse-to-ant transition for the first time, that you can
see here:

http://gchart.googlecode.com/svn/trunk/gchart/game.xml

And here's the GChart ant build script that employs these macros:

http://gchart.googlecode.com/svn/trunk/gchart/build-gchart.xml

I gave these macros a name much more generic than their specialized
nature deserves--but perhaps someone will be inspired by that name to
create a really general set of such macros and distribute them as an
open source project or even as a facet of GWT's extended Eclipse-
supporting toolset. I would have used it, at least.

* Kudos to GWT

Reasonable people can disagree about if it makes sense to layer a
chart library on top of standard GWT Widgets. What is undeniable is
that doing such a project is a kind of "stress test" for the basic GWT
GUI infrastructure. It's the kind of test some other GUI libraries
I've used would have failed miserably, but that GWT passed so easily
that I almost forget to mention it.

Finally, thanks to the thousands of you who downloaded GChart 1.1 and
even more thanks to those of you who actually tried it and mentioned
it. I hope you like GChart 2.0

John Gunther

[Ian Petersen]

On Sun, Mar 30, 2008 at 12:40 AM, John Gunther
<johncurt...@yahoo.com> wrote:
> * GAME (GWT Ant Macros for Eclipse)
>
> GChart 1.1 used an interactive build from Eclipse. GChart 2.0 is the
> first version to use an ant-based build, as recommended to me by Ian
> Petersen (http://roughian.com) and Isaac Truett in this thread:

Thanks for the mention--it's huge ego rub to see my name in print--but
I have no connection with http://roughian.com. I think it's Ian
Bambury that runs that particularly useful resource.

Ian

--
Tired of pop-ups, security holes, and spyware?
Try Firefox: http://www.getfirefox.com

[Peter Blazejewicz]

Hi John,

On Mar 30, 6:40 am, John Gunther <johncurtisgunt...@yahoo.com> wrote:
> The following post by Peter Blazejewicz (thanks!) provided key
> insights and a valuable Adobe Flex link that finally allowed me
> resolve this problem to my satisfaction:
>
> http://groups.google.com/group/Google-Web-Toolkit/msg/d8db5c7d56929c38
>

glad that could be helpful!
;-)

[John Gunther]

Ian,

Very sorry about that mix-up. I really like the roughian site too so
maybe it's not such a bad mistake. From now on I'm only going to trust
myself with first names only.

John

On Mar 30, 1:05 am, "Ian Petersen" <ispet...@gmail.com> wrote:
> On Sun, Mar 30, 2008 at 12:40 AM, John Gunther
>

> <johncurtisgunt...@yahoo.com> wrote:
> > * GAME (GWT Ant Macros for Eclipse)
>
> > GChart 1.1 used an interactive build from Eclipse. GChart 2.0 is the
> > first version to use an ant-based build, as recommended to me by Ian
> > Petersen (http://roughian.com) and Isaac Truett in this thread:
>
> Thanks for the mention--it's huge ego rub to see my name in print--but

> I have no connection withhttp://roughian.com. I think it's Ian

[Dean S. Jones]

Small issue with drawing charts and gchart.gif

If you include your GWT's module.js file from somewhere else other
than the module's HTML file... say in a JSP at the top of your
document structure...

script language="javascript" src="gwt/com.domain.curve.CurveEditor/
com.domian.curve.CurveEditor.nocache.js"

The graph draws with a bunch of broken image links on it.

The package assumes that gchart.gif is in the base folder, not the
Module included folder. There was a similar issue
with the first implementations of ImageBundles. I hacked GChart.java
to make it work, possibly there is a better
solution:

private final static String BLANK_GIF = GWT.getModuleBaseURL() + "/
gchart.gif";

Dean S. Jones

[John Gunther]

Dean,

Appreciate your pointing this out, and providing a patch, too. I had
assumed that anything in the module's public folder would
automatically be available to the module via a relative reference.
Thanks to your post, I know better now.

Here's the link to the ImageBundle bug/patch you mentioned:

http://code.google.com/p/google-web-toolkit/issues/detail?id=1147

Based on reading how the problem was fixed in ImageBundle, I think all
I have to do to fix this one is paste in your 1-line patch. Are you
aware of any reason that wouldn't work?

Incidentally, the same problem was in GChart 1.1 but you are the first
person to report it. My guess is that most users include the GWT
generated javascript the "Hello World way" (as all my tests do),
effectively hiding the bug until now.

Thanks again, a 2.01 is on the way.

John

[Dean S. Jones]

No problem, thank-you for the great library!!!!

As far as issues, looking at the patch for ImageBundles, I think the
only difference is the extra "/" before gchart.gif
is not needed.

Dean S. Jones

[John Gunther]

Dean,

I tried your patch, and it works quite well but has a side effect I
found unacceptable: when the absolute URL to the module base directory
is very long, it can increase the memory footprint of the GChart
significantly (10% in the demo chart with a normal length URL, but it
could be more with very long absolute URLs). In short, in some cases,
the cure could be worse than the disease or cause unexpected problems
for existing GChart users when the memory footprint ballooned when the
user upgraded or (after they upgraded to your patch) moved the GChart
to a longer-URLed location.

So for now I am either going to declare this bug a feature or provide
a workaround (call it what you will) as follows:

"GChart always expects to find its specially named 1 x 1 pixel
transparent gif, gchart.gif in the host page's base directory (see the
HTML base tag docs for information about how to define a page's base
directory). The GWT compiler automatically places gchart.gif into the
module base directory (where the compiled javascript also resides)
which for many (e.g the "Hello World" application) but not all, GWT
applications is the same directory as the host page's base directory.
If, for your application, the host page base and module directories
are not the same, you will have to either copy gchart.gif into the
host page's base directory, or use the HTML base tag to redefine the
host page's base directory to point to the module base directory, to
avoid getting 'missing image' icons in your charts."

Right now the only way to really fix this problem I can think of is to
switch from using the img tag to using the div tag, but because I have
exploited the fact that the image tag's box model implementation in
IE6 quirks mode isn't as non-standard as the div tag's to simplify my
implementation, it won't be a simple drop-in replacement if I go that
route.

Thanks again for reporting this issue, hopefully a future GChart
version will provide a better solution (your patch without the long
URL problem is what I'd like). Also, if you think I'm being overly
cautious about the long URL issue or you or anyone else has any other
suggestions I'd appreciate them. As far as a simple patch type fix is
concerned, I'm stumped.

John

[John Gunther]

Dean,

I've released GChart 2.01 that contains a new method that fixes the
bug (issue #1 in GChart's issue tracker) you reported. The javadoc for
the new, setBlankImageURL, method contains all the details:

http://gchart.googlecode.com/svn/trunk/doc/com/googlecode/gchart/client/GChart.html#setBlankImageURL(java.lang.String)

No telling how long this bug would have remained unfixed without your
report...Thanks!

The new version also fixes an unrelated bug that sometimes caused 1-
line annotations to word-wrap inappropriately in Firefox.

John Gunther

[Dean S. Jones]

Thanks John, the work-around will be just fine for me.