Home » Archived » BIRT » Standalone SWT charts/graphs from birt
| Standalone SWT charts/graphs from birt [message #231363] |
Thu, 29 March 2007 20:35  |
Eclipse User |
|
|
|
Originally posted by: jmeepta.trekspam.no
I would like to use the birt 3D Pie and Bar graph renderers in a stand alone
SWT application. Ideally I'd like to take a java class or 2 out of birt put
them in another application, pass them some numerical data, and have it return
a pretty graph on an SWT Composite.
The goal is not to reference AWT/Swing, or PNG/SVG/PDF file writing at all;
just pure SWT.
After scanning the birt code, it seems like whatever would render these SWT
graphs is heavily embedded deep within the birt package hierarchy. The
PieRenderer class I looked at references a lot of other stuff including
plugins, events, logging, and org.eclipse.emf.core, com.ibm...Locale, all the
way down to grandmas.kitchen.sink. Is anyone very familiar with these classes
and could suggest a way to extract the meat of the SWT pie/bar chart rendering
functionality with the very minimum number of classes?
SWT could really use some nice charts and graphs. Thank you.
|
|
|
| Re: Standalone SWT charts/graphs from birt [message #231457 is a reply to message #231363] |
Fri, 30 March 2007 08:24  |
| Eclipse User |
|
|
|
Hi,
The chart engine core is device independent. There is no Swing/AWT
dependency in the model renderers.
We provide a SWT device renderer. It's the org.eclipse.birt.chart.device.swt
plugin. It simply plugs onto the chart engine so you can render your charts
in SWT, without any swing dependency.
There is an example plugin and also an example view that is SWT based. I
advise you take a look at those to see how to render charts in SWT.
As for extracting a java class or two out of BIRT to render charts... I wish
charting would be that simple :)
David
"Jalalawa Meepta" <jmeepta@trekspam.no> wrote in message
news:euhlvj$o3n$1@build.eclipse.org...
>I would like to use the birt 3D Pie and Bar graph renderers in a stand
>alone SWT application. Ideally I'd like to take a java class or 2 out of
>birt put them in another application, pass them some numerical data, and
>have it return a pretty graph on an SWT Composite.
>
> The goal is not to reference AWT/Swing, or PNG/SVG/PDF file writing at
> all; just pure SWT.
>
> After scanning the birt code, it seems like whatever would render these
> SWT graphs is heavily embedded deep within the birt package hierarchy. The
> PieRenderer class I looked at references a lot of other stuff including
> plugins, events, logging, and org.eclipse.emf.core, com.ibm...Locale, all
> the way down to grandmas.kitchen.sink. Is anyone very familiar with these
> classes and could suggest a way to extract the meat of the SWT pie/bar
> chart rendering functionality with the very minimum number of classes?
>
> SWT could really use some nice charts and graphs. Thank you.
>
>
|
|
|
| Re: Standalone SWT charts/graphs from birt [message #231718 is a reply to message #231457] |
Sun, 01 April 2007 16:02 |
| Eclipse User |
|
|
|
Originally posted by: jmeepta.trekspam.no
Hi,
It is really nice not to depend on Swing/AWT. I've been looking at the code a
lot lately, trying to make some more sense of how it all fits together.
The goal was to be able to take the chart.model.* classes, along with the
chart.renderers.* and just chart.device.swt.* (along with the chart.device
interfaces), and have that somehow work on their own, to use it in an SWT
application like Azureus. (Something like JFreeChart but for SWT without the
AWT/Swing requirements) Birt has some nice 3D pie, line, pointy cone(?) and
other charts that look great and would be useful in the community of SWT apps.
My hope was that when an SWT program needed a pretty chart it would just need
these small group of classes, could set some input data and labels
(TextDataSet and NumberDataSet) with width/height, and render the resulting
chart to an swt.Image or swt.Composite. (Similar to CreatePieChart_1 in
report.tests.chart.smoke* but for SWT?) Every SWT program that needed charts
and graphs shouldn't need to write their own chart classes (why re-invent the
wheel?) when such nice ones already exist.
Unfortunately it doesn't seem to untangle that easily. Many dependencies
don't make immediate sense to me, like emf classes, emf.core.notifications and
ibm..Locale and a whole lot of other stuff continue to bloat what I'm trying
to separate out and I still haven't been able to completely extricate them.
Conceptually it seems like it should be possible, perhaps if more of the
Eclipse specific stuff were in superclasses of the main fundamental "take
input, draw output" classes which would presumably be pretty small. Perhaps
someone that has a deeper understanding of how it fits together and therefore
how it could be extracted would have better luck. The JFace team were able to
make a smaller standalone JFace that could enhance standalone SWT apps, but
also continue to work within the eclipse framework.
Am I wrong in thinking it is conceptually possible? Do you (or anyone that
has worked on birt charts) know if it would be much work to make the above
dream possible? If so any detailed pointers on what exactly can be cut out
would be very helpful!
"David Michonneau" <dmichonneau@actuate.com> wrote in message
news:euivhm$tn1$1@build.eclipse.org...
> Hi,
>
> The chart engine core is device independent. There is no Swing/AWT
> dependency in the model renderers.
>
> We provide a SWT device renderer. It's the org.eclipse.birt.chart.device.swt
> plugin. It simply plugs onto the chart engine so you can render your charts
> in SWT, without any swing dependency.
>
> There is an example plugin and also an example view that is SWT based. I
> advise you take a look at those to see how to render charts in SWT.
>
> As for extracting a java class or two out of BIRT to render charts... I wish
> charting would be that simple :)
>
> David
|
|
|
| Re: Standalone SWT charts/graphs from birt [message #232012 is a reply to message #231718] |
Tue, 03 April 2007 05:00 |
| Eclipse User |
|
|
|
Hi,
I am not sure to understand why you want to have a mininum set of classes.
The chart model is built on EMF, so there is no way to get rid of it with
the existing model. There are many advantages to use EMF, to name a few:
- Persistency service (Serialization/deserialization)
- Classes generation/regeneration. You just need to change the model schema
to change the model and let EMF regenerate the code
- Notification and command framework if you need one in your UI to work with
the chart model
ICU also have many advantages over the standard localization. See here:
http://icu-project.org/. I believe most eclipse plugins use it.
You can use ICU and EMF in any java app, so it shouldn't be a problem. There
is also a Rhino dependency to run the JavaScripts scripts.
Thanks,
David
"Jalalawa Meepta" <jmeepta@trekspam.no> wrote in message
news:eup347$70p$1@build.eclipse.org...
> Hi,
>
> It is really nice not to depend on Swing/AWT. I've been looking at the
> code a lot lately, trying to make some more sense of how it all fits
> together.
>
> The goal was to be able to take the chart.model.* classes, along with the
> chart.renderers.* and just chart.device.swt.* (along with the chart.device
> interfaces), and have that somehow work on their own, to use it in an SWT
> application like Azureus. (Something like JFreeChart but for SWT without
> the AWT/Swing requirements) Birt has some nice 3D pie, line, pointy
> cone(?) and other charts that look great and would be useful in the
> community of SWT apps. My hope was that when an SWT program needed a
> pretty chart it would just need these small group of classes, could set
> some input data and labels (TextDataSet and NumberDataSet) with
> width/height, and render the resulting chart to an swt.Image or
> swt.Composite. (Similar to CreatePieChart_1 in report.tests.chart.smoke*
> but for SWT?) Every SWT program that needed charts and graphs shouldn't
> need to write their own chart classes (why re-invent the wheel?) when such
> nice ones already exist.
>
> Unfortunately it doesn't seem to untangle that easily. Many dependencies
> don't make immediate sense to me, like emf classes, emf.core.notifications
> and ibm..Locale and a whole lot of other stuff continue to bloat what I'm
> trying to separate out and I still haven't been able to completely
> extricate them.
>
> Conceptually it seems like it should be possible, perhaps if more of the
> Eclipse specific stuff were in superclasses of the main fundamental "take
> input, draw output" classes which would presumably be pretty small.
> Perhaps someone that has a deeper understanding of how it fits together
> and therefore how it could be extracted would have better luck. The JFace
> team were able to make a smaller standalone JFace that could enhance
> standalone SWT apps, but also continue to work within the eclipse
> framework.
>
> Am I wrong in thinking it is conceptually possible? Do you (or anyone
> that has worked on birt charts) know if it would be much work to make the
> above dream possible? If so any detailed pointers on what exactly can be
> cut out would be very helpful!
>
>
>
> "David Michonneau" <dmichonneau@actuate.com> wrote in message
> news:euivhm$tn1$1@build.eclipse.org...
>> Hi,
>>
>> The chart engine core is device independent. There is no Swing/AWT
>> dependency in the model renderers.
>>
>> We provide a SWT device renderer. It's the
>> org.eclipse.birt.chart.device.swt plugin. It simply plugs onto the chart
>> engine so you can render your charts in SWT, without any swing
>> dependency.
>>
>> There is an example plugin and also an example view that is SWT based. I
>> advise you take a look at those to see how to render charts in SWT.
>>
>> As for extracting a java class or two out of BIRT to render charts... I
>> wish charting would be that simple :)
>>
>> David
>
>
|
|
|
| Re: Standalone SWT charts/graphs from birt [message #232282 is a reply to message #232012] |
Wed, 04 April 2007 16:20 |
| Eclipse User |
|
|
|
Originally posted by: jmeepta.trekspam.no
Hi,
Let us suppose that I write a standalone java application that directly uses
SWT rather than AWT/SWING, and it is 1 megabyte in size (let us call it
Azureas Bittorrent client), and I want to add some nice looking pie/line
charts to it.
Using some pre-existing open source solution seems to be the best way to avoid
"recreating the wheel" and rewriting lots of charts on my own from scratch.
Birt has some nice looking charts that work in SWT, but requiring all 3
million users to download a web of dependencies totaling 250 megabytes did not
seem realistic just for displaying a pie chart (even 10 megabytes seems too
much for this task), so the "mimimum set of classes needed to render an SWT
pie chart" became my first goal.
It intuitively made sense to me that there would be a minimum set of classes
that could take some raw data (numbers/co-ordinates and text = ints and
Strings), perform some algorithms on those numbers to figure out how to draw
and position a chart from them on an output device, and then a renderer would
graphically/visually render that data using the specific output device of an
SWT image, or composite.
But I guess this isn't how Birt works, or was not designed for it. I thought
"with so much existing good code that already performs the function that I'm
looking for and would be maintained in Birt, why couldn't it also be used for
the standalone example above making the existing code even more useful for the
community?" In my mind, there would be core classes that perform the basic
modelling/rendering, and superclasses to add on the Eclipse-specific
functionality for XML serialization, localization and notification.
CoreClass.java
CoreClassWithSerializationAndNotification.java extends CoreClass
and all the CoreClasses would have minimal dependencies (just working with
ints and Strings or so) and could be imported into and used in the standalone
SWT application to render some nice charts. Eclipse would use the extended
classes with all the Eclipse specific dependencies to get the extended
functionality.
(The SWT package can be used on its own without any Eclipse dependencies. I
was looking for a basic SWT chart making package that could work on its own
just with SWT. The ones in Birt were the only existing ones, but they didn't
appear to be modular enough to be used on their own.)
I hope this explains why I wanted a minimum set of classes.
"David Michonneau" <dmichonneau@actuate.com> wrote in message
news:eut548$8en$1@build.eclipse.org...
> Hi,
>
> I am not sure to understand why you want to have a mininum set of classes.
> The chart model is built on EMF, so there is no way to get rid of it with
> the existing model. There are many advantages to use EMF, to name a few:
> - Persistency service (Serialization/deserialization)
> - Classes generation/regeneration. You just need to change the model schema
> to change the model and let EMF regenerate the code
> - Notification and command framework if you need one in your UI to work with
> the chart model
>
> ICU also have many advantages over the standard localization. See here:
> http://icu-project.org/. I believe most eclipse plugins use it.
>
> You can use ICU and EMF in any java app, so it shouldn't be a problem. There
> is also a Rhino dependency to run the JavaScripts scripts.
>
> Thanks,
>
> David
|
|
|
Goto Forum:
Current Time: Sun Jun 01 04:16:30 EDT 2025
Powered by FUDForum. Page generated in 0.02681 seconds |
Home