You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@flex.apache.org by Harbs <ha...@gmail.com> on 2016/07/25 10:12:15 UTC
Changed svg namespace
I just changed the svg namespace in the Graphics package. I’m not 100% sure I did it right — especially with the maven build.
I hope I did not mess up the next build, but we’ll find out soon. ;-)
If someone could double-check what I did (both on the ant side and the maven side), that might catch my errors sooner…
Thanks,
Harbs
Re: Changed svg namespace
Posted by Alex Harui <ah...@adobe.com>.
Copy/pasting from several posts...
On 7/27/16, 2:09 AM, "Harbs" <ha...@gmail.com> wrote:
>Thinking about this some more, I think an svg should have a different API.
>
>SVG elements should inherit from UIBase and have the full capabilities
>For one, I’m not sure primitives should implement beads. UIBase also
>makes a lot of assumptions based on normal DOM elements. SVG has quite a
>few attributes which can be specified directly rather than using styles
>(i.e. width, height opacity, etc.)
I'm not sure what you mean by "SVG elements", but IMO, the rect primitive
probably shouldn't inherit from UIBase, and maybe shouldn't not implement
IUIBase unless we decide that same Rect class will also act as the "Rect
component".
>
>It seem to me like primitives are pretty well defined and the full gamut
>of behavior should be part of the classes. Any behavior beyond that
>should require either using proper components, or wrapping the primitives
>in primitive containers.
>
>Another area which makes sense to have separate APIs for primitives is
>related to defs.[1] You can define definitions in SVG and use those in
>SVG elements contained therein. There should be a mechanism for
>primitives to get defs of their containing SVG element. A good example is
>masks[2] masking content in a single SVG is straightforward, but masking
>one SVG using another is not.
>
>[1]https://developer.mozilla.org/en-US/docs/Web/SVG/Element/defs
>[2]https://developer.mozilla.org/en-US/docs/Web/SVG/Element/mask
Does SVG support a mechanism for primitives to get their defs? If not,
IMO, doing so would be a nice-to-have, not a requirement.
>I prefer to make things a little more explicit:
><svg:Rect> would be <rect>
><svg:RectComponent> would be <svg><rect></svg>
><svg:Circle> would be <circle>
><svg:CircleComponent> would be <svg><circle></svg>
>
><canvas:Rect> would do drawRect() on the containing canvas
><canvas:RectComponent> would be <canvas> and drawRect()
><canvas:Circle> would be drawCircle() on the containing canvas
><canvas:CircleComponent> would be <canvas> and drawCircle()
>
>I’m not sold on the names. Maybe something like WrappedRect instead?
>
Another possibility is different flavors of Spacer like RectSpacer. Also
realize that for a Rect "component" you can also use a <div> and for line
there is the <hr> tag.
>
>I’m not sure how to enforce that the correct components are added to the
>correct containers, though.
>
If primitives support an interface, in theory the MXML compiler should
catch when the content property is not assigned something supporting that
interface. The ArrayElementType metadata supposedly makes that happen.
>
>The way Om did it makes that simple. All Graphic elements are simple DOM
>elements at their basic level, and can be added to anything. When you are
>dealing with primitives it’s more difficult. What I did in
>GraphicContainer (which is an svg) is that I’m overriding addElement and
>checking that the element being added is an svg-compatible component.
>Otherwise I’m throwing an error. This helps for runtime coercion, but not
>for compile-time and MXML. Ideally, there should be a compile-time way of
>checking which elements can be added to what.
>
FWIW, my philosophy is not to do runtime checking of the type of the
children. You can add conditional compilation around that check and
produce a "debug version" of the class, but at production time, in theory
you've done enough testing to get the types right, and that checking is
not helpful.
On Jul 27, 2016, at 10:59 AM, yishayw <yi...@hotmail.com> wrote:
>If we change IUIBase.addedToParent() to
>IUIBase.addedToParent(parent:IUIBase) we can probably make the necessary
>adjustments there. That also works around the mxml compile error question.
>
Whether we do that or not, in theory at addedToParent() time the parent
property is valid.
HTH,
-Alex
Re: Changed svg namespace
Posted by Harbs <ha...@gmail.com>.
Thinking about this some more, I think an svg should have a different API.
SVG elements should inherit from UIBase and have the full capabilities
For one, I’m not sure primitives should implement beads. UIBase also makes a lot of assumptions based on normal DOM elements. SVG has quite a few attributes which can be specified directly rather than using styles (i.e. width, height opacity, etc.)
It seem to me like primitives are pretty well defined and the full gamut of behavior should be part of the classes. Any behavior beyond that should require either using proper components, or wrapping the primitives in primitive containers.
Another area which makes sense to have separate APIs for primitives is related to defs.[1] You can define definitions in SVG and use those in SVG elements contained therein. There should be a mechanism for primitives to get defs of their containing SVG element. A good example is masks[2] masking content in a single SVG is straightforward, but masking one SVG using another is not.
[1]https://developer.mozilla.org/en-US/docs/Web/SVG/Element/defs
[2]https://developer.mozilla.org/en-US/docs/Web/SVG/Element/mask
On Jul 27, 2016, at 10:59 AM, yishayw <yi...@hotmail.com> wrote:
> I propose to have a single class. It could have a get
> drawnElement():WrappedHTMLElement which the transform bead, or other
> clients, would reference when interested in DOM manipulation. The condition
> would be implemented once there.
>
> Again, this is assuming wrapping in <svg> doesn't somehow make it a
> candidate for a different API.
>
>
>
>
>
> --
> View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Changed-svg-namespace-tp54150p54222.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Changed svg namespace
Posted by yishayw <yi...@hotmail.com>.
I propose to have a single class. It could have a get
drawnElement():WrappedHTMLElement which the transform bead, or other
clients, would reference when interested in DOM manipulation. The condition
would be implemented once there.
Again, this is assuming wrapping in <svg> doesn't somehow make it a
candidate for a different API.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Changed-svg-namespace-tp54150p54222.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Changed svg namespace
Posted by Harbs <ha...@gmail.com>.
How do you propose merging them?
Do you mean to have a single class that figures out what markup to use based on what it’s added to? Or do you mean have two separate classes which are determined in MXML?
There’s probably going to have to be a lot of conditional code to deal with a single class. For example: a transform bead would have to know the markup of the class to know how to properly do the transform.
As far as APIs go, it might make sense to have separate APIs, I have not thought that completely through.
On Jul 27, 2016, at 10:40 AM, yishayw <yi...@hotmail.com> wrote:
> Unless Rect and RectComponent have different APIs I would elect to merge
> them. We don't want to make the client think too much on what s/he should
> use.
>
> If we change IUIBase.addedToParent() to
> IUIBase.addedToParent(parent:IUIBase) we can probably make the necessary
> adjustments there. That also works around the mxml compile error question.
>
> The resultant DOM structure becomes less transparent (Rect could map to
> either <rect/> or <svg><rect/></svg>), but I don't think that would confuse
> me if I was inspecting the DOM.
>
>
>
> --
> View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Changed-svg-namespace-tp54150p54220.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Changed svg namespace
Posted by yishayw <yi...@hotmail.com>.
Unless Rect and RectComponent have different APIs I would elect to merge
them. We don't want to make the client think too much on what s/he should
use.
If we change IUIBase.addedToParent() to
IUIBase.addedToParent(parent:IUIBase) we can probably make the necessary
adjustments there. That also works around the mxml compile error question.
The resultant DOM structure becomes less transparent (Rect could map to
either <rect/> or <svg><rect/></svg>), but I don't think that would confuse
me if I was inspecting the DOM.
--
View this message in context: http://apache-flex-development.2333347.n4.nabble.com/Changed-svg-namespace-tp54150p54220.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
Re: Changed svg namespace
Posted by Harbs <ha...@gmail.com>.
I prefer to make things a little more explicit:
<svg:Rect> would be <rect>
<svg:RectComponent> would be <svg><rect></svg>
<svg:Circle> would be <circle>
<svg:CircleComponent> would be <svg><circle></svg>
<canvas:Rect> would do drawRect() on the containing canvas
<canvas:RectComponent> would be <canvas> and drawRect()
<canvas:Circle> would be drawCircle() on the containing canvas
<canvas:CircleComponent> would be <canvas> and drawCircle()
I’m not sold on the names. Maybe something like WrappedRect instead?
I’m not sure how to enforce that the correct components are added to the correct containers, though.
The way Om did it makes that simple. All Graphic elements are simple DOM elements at their basic level, and can be added to anything. When you are dealing with primitives it’s more difficult. What I did in GraphicContainer (which is an svg) is that I’m overriding addElement and checking that the element being added is an svg-compatible component. Otherwise I’m throwing an error. This helps for runtime coercion, but not for compile-time and MXML. Ideally, there should be a compile-time way of checking which elements can be added to what.
Harbs
On Jul 27, 2016, at 9:24 AM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/26/16, 5:02 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
> <omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>
>> On Jul 26, 2016 11:47 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>> I agree there should be a Group object.
>>>
>>> The problem is that the way the classes are currently constructed is
>>> that
>> 100 pixel “Rect" positioned at 100,100 actually contains the following
>> markup: <svg x=“100” y=“100"><rect x=“0” y=“0” width=“100”
>> height=“100”/></svg>
>>>
>>> I think the reason it was done this way was to make it possible to add
>> Rects (and similar) directly to HTML elements.
>>
>> Yes, that is correct. This was the intention. The idea comes from the
>> paradigm in Flex where you can simply add a Line or Rect in any component
>> and expect it to work correctly, especially with the layout restrictions
>> of
>> the parent component. You dont add a GraphicContainer or some such
>> container to add a graphic element. This is how Spark skins are possible.
>>
>>>
>>> I suppose we could change the way the classes are setup (and drawn) so
>> that <rect> <circle> and the like could only be added to elements which
>> legally can contain them (such as <svg> and <g>).
>>
>> I did toy around with this idea. How would this square when you want to
>> draw a circle with Canvas? Might get complicated to the user.
>
> This is not my area of expertise, but AIUI, s:Rect could be added "as a
> component" or "as a primitive" in MXML Graphics where it would be a child
> of a <Graphics /> tag [1]. IIRC, under the covers there is a fair amount
> of code to figure out where/how to draw Rect, so it wouldn't be my
> favorite way of going about it, but I just want to remind folks that it is
> a possibility.
>
> Another possibility is to have a Rect component and a separate Rect
> "graphic primitive". In some ways, what we are trying to do with FlexJS
> is identify common JS/HTML/CSS patterns and encapsulate them into
> components. So a pattern of <svg><rect/></svg> can be a component, and a
> pattern of <rect> as children of an <svg> tag is another pattern and
> another component. Different package names and different manifest URIs
> can let us call both "Rect" but we could also call one of them Rectangle
> if we really wanted to.
>
> Just food for thought,
> -Alex
>
> [1]
> http://help.adobe.com/en_US/flex/using/WSda78ed3a750d6b8fee1b36612357de97a3
> -8000.html
Re: Changed svg namespace
Posted by Alex Harui <ah...@adobe.com>.
On 7/26/16, 5:02 PM, "omuppi1@gmail.com on behalf of OmPrakash Muppirala"
<omuppi1@gmail.com on behalf of bigosmallm@gmail.com> wrote:
>On Jul 26, 2016 11:47 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>> I agree there should be a Group object.
>>
>> The problem is that the way the classes are currently constructed is
>>that
>100 pixel “Rect" positioned at 100,100 actually contains the following
>markup: <svg x=“100” y=“100"><rect x=“0” y=“0” width=“100”
>height=“100”/></svg>
>>
>> I think the reason it was done this way was to make it possible to add
>Rects (and similar) directly to HTML elements.
>
>Yes, that is correct. This was the intention. The idea comes from the
>paradigm in Flex where you can simply add a Line or Rect in any component
>and expect it to work correctly, especially with the layout restrictions
>of
>the parent component. You dont add a GraphicContainer or some such
>container to add a graphic element. This is how Spark skins are possible.
>
>>
>> I suppose we could change the way the classes are setup (and drawn) so
>that <rect> <circle> and the like could only be added to elements which
>legally can contain them (such as <svg> and <g>).
>
>I did toy around with this idea. How would this square when you want to
>draw a circle with Canvas? Might get complicated to the user.
This is not my area of expertise, but AIUI, s:Rect could be added "as a
component" or "as a primitive" in MXML Graphics where it would be a child
of a <Graphics /> tag [1]. IIRC, under the covers there is a fair amount
of code to figure out where/how to draw Rect, so it wouldn't be my
favorite way of going about it, but I just want to remind folks that it is
a possibility.
Another possibility is to have a Rect component and a separate Rect
"graphic primitive". In some ways, what we are trying to do with FlexJS
is identify common JS/HTML/CSS patterns and encapsulate them into
components. So a pattern of <svg><rect/></svg> can be a component, and a
pattern of <rect> as children of an <svg> tag is another pattern and
another component. Different package names and different manifest URIs
can let us call both "Rect" but we could also call one of them Rectangle
if we really wanted to.
Just food for thought,
-Alex
[1]
http://help.adobe.com/en_US/flex/using/WSda78ed3a750d6b8fee1b36612357de97a3
-8000.html
Re: Changed svg namespace
Posted by OmPrakash Muppirala <bi...@gmail.com>.
On Jul 26, 2016 11:47 AM, "Harbs" <ha...@gmail.com> wrote:
>
> I agree there should be a Group object.
>
> The problem is that the way the classes are currently constructed is that
100 pixel “Rect" positioned at 100,100 actually contains the following
markup: <svg x=“100” y=“100"><rect x=“0” y=“0” width=“100”
height=“100”/></svg>
>
> I think the reason it was done this way was to make it possible to add
Rects (and similar) directly to HTML elements.
Yes, that is correct. This was the intention. The idea comes from the
paradigm in Flex where you can simply add a Line or Rect in any component
and expect it to work correctly, especially with the layout restrictions of
the parent component. You dont add a GraphicContainer or some such
container to add a graphic element. This is how Spark skins are possible.
>
> I suppose we could change the way the classes are setup (and drawn) so
that <rect> <circle> and the like could only be added to elements which
legally can contain them (such as <svg> and <g>).
I did toy around with this idea. How would this square when you want to
draw a circle with Canvas? Might get complicated to the user.
I am all for adding an SVGContainer component that expects children to be
relatively positioned inside it. Maybe we could call the primitives
SVGLine, SVGRect etc? And a similar setup for Canvas?
Thanks,
Om
>
> On Jul 26, 2016, at 8:38 PM, Alex Harui <ah...@adobe.com> wrote:
>
> >
> >
> > On 7/26/16, 8:19 AM, "Harbs" <ha...@gmail.com> wrote:
> >
> >> Both.
> >>
> >> In SVG we're actually struggling with the same (or rather similar)
issue.
> >>
> >> There’s a big difference between:
> >> <div><svg><rect/></svg><svg><circle/></svg></div>
> >>
> >> and
> >> <div><svg><g><rect/><circle/></g></svg></div>
> >>
> >> Each svg has its own coordinate space, and svg elements cannot have
> >> transform properties. This is proving to be quite difficult in terms of
> >> transformations.
> >>
> >> Ideally, it should be easy to pick whether you want to wrap each shape
in
> >> its own SVG element or have them all in the same svg element (or g
> >> element). Currently GraphicShape draws each shape with its own svg
> >> wrapper. CompoundShape, on the other hand, draws separate objects
within
> >> a single svg element. GraphicContainer takes svg-type elements as
> >> children, but does not care exactly which type.
> >>
> >> I think there should also be a GraphicGroup object which would be a g
> >> element and take children.
> >>
> >> I’m struggling with how to specify whether svg element have the svg
> >> wrapper and not. (Ideas welcome!)
> >
> > IMO, I suspect there exist SVG snippets in the world that folks might
want
> > to repurpose into their FlexJS apps. Having a simple 1:1 mapping
between
> > tags is probably the best strategy. Are folks worried about the
overhead
> > of that verbosity? IMO, it is always possible to provide aggregations,
> > but aggregations make assumptions and often someone will come back and
ask
> > for the low-level.
> >
> > For example, in Flex Spark (and FlexJS) specifying a layout for a
> > container takes 3 lines:
> >
> > <Container>
> > <layout>
> > <VerticalLayout />
> > </layout>
> > </Container>
> >
> > In Flex MX, it is one line:
> >
> > <Container layout="Vertical" />
> >
> > The problem is that you can't specify other properties on the
> > VerticalLayout in MX, and Horizontal and Absolute layout are baked into
> > the MX container and are linked into your code, and you can't add new
> > layouts.
> >
> > So for graphics, if I understand the issue, why not add a <g> or <Group>
> > tag and make folks use it where they need it?
> >
> > My 2 cents,
> > -Alex
>
Re: Changed svg namespace
Posted by Peter Ent <pe...@adobe.com>.
I wasn't really too sure about the resize thing either with getBBox which
sometimes wasn't returning any value. That is a mystery a bit to me, too,
but I got it to work. I think if you have a complete picture of what you
want (API-wise), then I can adapt and redo things. Basically,
DecrementButtonView wants to have a downward arrowhead in a box, however
that's achieved.
—peter
On 7/26/16, 5:10 PM, "Harbs" <ha...@gmail.com> wrote:
>Well, the whole drawRect() method seemed redundant to me along with the
>need to specify the width and height. I tried to remove it and move the
>logic to the draw() method (sans the width and height, and I ran into the
>following code in DecrementButtonView: _backRect.drawRect(0, 0,
>host.width, host.height); I was assuming that there’s a reason the host
>width and height is being specified instead of the _backRect ones.
>
>I also have no idea what this was about: resize(x, y, _rect['getBBox']());
>
>If this can all be simplified, I’d be happy to do so, but I thought
>there’s things going on here that I don’t completely understand.
>
>I’m not understanding why a Rect needs to wrap the svg. Why can’t it just
>be a pure rect element and be required to be added to an svg or g element?
>
>On Jul 26, 2016, at 11:55 PM, Peter Ent <pe...@adobe.com> wrote:
>
>> I actually just followed some examples from Om. We have our element as
>>the
>> root of a component which would be the <svg>. This is positioned and so
>> anything drawn in it would start a (0,0). So to me, this makes sense for
>> how it is being done at the moment.
>>
>> ‹peter
>>
>> On 7/26/16, 3:52 PM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> Internally, it¹s always setting it to 0,0. It looks to me like some
>>> renderers might be doing some relative positioning, but I did not study
>>> them well enough to figure it out.
>>>
>>> I think it was in charts, so Peter should probably have a better idea.
>>>
>>> On Jul 26, 2016, at 10:41 PM, Alex Harui <ah...@adobe.com> wrote:
>>>
>>>>
>>>>
>>>> On 7/26/16, 11:47 AM, "Harbs" <ha...@gmail.com> wrote:
>>>>
>>>>> I agree there should be a Group object.
>>>>>
>>>>> The problem is that the way the classes are currently constructed is
>>>>> that
>>>>> 100 pixel ³Rect" positioned at 100,100 actually contains the
>>>>>following
>>>>> markup: <svg x=³100² y=³100"><rect x=³0² y=³0² width=³100²
>>>>> height=³100²/></svg>
>>>>
>>>> Are you saying that code is doing relative positioning re-calculation?
>>>> I
>>>> would wonder why it does that. Otherwise, a more straightforward
>>>> mapping
>>>> would make sense.
>>>>
>>>> -Alex
>>>>
>>>
>>
>
Re: Changed svg namespace
Posted by Harbs <ha...@gmail.com>.
Well, the whole drawRect() method seemed redundant to me along with the need to specify the width and height. I tried to remove it and move the logic to the draw() method (sans the width and height, and I ran into the following code in DecrementButtonView: _backRect.drawRect(0, 0, host.width, host.height); I was assuming that there’s a reason the host width and height is being specified instead of the _backRect ones.
I also have no idea what this was about: resize(x, y, _rect['getBBox']());
If this can all be simplified, I’d be happy to do so, but I thought there’s things going on here that I don’t completely understand.
I’m not understanding why a Rect needs to wrap the svg. Why can’t it just be a pure rect element and be required to be added to an svg or g element?
On Jul 26, 2016, at 11:55 PM, Peter Ent <pe...@adobe.com> wrote:
> I actually just followed some examples from Om. We have our element as the
> root of a component which would be the <svg>. This is positioned and so
> anything drawn in it would start a (0,0). So to me, this makes sense for
> how it is being done at the moment.
>
> ‹peter
>
> On 7/26/16, 3:52 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> Internally, it¹s always setting it to 0,0. It looks to me like some
>> renderers might be doing some relative positioning, but I did not study
>> them well enough to figure it out.
>>
>> I think it was in charts, so Peter should probably have a better idea.
>>
>> On Jul 26, 2016, at 10:41 PM, Alex Harui <ah...@adobe.com> wrote:
>>
>>>
>>>
>>> On 7/26/16, 11:47 AM, "Harbs" <ha...@gmail.com> wrote:
>>>
>>>> I agree there should be a Group object.
>>>>
>>>> The problem is that the way the classes are currently constructed is
>>>> that
>>>> 100 pixel ³Rect" positioned at 100,100 actually contains the following
>>>> markup: <svg x=³100² y=³100"><rect x=³0² y=³0² width=³100²
>>>> height=³100²/></svg>
>>>
>>> Are you saying that code is doing relative positioning re-calculation?
>>> I
>>> would wonder why it does that. Otherwise, a more straightforward
>>> mapping
>>> would make sense.
>>>
>>> -Alex
>>>
>>
>
Re: Changed svg namespace
Posted by Peter Ent <pe...@adobe.com>.
I actually just followed some examples from Om. We have our element as the
root of a component which would be the <svg>. This is positioned and so
anything drawn in it would start a (0,0). So to me, this makes sense for
how it is being done at the moment.
‹peter
On 7/26/16, 3:52 PM, "Harbs" <ha...@gmail.com> wrote:
>Internally, it¹s always setting it to 0,0. It looks to me like some
>renderers might be doing some relative positioning, but I did not study
>them well enough to figure it out.
>
>I think it was in charts, so Peter should probably have a better idea.
>
>On Jul 26, 2016, at 10:41 PM, Alex Harui <ah...@adobe.com> wrote:
>
>>
>>
>> On 7/26/16, 11:47 AM, "Harbs" <ha...@gmail.com> wrote:
>>
>>> I agree there should be a Group object.
>>>
>>> The problem is that the way the classes are currently constructed is
>>>that
>>> 100 pixel ³Rect" positioned at 100,100 actually contains the following
>>> markup: <svg x=³100² y=³100"><rect x=³0² y=³0² width=³100²
>>> height=³100²/></svg>
>>
>> Are you saying that code is doing relative positioning re-calculation?
>>I
>> would wonder why it does that. Otherwise, a more straightforward
>>mapping
>> would make sense.
>>
>> -Alex
>>
>
Re: Changed svg namespace
Posted by Harbs <ha...@gmail.com>.
Internally, it’s always setting it to 0,0. It looks to me like some renderers might be doing some relative positioning, but I did not study them well enough to figure it out.
I think it was in charts, so Peter should probably have a better idea.
On Jul 26, 2016, at 10:41 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/26/16, 11:47 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> I agree there should be a Group object.
>>
>> The problem is that the way the classes are currently constructed is that
>> 100 pixel “Rect" positioned at 100,100 actually contains the following
>> markup: <svg x=“100” y=“100"><rect x=“0” y=“0” width=“100”
>> height=“100”/></svg>
>
> Are you saying that code is doing relative positioning re-calculation? I
> would wonder why it does that. Otherwise, a more straightforward mapping
> would make sense.
>
> -Alex
>
Re: Changed svg namespace
Posted by Alex Harui <ah...@adobe.com>.
On 7/26/16, 11:47 AM, "Harbs" <ha...@gmail.com> wrote:
>I agree there should be a Group object.
>
>The problem is that the way the classes are currently constructed is that
>100 pixel “Rect" positioned at 100,100 actually contains the following
>markup: <svg x=“100” y=“100"><rect x=“0” y=“0” width=“100”
>height=“100”/></svg>
Are you saying that code is doing relative positioning re-calculation? I
would wonder why it does that. Otherwise, a more straightforward mapping
would make sense.
-Alex
Re: Changed svg namespace
Posted by Harbs <ha...@gmail.com>.
I agree there should be a Group object.
The problem is that the way the classes are currently constructed is that 100 pixel “Rect" positioned at 100,100 actually contains the following markup: <svg x=“100” y=“100"><rect x=“0” y=“0” width=“100” height=“100”/></svg>
I think the reason it was done this way was to make it possible to add Rects (and similar) directly to HTML elements.
I suppose we could change the way the classes are setup (and drawn) so that <rect> <circle> and the like could only be added to elements which legally can contain them (such as <svg> and <g>).
On Jul 26, 2016, at 8:38 PM, Alex Harui <ah...@adobe.com> wrote:
>
>
> On 7/26/16, 8:19 AM, "Harbs" <ha...@gmail.com> wrote:
>
>> Both.
>>
>> In SVG we're actually struggling with the same (or rather similar) issue.
>>
>> There’s a big difference between:
>> <div><svg><rect/></svg><svg><circle/></svg></div>
>>
>> and
>> <div><svg><g><rect/><circle/></g></svg></div>
>>
>> Each svg has its own coordinate space, and svg elements cannot have
>> transform properties. This is proving to be quite difficult in terms of
>> transformations.
>>
>> Ideally, it should be easy to pick whether you want to wrap each shape in
>> its own SVG element or have them all in the same svg element (or g
>> element). Currently GraphicShape draws each shape with its own svg
>> wrapper. CompoundShape, on the other hand, draws separate objects within
>> a single svg element. GraphicContainer takes svg-type elements as
>> children, but does not care exactly which type.
>>
>> I think there should also be a GraphicGroup object which would be a g
>> element and take children.
>>
>> I’m struggling with how to specify whether svg element have the svg
>> wrapper and not. (Ideas welcome!)
>
> IMO, I suspect there exist SVG snippets in the world that folks might want
> to repurpose into their FlexJS apps. Having a simple 1:1 mapping between
> tags is probably the best strategy. Are folks worried about the overhead
> of that verbosity? IMO, it is always possible to provide aggregations,
> but aggregations make assumptions and often someone will come back and ask
> for the low-level.
>
> For example, in Flex Spark (and FlexJS) specifying a layout for a
> container takes 3 lines:
>
> <Container>
> <layout>
> <VerticalLayout />
> </layout>
> </Container>
>
> In Flex MX, it is one line:
>
> <Container layout="Vertical" />
>
> The problem is that you can't specify other properties on the
> VerticalLayout in MX, and Horizontal and Absolute layout are baked into
> the MX container and are linked into your code, and you can't add new
> layouts.
>
> So for graphics, if I understand the issue, why not add a <g> or <Group>
> tag and make folks use it where they need it?
>
> My 2 cents,
> -Alex
Re: Changed svg namespace
Posted by Alex Harui <ah...@adobe.com>.
On 7/26/16, 8:19 AM, "Harbs" <ha...@gmail.com> wrote:
>Both.
>
>In SVG we're actually struggling with the same (or rather similar) issue.
>
>There’s a big difference between:
><div><svg><rect/></svg><svg><circle/></svg></div>
>
>and
><div><svg><g><rect/><circle/></g></svg></div>
>
>Each svg has its own coordinate space, and svg elements cannot have
>transform properties. This is proving to be quite difficult in terms of
>transformations.
>
>Ideally, it should be easy to pick whether you want to wrap each shape in
>its own SVG element or have them all in the same svg element (or g
>element). Currently GraphicShape draws each shape with its own svg
>wrapper. CompoundShape, on the other hand, draws separate objects within
>a single svg element. GraphicContainer takes svg-type elements as
>children, but does not care exactly which type.
>
>I think there should also be a GraphicGroup object which would be a g
>element and take children.
>
>I’m struggling with how to specify whether svg element have the svg
>wrapper and not. (Ideas welcome!)
IMO, I suspect there exist SVG snippets in the world that folks might want
to repurpose into their FlexJS apps. Having a simple 1:1 mapping between
tags is probably the best strategy. Are folks worried about the overhead
of that verbosity? IMO, it is always possible to provide aggregations,
but aggregations make assumptions and often someone will come back and ask
for the low-level.
For example, in Flex Spark (and FlexJS) specifying a layout for a
container takes 3 lines:
<Container>
<layout>
<VerticalLayout />
</layout>
</Container>
In Flex MX, it is one line:
<Container layout="Vertical" />
The problem is that you can't specify other properties on the
VerticalLayout in MX, and Horizontal and Absolute layout are baked into
the MX container and are linked into your code, and you can't add new
layouts.
So for graphics, if I understand the issue, why not add a <g> or <Group>
tag and make folks use it where they need it?
My 2 cents,
-Alex
Re: Changed svg namespace
Posted by Harbs <ha...@gmail.com>.
Both.
In SVG we're actually struggling with the same (or rather similar) issue.
There’s a big difference between:
<div><svg><rect/></svg><svg><circle/></svg></div>
and
<div><svg><g><rect/><circle/></g></svg></div>
Each svg has its own coordinate space, and svg elements cannot have transform properties. This is proving to be quite difficult in terms of transformations.
Ideally, it should be easy to pick whether you want to wrap each shape in its own SVG element or have them all in the same svg element (or g element). Currently GraphicShape draws each shape with its own svg wrapper. CompoundShape, on the other hand, draws separate objects within a single svg element. GraphicContainer takes svg-type elements as children, but does not care exactly which type.
I think there should also be a GraphicGroup object which would be a g element and take children.
I’m struggling with how to specify whether svg element have the svg wrapper and not. (Ideas welcome!)
These concepts apply pretty well to canvas too. I’d imagine you sometimes want a lot of separate canvases, and sometime you’d want a “display list” on a single canvas. If each object would have its own canvas, they would be separate DOM elements, but if it’s a “virtual” display list, there would be a single canvas element visible on the DOM. Both are valid use cases, and both should be possible.
On Jul 26, 2016, at 5:28 PM, Peter Ent <pe...@adobe.com> wrote:
> Hi,
>
> For my own education, I just wanted to get some clarification. With
> regards to SVG, when you use it, it looks something like this in the HTML
> file:
> <svg style="Š">
> <rect style="Š" />
> <rect style="Š" />
> </svg>
>
> With Canvas, there aren't any graphic elements, you just have <canvas />
> and then JS code to draw the rects (or whatever).
>
> Were you thinking we would be able to substitute Canvas for SVG? In other
> words, in the Charts, I used SVG in the JS version of the BoxItemRenderer.
> Is it your intent that you could write a BoxItemRenderer that used Canvas
> instead, for each renderer? The JS would be something like a
> <div><canvas/></div> (the SVG version is <div><svg><rect /></svg></div> so
> the mouse tracking would be on the outer <div>.
>
> Or were you thinking that if you wanted to use Canvas for the Charts,
> you'd work at a higher level and have a <canvas> per chart and inside of
> that the renderers would simply use Canvas drawing to make the bars,
> columns, axes, etc.?
>
> I just wanted to see where you were envisioning this going. I think both
> approaches would work.
>
> ‹peter
>
> On 7/25/16, 5:13 PM, "Harbs" <ha...@gmail.com> wrote:
>
>> FYI:
>>
>> I just added a bunch of drawing APIs for SVG which should work for canvas
>> as well when we have it.
>>
>> It should be possible to efficiently construct paths with can be used for
>> all outputs. I still need to do some testing and add simple rounded rects
>> and I need to add string decomposition for canvas, but it¹s pretty
>> complete. (Although the AS Docs could use some work.)
>>
>> The paths can be built implicitly using complex rounded rects or built
>> using the new PathBuilder class which wraps a suite of drawing commands
>> and spits them out as path strings. (Of course you can construct the
>> strings manually if you like, but that seems very error prone to me.)
>> Converting existing Flash drawing should be very straight-forward and it
>> maps naturally to HTML.
>>
>> That¹s it for todayŠ
>>
>> On Jul 25, 2016, at 1:54 PM, Harbs <ha...@gmail.com> wrote:
>>
>>> I think I missed the correct config file the first time around, and I
>>> fixed this.
>>>
>>> The change is that SVG components such as Rect, Circle, etc, should now
>>> need the library://ns.apache.org/flexjs/svg namespace in MXML instead of
>>> library://ns.apache.org/flexjs/basic.
>>>
>>> So to use vsg compenents, you¹d need to do this:
>>> xmlns:svg="library://ns.apache.org/flexjs/svg²
>>>
>>> and <svg:Circle/>
>>>
>>> (eventually, I expect we¹ll have <canvas:Circle/> as well)
>>>
>>> On Jul 25, 2016, at 1:36 PM, Christofer Dutz
>>> <ch...@c-ware.de> wrote:
>>>
>>>> Hi Harbs,
>>>>
>>>>
>>>> it would have been easier to check, if all Is ok, if you had described
>>>> what you changed. From a review of the commit it seems you moved some
>>>> parts to dedicated svg packages, created a new namespace file to
>>>> reference the svg elements and removed the old ones from the original
>>>> ones. Am I correct?
>>>>
>>>>
>>>> I just did a quick check ... I was still able to build everything
>>>> (including examples) with Maven, so in general it should be ok ... but
>>>> I did notice, that you only updated the manifest info in the
>>>> flex-config.xml template in the maven distribution module, but not to
>>>> any of the configs in the normal framework directory or any of the
>>>> other templates in the distribution directory. I Fixed this for the
>>>> maven distribution and will commit that as soon as I have finished my
>>>> current work on bundling AIR in the directory distribution, but you'll
>>>> have to finish that in the framework directory the Ant build uses.
>>>>
>>>>
>>>> Chris
>>>>
>>>> ________________________________
>>>> Von: Harbs <ha...@gmail.com>
>>>> Gesendet: Montag, 25. Juli 2016 12:12:15
>>>> An: dev
>>>> Betreff: Changed svg namespace
>>>>
>>>> I just changed the svg namespace in the Graphics package. I¹m not 100%
>>>> sure I did it right ‹ especially with the maven build.
>>>>
>>>> I hope I did not mess up the next build, but we¹ll find out soon. ;-)
>>>>
>>>> If someone could double-check what I did (both on the ant side and the
>>>> maven side), that might catch my errors soonerŠ
>>>>
>>>> Thanks,
>>>> Harbs
>>>
>>
>
Re: Changed svg namespace
Posted by Peter Ent <pe...@adobe.com>.
Hi,
For my own education, I just wanted to get some clarification. With
regards to SVG, when you use it, it looks something like this in the HTML
file:
<svg style="Š">
<rect style="Š" />
<rect style="Š" />
</svg>
With Canvas, there aren't any graphic elements, you just have <canvas />
and then JS code to draw the rects (or whatever).
Were you thinking we would be able to substitute Canvas for SVG? In other
words, in the Charts, I used SVG in the JS version of the BoxItemRenderer.
Is it your intent that you could write a BoxItemRenderer that used Canvas
instead, for each renderer? The JS would be something like a
<div><canvas/></div> (the SVG version is <div><svg><rect /></svg></div> so
the mouse tracking would be on the outer <div>.
Or were you thinking that if you wanted to use Canvas for the Charts,
you'd work at a higher level and have a <canvas> per chart and inside of
that the renderers would simply use Canvas drawing to make the bars,
columns, axes, etc.?
I just wanted to see where you were envisioning this going. I think both
approaches would work.
‹peter
On 7/25/16, 5:13 PM, "Harbs" <ha...@gmail.com> wrote:
>FYI:
>
>I just added a bunch of drawing APIs for SVG which should work for canvas
>as well when we have it.
>
>It should be possible to efficiently construct paths with can be used for
>all outputs. I still need to do some testing and add simple rounded rects
>and I need to add string decomposition for canvas, but it¹s pretty
>complete. (Although the AS Docs could use some work.)
>
>The paths can be built implicitly using complex rounded rects or built
>using the new PathBuilder class which wraps a suite of drawing commands
>and spits them out as path strings. (Of course you can construct the
>strings manually if you like, but that seems very error prone to me.)
>Converting existing Flash drawing should be very straight-forward and it
>maps naturally to HTML.
>
>That¹s it for todayŠ
>
>On Jul 25, 2016, at 1:54 PM, Harbs <ha...@gmail.com> wrote:
>
>> I think I missed the correct config file the first time around, and I
>>fixed this.
>>
>> The change is that SVG components such as Rect, Circle, etc, should now
>>need the library://ns.apache.org/flexjs/svg namespace in MXML instead of
>>library://ns.apache.org/flexjs/basic.
>>
>> So to use vsg compenents, you¹d need to do this:
>> xmlns:svg="library://ns.apache.org/flexjs/svg²
>>
>> and <svg:Circle/>
>>
>> (eventually, I expect we¹ll have <canvas:Circle/> as well)
>>
>> On Jul 25, 2016, at 1:36 PM, Christofer Dutz
>><ch...@c-ware.de> wrote:
>>
>>> Hi Harbs,
>>>
>>>
>>> it would have been easier to check, if all Is ok, if you had described
>>>what you changed. From a review of the commit it seems you moved some
>>>parts to dedicated svg packages, created a new namespace file to
>>>reference the svg elements and removed the old ones from the original
>>>ones. Am I correct?
>>>
>>>
>>> I just did a quick check ... I was still able to build everything
>>>(including examples) with Maven, so in general it should be ok ... but
>>>I did notice, that you only updated the manifest info in the
>>>flex-config.xml template in the maven distribution module, but not to
>>>any of the configs in the normal framework directory or any of the
>>>other templates in the distribution directory. I Fixed this for the
>>>maven distribution and will commit that as soon as I have finished my
>>>current work on bundling AIR in the directory distribution, but you'll
>>>have to finish that in the framework directory the Ant build uses.
>>>
>>>
>>> Chris
>>>
>>> ________________________________
>>> Von: Harbs <ha...@gmail.com>
>>> Gesendet: Montag, 25. Juli 2016 12:12:15
>>> An: dev
>>> Betreff: Changed svg namespace
>>>
>>> I just changed the svg namespace in the Graphics package. I¹m not 100%
>>>sure I did it right ‹ especially with the maven build.
>>>
>>> I hope I did not mess up the next build, but we¹ll find out soon. ;-)
>>>
>>> If someone could double-check what I did (both on the ant side and the
>>>maven side), that might catch my errors soonerŠ
>>>
>>> Thanks,
>>> Harbs
>>
>
Re: Changed svg namespace
Posted by Harbs <ha...@gmail.com>.
FYI:
I just added a bunch of drawing APIs for SVG which should work for canvas as well when we have it.
It should be possible to efficiently construct paths with can be used for all outputs. I still need to do some testing and add simple rounded rects and I need to add string decomposition for canvas, but it’s pretty complete. (Although the AS Docs could use some work.)
The paths can be built implicitly using complex rounded rects or built using the new PathBuilder class which wraps a suite of drawing commands and spits them out as path strings. (Of course you can construct the strings manually if you like, but that seems very error prone to me.) Converting existing Flash drawing should be very straight-forward and it maps naturally to HTML.
That’s it for today…
On Jul 25, 2016, at 1:54 PM, Harbs <ha...@gmail.com> wrote:
> I think I missed the correct config file the first time around, and I fixed this.
>
> The change is that SVG components such as Rect, Circle, etc, should now need the library://ns.apache.org/flexjs/svg namespace in MXML instead of library://ns.apache.org/flexjs/basic.
>
> So to use vsg compenents, you’d need to do this:
> xmlns:svg="library://ns.apache.org/flexjs/svg”
>
> and <svg:Circle/>
>
> (eventually, I expect we’ll have <canvas:Circle/> as well)
>
> On Jul 25, 2016, at 1:36 PM, Christofer Dutz <ch...@c-ware.de> wrote:
>
>> Hi Harbs,
>>
>>
>> it would have been easier to check, if all Is ok, if you had described what you changed. From a review of the commit it seems you moved some parts to dedicated svg packages, created a new namespace file to reference the svg elements and removed the old ones from the original ones. Am I correct?
>>
>>
>> I just did a quick check ... I was still able to build everything (including examples) with Maven, so in general it should be ok ... but I did notice, that you only updated the manifest info in the flex-config.xml template in the maven distribution module, but not to any of the configs in the normal framework directory or any of the other templates in the distribution directory. I Fixed this for the maven distribution and will commit that as soon as I have finished my current work on bundling AIR in the directory distribution, but you'll have to finish that in the framework directory the Ant build uses.
>>
>>
>> Chris
>>
>> ________________________________
>> Von: Harbs <ha...@gmail.com>
>> Gesendet: Montag, 25. Juli 2016 12:12:15
>> An: dev
>> Betreff: Changed svg namespace
>>
>> I just changed the svg namespace in the Graphics package. I’m not 100% sure I did it right — especially with the maven build.
>>
>> I hope I did not mess up the next build, but we’ll find out soon. ;-)
>>
>> If someone could double-check what I did (both on the ant side and the maven side), that might catch my errors sooner…
>>
>> Thanks,
>> Harbs
>
Re: Changed svg namespace
Posted by Harbs <ha...@gmail.com>.
I think I missed the correct config file the first time around, and I fixed this.
The change is that SVG components such as Rect, Circle, etc, should now need the library://ns.apache.org/flexjs/svg namespace in MXML instead of library://ns.apache.org/flexjs/basic.
So to use vsg compenents, you’d need to do this:
xmlns:svg="library://ns.apache.org/flexjs/svg”
and <svg:Circle/>
(eventually, I expect we’ll have <canvas:Circle/> as well)
On Jul 25, 2016, at 1:36 PM, Christofer Dutz <ch...@c-ware.de> wrote:
> Hi Harbs,
>
>
> it would have been easier to check, if all Is ok, if you had described what you changed. From a review of the commit it seems you moved some parts to dedicated svg packages, created a new namespace file to reference the svg elements and removed the old ones from the original ones. Am I correct?
>
>
> I just did a quick check ... I was still able to build everything (including examples) with Maven, so in general it should be ok ... but I did notice, that you only updated the manifest info in the flex-config.xml template in the maven distribution module, but not to any of the configs in the normal framework directory or any of the other templates in the distribution directory. I Fixed this for the maven distribution and will commit that as soon as I have finished my current work on bundling AIR in the directory distribution, but you'll have to finish that in the framework directory the Ant build uses.
>
>
> Chris
>
> ________________________________
> Von: Harbs <ha...@gmail.com>
> Gesendet: Montag, 25. Juli 2016 12:12:15
> An: dev
> Betreff: Changed svg namespace
>
> I just changed the svg namespace in the Graphics package. I’m not 100% sure I did it right — especially with the maven build.
>
> I hope I did not mess up the next build, but we’ll find out soon. ;-)
>
> If someone could double-check what I did (both on the ant side and the maven side), that might catch my errors sooner…
>
> Thanks,
> Harbs
AW: Changed svg namespace
Posted by Christofer Dutz <ch...@c-ware.de>.
Hi Harbs,
it would have been easier to check, if all Is ok, if you had described what you changed. From a review of the commit it seems you moved some parts to dedicated svg packages, created a new namespace file to reference the svg elements and removed the old ones from the original ones. Am I correct?
I just did a quick check ... I was still able to build everything (including examples) with Maven, so in general it should be ok ... but I did notice, that you only updated the manifest info in the flex-config.xml template in the maven distribution module, but not to any of the configs in the normal framework directory or any of the other templates in the distribution directory. I Fixed this for the maven distribution and will commit that as soon as I have finished my current work on bundling AIR in the directory distribution, but you'll have to finish that in the framework directory the Ant build uses.
Chris
________________________________
Von: Harbs <ha...@gmail.com>
Gesendet: Montag, 25. Juli 2016 12:12:15
An: dev
Betreff: Changed svg namespace
I just changed the svg namespace in the Graphics package. I’m not 100% sure I did it right — especially with the maven build.
I hope I did not mess up the next build, but we’ll find out soon. ;-)
If someone could double-check what I did (both on the ant side and the maven side), that might catch my errors sooner…
Thanks,
Harbs