Copy/pasting from several posts...
On 7/27/16, 2:09 AM, "Harbs" 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
>make
suming wrapping in doesn't somehow make it a
> candidate for a different API.
>
>
>
>
>
> --
> View this message in context:
> http://apache-flex-development.247.n4.nabble.com/Changed-svg-namespace-tp54150p54222.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
it a
candidate for a different API.
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/Changed-svg-namespace-tp54150p54222.html
Sent from the Apache Flex Development mailing list archive at Nabble.com.
t:
> http://apache-flex-development.247.n4.nabble.com/Changed-svg-namespace-tp54150p54220.html
> Sent from the Apache Flex Development mailing list archive at Nabble.com.
also works around the mxml compile error question.
The resultant DOM structure becomes less transparent (Rect could map to
either or ), but I don't think that would confuse
me if I was inspecting the DOM.
--
View this message in context:
http://apache-flex-development.247.n4.nabble.com/C
I prefer to make things a little more explicit:
would be
would be
would be
would be
would do drawRect() on the containing canvas
would be and drawRect()
would be drawCircle() on the containing canvas
would be and drawCircle()
I’m not sold on the names. Maybe something like WrappedR
On 7/26/16, 5:02 PM, "omup...@gmail.com on behalf of OmPrakash Muppirala"
wrote:
>On Jul 26, 2016 11:47 AM, "Harbs" 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 act
On Jul 26, 2016 11:47 AM, "Harbs" 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:
>
> I think the reason it was done this way was to make
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,
DecrementButtonV
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.drawRe
I actually just followed some examples from Om. We have our element as the
root of a component which would be the . 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" 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 wrote:
On 7/26/16, 11:47 AM, "Harbs" 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: height=“100”/>
Are you saying that code is doing relative
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:
I think the reason it was done this way was to make it possible to add Rects
(and similar) directly t
On 7/26/16, 8:19 AM, "Harbs" wrote:
>Both.
>
>In SVG we're actually struggling with the same (or rather similar) issue.
>
>There’s a big difference between:
>
>
>and
>
>
>Each svg has its own coordinate space, and svg elements cannot have
>transform properties. This is proving to be quite diff
hing
>>>> (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 n
odule, 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 t
tion, but you'll have to finish that in the framework directory the
>> Ant build uses.
>>
>>
>> Chris
>>
>>
>> Von: Harbs
>> Gesendet: Montag, 25. Juli 2016 12:12:15
>> An: dev
>> Betreff: Changed
uses.
>
>
> Chris
>
>
> Von: Harbs
> 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 — es
n the framework directory the Ant build uses.
Chris
Von: Harbs
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 buil
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 catc
21 matches
Mail list logo
