You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Greg Brown <gk...@mac.com> on 2010/09/30 21:07:37 UTC
SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Hi all,
I'm quite impressed with what can be done with SVG Salamander within a Pivot app. If Mark (SVG Salamander's creator) is willing to include the Pivot adapter code I wrote in his project, I'm actually thinking that we might want to simply drop support for Pivot's own "shape DOM" in favor of SVG Salamander. Along the same lines, it would be great if we could get David Gilbert, the creator of JFreeChart, to include the code from the Pivot/JFree project in his distribution. I asked him about this a couple of years ago and nothing happened, but it has been a while so maybe I'll ping him again.
Let me know what you think. The drawing package is probably the one that gets the least attention and testing, and it is clearly inferior to other alternatives like SVG Salamander. It might be best to simply save ourselves the effort of maintaining it (and reduce our JAR size a bit) by dropping it.
G
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Greg Brown <gk...@mac.com>.
> But just a question, if someone would try to use Batik instead ?
It is certainly possible to use Batik - I imagine a similar approach could be applied. However, Batik is pretty large, whereas SVG Salamander is tiny - ideal for the kinds of use cases we might expect in a Pivot app.
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Greg Brown <gk...@mac.com>.
FYI, this is done. I moved the sample app here:
http://svn.apache.org/repos/asf/pivot/trunk/examples/src/org/apache/pivot/examples/svg/
This does mean that we now need to include the SVG Salamander JAR in SVN in order to build Pivot, but it is dual-licensed as LGPL as well as BSD, which is compatible with ASL. So this shouldn't be a problem.
Let me know if you have any questions.
G
On Oct 1, 2010, at 3:55 PM, Greg Brown wrote:
> Another option that just occurred to me is to simply replace the Drawing class with the SVGImage class from the prototype, and rename SVGImageSerializer to DrawingSerializer. These classes could live in org.apache.pivot.wtk.media as always, but Drawing would wrap an SVG Salamander SVGDiagram instead of an org.apache.pivot.wtk.medie.drawing.Canvas. It would be similar to how Picture currently wraps an AWT BufferedImage.
>
> This would of course entail a dependency on SVG Salamander, but only if callers tried to use the Drawing class. The benefit of this approach is that applications wouldn't need to explicitly add the SVGImageSerializer to BXMLSerializer's MIME map - Drawings could be loaded by Image.LoadTask, as is currently done for Pictures, so instead of this:
>
> <ImageView>
> <image>
> <bxml:include src="foo.svg"/>
> </image>
> </ImageView>
>
> we could do this:
>
> <ImageView image="@foo.svg"/>
>
> which I think is much nicer.
>
> Thoughts?
>
> G
>
>
> On Oct 1, 2010, at 12:41 PM, Greg Brown wrote:
>
>> Honestly, even if we can't get dynamic updates working, I still think it is worth dropping the shape DOM classes. We'd still be able to use SVG diagrams as image assets, which is arguably where they will be most valuable in a Pivot app anyways.
>>
>> There's just a lot of code in the org.apache.pivot.wtk.media.drawing package that hardly ever gets exercised, and a major release like 2.0 is probably the best time to make a change like this.
>>
>>
>> On Oct 1, 2010, at 12:36 PM, Greg Brown wrote:
>>
>>> OK, I have some dynamic updates working. I ported the "add circle" logic from Mark's dynamic SVG sample app to the Pivot demo and it seems to work. However, I still have a couple of questions:
>>>
>>> 1) Is it possible to trigger a repaint of only those elements that have changed, or do you need to repaint the entire diagram every time you change any element? The comments in the dynamic SVG example are a little confusing: they say that calling update() on the Circle won't update the parent, but calling update on the Group does appear to have some impact on its own parent, since the Group isn't the root element. I'm not sure what the rules are, so I'm simply calling update() (or updateTime()) on the diagram itself. Is there a better (i.e. more efficient) way?
>>>
>>> 2) I'm having some trouble resizing the image. I set the "width" and "height" attributes of the root object as follows:
>>>
>>> SVGRoot root = diagram.getRoot();
>>> try {
>>> root.setAttribute("width", AnimationElement.AT_XML, Integer.toString(width));
>>> root.setAttribute("height", AnimationElement.AT_XML, Integer.toString(height));
>>> } catch (SVGElementException exception) {
>>> throw new RuntimeException(exception);
>>> }
>>>
>>> try {
>>> diagram.updateTime(0.0);
>>> } catch (SVGException exception) {
>>> throw new RuntimeException(exception);
>>> }
>>>
>>> However, the changes don't appear to take effect until the second time I call this code. You can see what I mean if you run the demo.
>>>
>>> Any help would be much appreciated.
>>>
>>> Thanks,
>>> Greg
>>>
>>> <pivot_svgsalamander.zip>
>>>
>>> On Oct 1, 2010, at 10:49 AM, Greg Brown wrote:
>>>
>>>> FYI, Mark has explained to me how repaints are triggered. Once I get something working in a Pivot app, I'll post an update.
>>>>
>>>> On Oct 1, 2010, at 7:39 AM, Greg Brown wrote:
>>>>
>>>>>> So then there are two ways to work with SVG then: as serialized file resources (the demo today) and also building a SVGDiagram from code. I just wanted to confirm this.
>>>>>
>>>>> Yes, but we'll still need clarification from Mark on how repaints can be triggered when an SVGDiagram is modified. Mark, can you share any insight here? How does this work in a Swing app, for example?
>>>>>
>>>>
>>>
>>
>
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Greg Brown <gk...@mac.com>.
> Right, popup is just an undecorated window. With a FadeDecorator it can be transparent and then be populated with different icons, etc, as required. Hows that for starting to get my Pivot ABC's together :-)
Very nice. :-)
> Speaking of windows, does the full-screen handler move between window and regular decorated frame automatically? It looked to me like there was some fancy display-host stuff going on in the application objects.
You can use Control-Shift-F to toggle between full screen and windowed mode.
G
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Superstring Media <su...@gmail.com>.
Right, popup is just an undecorated window. With a FadeDecorator it can be transparent and then be populated with different icons, etc, as required. Hows that for starting to get my Pivot ABC's together :-)
Speaking of windows, does the full-screen handler move between window and regular decorated frame automatically? It looked to me like there was some fancy display-host stuff going on in the application objects.
Cheers,
Thom
On 2010-10-01, at 7:09 PM, Greg Brown wrote:
>> Now that there will be a SVGImage wrapping a SVGDiagram there are also more options for the type of inplace/contextual floating editors I need to have for editing score data and symbols. These small editors need to be built dynamically as the mouse moves about the score to reflect what editing options are possible in a given music context (kind off like MetaWidget if you have seen it).
>
> You actually don't need SVG to implement features such as this - there are a number of ways you can do this in a Pivot app. A typical approach is to use a "popup" window - basically just an undecorated window that contains data/component relevant to whatever the mouse is currently hovering over.
>
>> P.S. Pivot is not far from doing the kind of thing MetaWidget is doing, might be a nice way to quickly layout forms in Pivot too?
>
> Maybe MetaWidget should consider adding Pivot support. :-)
>
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Greg Brown <gk...@mac.com>.
> Now that there will be a SVGImage wrapping a SVGDiagram there are also more options for the type of inplace/contextual floating editors I need to have for editing score data and symbols. These small editors need to be built dynamically as the mouse moves about the score to reflect what editing options are possible in a given music context (kind off like MetaWidget if you have seen it).
You actually don't need SVG to implement features such as this - there are a number of ways you can do this in a Pivot app. A typical approach is to use a "popup" window - basically just an undecorated window that contains data/component relevant to whatever the mouse is currently hovering over.
> P.S. Pivot is not far from doing the kind of thing MetaWidget is doing, might be a nice way to quickly layout forms in Pivot too?
Maybe MetaWidget should consider adding Pivot support. :-)
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Superstring Media <su...@gmail.com>.
This sounds good to me.
Now that there will be a SVGImage wrapping a SVGDiagram there are also more options for the type of inplace/contextual floating editors I need to have for editing score data and symbols. These small editors need to be built dynamically as the mouse moves about the score to reflect what editing options are possible in a given music context (kind off like MetaWidget if you have seen it).
The combination of the Pivot Image Component and the wrapped SVGDiagram together with optional Pivot decorators attached to the SVGImage and styling options can make this happen. I've spent years designing a superior non compromise environment for music composition and I'm very happy now that the means to make it happen are coming together. Superstring Media, my company has funders who are intent on releasing a quantum leap music application on a worldwide scale. Myself, I'm the CEO/CTO and these days I'm very happy!
P.S. Pivot is not far from doing the kind of thing MetaWidget is doing, might be a nice way to quickly layout forms in Pivot too?
Thom
On 2010-10-01, at 2:55 PM, Greg Brown wrote:
> Another option that just occurred to me is to simply replace the Drawing class with the SVGImage class from the prototype, and rename SVGImageSerializer to DrawingSerializer. These classes could live in org.apache.pivot.wtk.media as always, but Drawing would wrap an SVG Salamander SVGDiagram instead of an org.apache.pivot.wtk.medie.drawing.Canvas. It would be similar to how Picture currently wraps an AWT BufferedImage.
>
> This would of course entail a dependency on SVG Salamander, but only if callers tried to use the Drawing class. The benefit of this approach is that applications wouldn't need to explicitly add the SVGImageSerializer to BXMLSerializer's MIME map - Drawings could be loaded by Image.LoadTask, as is currently done for Pictures, so instead of this:
>
> <ImageView>
> <image>
> <bxml:include src="foo.svg"/>
> </image>
> </ImageView>
>
> we could do this:
>
> <ImageView image="@foo.svg"/>
>
> which I think is much nicer.
>
> Thoughts?
>
> G
>
>
> On Oct 1, 2010, at 12:41 PM, Greg Brown wrote:
>
>> Honestly, even if we can't get dynamic updates working, I still think it is worth dropping the shape DOM classes. We'd still be able to use SVG diagrams as image assets, which is arguably where they will be most valuable in a Pivot app anyways.
>>
>> There's just a lot of code in the org.apache.pivot.wtk.media.drawing package that hardly ever gets exercised, and a major release like 2.0 is probably the best time to make a change like this.
>>
>>
>> On Oct 1, 2010, at 12:36 PM, Greg Brown wrote:
>>
>>> OK, I have some dynamic updates working. I ported the "add circle" logic from Mark's dynamic SVG sample app to the Pivot demo and it seems to work. However, I still have a couple of questions:
>>>
>>> 1) Is it possible to trigger a repaint of only those elements that have changed, or do you need to repaint the entire diagram every time you change any element? The comments in the dynamic SVG example are a little confusing: they say that calling update() on the Circle won't update the parent, but calling update on the Group does appear to have some impact on its own parent, since the Group isn't the root element. I'm not sure what the rules are, so I'm simply calling update() (or updateTime()) on the diagram itself. Is there a better (i.e. more efficient) way?
>>>
>>> 2) I'm having some trouble resizing the image. I set the "width" and "height" attributes of the root object as follows:
>>>
>>> SVGRoot root = diagram.getRoot();
>>> try {
>>> root.setAttribute("width", AnimationElement.AT_XML, Integer.toString(width));
>>> root.setAttribute("height", AnimationElement.AT_XML, Integer.toString(height));
>>> } catch (SVGElementException exception) {
>>> throw new RuntimeException(exception);
>>> }
>>>
>>> try {
>>> diagram.updateTime(0.0);
>>> } catch (SVGException exception) {
>>> throw new RuntimeException(exception);
>>> }
>>>
>>> However, the changes don't appear to take effect until the second time I call this code. You can see what I mean if you run the demo.
>>>
>>> Any help would be much appreciated.
>>>
>>> Thanks,
>>> Greg
>>>
>>> <pivot_svgsalamander.zip>
>>>
>>> On Oct 1, 2010, at 10:49 AM, Greg Brown wrote:
>>>
>>>> FYI, Mark has explained to me how repaints are triggered. Once I get something working in a Pivot app, I'll post an update.
>>>>
>>>> On Oct 1, 2010, at 7:39 AM, Greg Brown wrote:
>>>>
>>>>>> So then there are two ways to work with SVG then: as serialized file resources (the demo today) and also building a SVGDiagram from code. I just wanted to confirm this.
>>>>>
>>>>> Yes, but we'll still need clarification from Mark on how repaints can be triggered when an SVGDiagram is modified. Mark, can you share any insight here? How does this work in a Swing app, for example?
>>>>>
>>>>
>>>
>>
>
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Greg Brown <gk...@mac.com>.
Another option that just occurred to me is to simply replace the Drawing class with the SVGImage class from the prototype, and rename SVGImageSerializer to DrawingSerializer. These classes could live in org.apache.pivot.wtk.media as always, but Drawing would wrap an SVG Salamander SVGDiagram instead of an org.apache.pivot.wtk.medie.drawing.Canvas. It would be similar to how Picture currently wraps an AWT BufferedImage.
This would of course entail a dependency on SVG Salamander, but only if callers tried to use the Drawing class. The benefit of this approach is that applications wouldn't need to explicitly add the SVGImageSerializer to BXMLSerializer's MIME map - Drawings could be loaded by Image.LoadTask, as is currently done for Pictures, so instead of this:
<ImageView>
<image>
<bxml:include src="foo.svg"/>
</image>
</ImageView>
we could do this:
<ImageView image="@foo.svg"/>
which I think is much nicer.
Thoughts?
G
On Oct 1, 2010, at 12:41 PM, Greg Brown wrote:
> Honestly, even if we can't get dynamic updates working, I still think it is worth dropping the shape DOM classes. We'd still be able to use SVG diagrams as image assets, which is arguably where they will be most valuable in a Pivot app anyways.
>
> There's just a lot of code in the org.apache.pivot.wtk.media.drawing package that hardly ever gets exercised, and a major release like 2.0 is probably the best time to make a change like this.
>
>
> On Oct 1, 2010, at 12:36 PM, Greg Brown wrote:
>
>> OK, I have some dynamic updates working. I ported the "add circle" logic from Mark's dynamic SVG sample app to the Pivot demo and it seems to work. However, I still have a couple of questions:
>>
>> 1) Is it possible to trigger a repaint of only those elements that have changed, or do you need to repaint the entire diagram every time you change any element? The comments in the dynamic SVG example are a little confusing: they say that calling update() on the Circle won't update the parent, but calling update on the Group does appear to have some impact on its own parent, since the Group isn't the root element. I'm not sure what the rules are, so I'm simply calling update() (or updateTime()) on the diagram itself. Is there a better (i.e. more efficient) way?
>>
>> 2) I'm having some trouble resizing the image. I set the "width" and "height" attributes of the root object as follows:
>>
>> SVGRoot root = diagram.getRoot();
>> try {
>> root.setAttribute("width", AnimationElement.AT_XML, Integer.toString(width));
>> root.setAttribute("height", AnimationElement.AT_XML, Integer.toString(height));
>> } catch (SVGElementException exception) {
>> throw new RuntimeException(exception);
>> }
>>
>> try {
>> diagram.updateTime(0.0);
>> } catch (SVGException exception) {
>> throw new RuntimeException(exception);
>> }
>>
>> However, the changes don't appear to take effect until the second time I call this code. You can see what I mean if you run the demo.
>>
>> Any help would be much appreciated.
>>
>> Thanks,
>> Greg
>>
>> <pivot_svgsalamander.zip>
>>
>> On Oct 1, 2010, at 10:49 AM, Greg Brown wrote:
>>
>>> FYI, Mark has explained to me how repaints are triggered. Once I get something working in a Pivot app, I'll post an update.
>>>
>>> On Oct 1, 2010, at 7:39 AM, Greg Brown wrote:
>>>
>>>>> So then there are two ways to work with SVG then: as serialized file resources (the demo today) and also building a SVGDiagram from code. I just wanted to confirm this.
>>>>
>>>> Yes, but we'll still need clarification from Mark on how repaints can be triggered when an SVGDiagram is modified. Mark, can you share any insight here? How does this work in a Swing app, for example?
>>>>
>>>
>>
>
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Greg Brown <gk...@mac.com>.
Honestly, even if we can't get dynamic updates working, I still think it is worth dropping the shape DOM classes. We'd still be able to use SVG diagrams as image assets, which is arguably where they will be most valuable in a Pivot app anyways.
There's just a lot of code in the org.apache.pivot.wtk.media.drawing package that hardly ever gets exercised, and a major release like 2.0 is probably the best time to make a change like this.
On Oct 1, 2010, at 12:36 PM, Greg Brown wrote:
> OK, I have some dynamic updates working. I ported the "add circle" logic from Mark's dynamic SVG sample app to the Pivot demo and it seems to work. However, I still have a couple of questions:
>
> 1) Is it possible to trigger a repaint of only those elements that have changed, or do you need to repaint the entire diagram every time you change any element? The comments in the dynamic SVG example are a little confusing: they say that calling update() on the Circle won't update the parent, but calling update on the Group does appear to have some impact on its own parent, since the Group isn't the root element. I'm not sure what the rules are, so I'm simply calling update() (or updateTime()) on the diagram itself. Is there a better (i.e. more efficient) way?
>
> 2) I'm having some trouble resizing the image. I set the "width" and "height" attributes of the root object as follows:
>
> SVGRoot root = diagram.getRoot();
> try {
> root.setAttribute("width", AnimationElement.AT_XML, Integer.toString(width));
> root.setAttribute("height", AnimationElement.AT_XML, Integer.toString(height));
> } catch (SVGElementException exception) {
> throw new RuntimeException(exception);
> }
>
> try {
> diagram.updateTime(0.0);
> } catch (SVGException exception) {
> throw new RuntimeException(exception);
> }
>
> However, the changes don't appear to take effect until the second time I call this code. You can see what I mean if you run the demo.
>
> Any help would be much appreciated.
>
> Thanks,
> Greg
>
> <pivot_svgsalamander.zip>
>
> On Oct 1, 2010, at 10:49 AM, Greg Brown wrote:
>
>> FYI, Mark has explained to me how repaints are triggered. Once I get something working in a Pivot app, I'll post an update.
>>
>> On Oct 1, 2010, at 7:39 AM, Greg Brown wrote:
>>
>>>> So then there are two ways to work with SVG then: as serialized file resources (the demo today) and also building a SVGDiagram from code. I just wanted to confirm this.
>>>
>>> Yes, but we'll still need clarification from Mark on how repaints can be triggered when an SVGDiagram is modified. Mark, can you share any insight here? How does this work in a Swing app, for example?
>>>
>>
>
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Greg Brown <gk...@mac.com>.
FYI, Mark has explained to me how repaints are triggered. Once I get something working in a Pivot app, I'll post an update.
On Oct 1, 2010, at 7:39 AM, Greg Brown wrote:
>> So then there are two ways to work with SVG then: as serialized file resources (the demo today) and also building a SVGDiagram from code. I just wanted to confirm this.
>
> Yes, but we'll still need clarification from Mark on how repaints can be triggered when an SVGDiagram is modified. Mark, can you share any insight here? How does this work in a Swing app, for example?
>
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Greg Brown <gk...@mac.com>.
> So then there are two ways to work with SVG then: as serialized file resources (the demo today) and also building a SVGDiagram from code. I just wanted to confirm this.
Yes, but we'll still need clarification from Mark on how repaints can be triggered when an SVGDiagram is modified. Mark, can you share any insight here? How does this work in a Swing app, for example?
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Superstring Media <su...@gmail.com>.
Thanks for reminding me about retained versus immediate rendering modes, its been an exciting day :-)
To have immediate mode is a given then and SVGSalamander does indeed have a great retained structure with its SVGDiagram. What I was thinking about was the ability to add, remove and edit the element entities in the SVGDiagram, so that a SVGDiagram is able to be created and edited from within Pivot code. SVGSalamander has its own methods for this, there are examples at the bottom of this link :
https://svgsalamander.dev.java.net/docs/use.html
So then there are two ways to work with SVG then: as serialized file resources (the demo today) and also building a SVGDiagram from code. I just wanted to confirm this.
Thom
On 2010-09-30, at 9:13 PM, Greg Brown wrote:
>> There should still be a drawing facility in Pivot.
>
> There will be. Pivot will still support immediate mode rendering - just not retained mode, since there are other technologies that are better suited to that.
>
>> I'd certainly like
>> to confirm that SVGSalamander can be used for defining a new drawing from
>> Pivot first.
>
> Not completely sure what you mean. I thought that the demo I put together earlier today pretty clearly demonstrated that SVG Salamander can be used for this?
>
>> SVGSalamader also handles annimation so the same confirmation
>> is needed for the movie functions.
>
> The "movie" features of Pivot are easily one of the most underused aspects of the platform. I'm not saying that they are poorly designed or implemented, but, like the drawing API, they haven't historically gotten much attention. If there are better alternatives available, I don't think there is much justification for keeping the existing Pivot version.
>
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Greg Brown <gk...@mac.com>.
> There should still be a drawing facility in Pivot.
There will be. Pivot will still support immediate mode rendering - just not retained mode, since there are other technologies that are better suited to that.
> I'd certainly like
> to confirm that SVGSalamander can be used for defining a new drawing from
> Pivot first.
Not completely sure what you mean. I thought that the demo I put together earlier today pretty clearly demonstrated that SVG Salamander can be used for this?
> SVGSalamader also handles annimation so the same confirmation
> is needed for the movie functions.
The "movie" features of Pivot are easily one of the most underused aspects of the platform. I'm not saying that they are poorly designed or implemented, but, like the drawing API, they haven't historically gotten much attention. If there are better alternatives available, I don't think there is much justification for keeping the existing Pivot version.
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Superstring <su...@gmail.com>.
There think should still be a drawing facility in Pivot. SVGSalamander
renders SVG which can be created in vector graphic editors however, the
drawing functions Pivot has are good for many other uses. I'd certainly like
to confirm that SVGSalamander can be used for defining a new drawing from
Pivot first. SVGSalamader also handles annimation so the same confirmation
is needed for the movie functions.
Thom
--
View this message in context: http://apache-pivot-developers.417237.n3.nabble.com/SVG-Salamander-vs-org-apache-pivot-wtk-media-drawing-tp1610372p1612025.html
Sent from the Apache Pivot - Developers mailing list archive at Nabble.com.
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Greg Brown <gk...@mac.com>.
> Yes, you have been clear ... and for me the idea is the same :-)
Any other comments on this? Any arguments in favor of keeping the drawing API?
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Sandro Martini <sa...@gmail.com>.
Yes, you have been clear ... and for me the idea is the same :-)
But just a question, if someone would try to use Batik instead ?
There is some part that could be shared between the two
implementations of the Pivot adapter (so could make sense to move in a
dedicated project somewhere) ?
For example, for this and some other little things I'm doing (as
always with my slow timings) I have created the project Pivot-Stuff on
GoogleCode, here: http://code.google.com/p/pivot-stuff/
Let me know if someone is interested in put there some stuff (any
subproject in its folder, but with all inside the main trunk), just to
not split Pivot extensions etc across many sites, but it's only my
idea ...
Bye,
Sandro
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Greg Brown <gk...@mac.com>.
> for me it's ok to drop it and move in SVG Salamander (it's a part of
> Pivot that I haven't used, and as you said maybe also others ...).
Just to be clear - in this scenario, we wouldn't be adding the SVG Salamander code to the Pivot platform itself. My hope is that Mark is willing to include the Pivot adapter code in his project (similar to how he currently provides Swing support). If for some reason he doesn't want to do this, then I'll just post it somewhere on Google Code (as pivot-svgsalamander, or something like that).
So either way, it is probably realistic to think about dropping the drawing APIs.
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
Posted by Sandro Martini <sa...@gmail.com>.
Hi,
for me it's ok to drop it and move in SVG Salamander (it's a part of
Pivot that I haven't used, and as you said maybe also others ...).
And of course the same for JFreeChart ... in the hope that it will be accepted.
Bye,
Sandro