You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pivot.apache.org by Superstring <su...@gmail.com> on 2010/10/01 02:32:33 UTC
Re: SVG Salamander vs. org.apache.pivot.wtk.media.drawing
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>.
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.