OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cgmo-webcgm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [cgmo-webcgm] Flow of electricity


I think we are on the same page... but I have yet to see any concrete
proposal. 

-----Original Message-----
From: Forrest Carpenter [mailto:forrest@sdicgm.com] 
Sent: Tuesday, October 02, 2007 2:00 PM
To: Bezaire, Benoit; 'WebCGM'
Subject: RE: [cgmo-webcgm] Flow of electricity

Benoit,

What Stuart achieved in a complex manner could easily be done if we
added style attributes to support defined line types and line type
initial offset.
Also I think what ever type of animation we decide on, it would not be
hand coded but generated in a CGM authoring tool. 

Regards,
Forrest

-----Original Message-----
From: Bezaire, Benoit [mailto:bbezaire@ptc.com]
Sent: Tuesday, October 02, 2007 9:50 AM
To: cgmo-webcgm@lists.oasis-open.org
Subject: RE: [cgmo-webcgm] Flow of electricity

Hi Stuart,

That's a nice little animation. Clever!

If I remember correctly, we do have a remove style... you have to do: 
setStyleProperty( prop, "inherit" );

I have a felling I'm not about to make any friends with what I'm about
to say; but I have to say it since I think it matters.

Although the result Stuart generated is good looking (which is a great
positive), I would not encourage users to do this. I would argue that it
takes too long to author such an animation. Equivalent results can be
achieve faster in other file formats.

If we want animations to be frequently used in CGM we need easier
methods than what is shown in this example (I'm mostly referring to the
flow aspect). The electrical path was broken down into multiple
fragments, then each were assigned a specific name/id. I would argue
that most revisions of this illustration breaks the animation.
Additionally, I suspect that customers wiring diagrams are 20x more
complex; thus, authoring animation must be much easier.

Attached is an example of what I mean (in SVG). Displayed are two (out
of many) ways of showing flow, both used at the same time. In this
example, if the wire (say during a revision) goes from a rectangle to a
some sort of polygon, or if the battery/switch are moved to a new
location... the animation still work.

Again, I'm not opposed to animation in CGM, but I very much favor a
declarative approach than a DOM approach.

Thoughts?

Benoit.

-----Original Message-----
From: Lofton Henderson [mailto:lofton@rockynet.com]
Sent: Monday, October 01, 2007 6:10 PM
To: Galt, Stuart A; cgmo-webcgm@lists.oasis-open.org
Subject: Re: [cgmo-webcgm] Flow of electricity

Stuart --

Good stuff!  Again, we should be looking to put your examples (and
anyone
else's) of 2.0 capabilities somewhere on the Web site.  So, aside from
technical (and 2.1 rqts questions), there is the Education/Outreach
question:  when and where can we put these up and direct people to them?

Technical questions...

At 01:46 PM 9/28/2007 -0700, Galt, Stuart A wrote:
>[...]
>As I start making more complex images/applications I am finding myself 
>wishing I had a either getStyleProperty() or removeStyleProperty()

Is the "get" an inquiry function?  Do you actually want both "get" and
"remove", or did you really mean "either...or"?

Do you propose that these be added to the 2.1 wish list?

>method
>(I realize that this is difficult to implement) and the ability to make

>several DOM changes without waiting for a redraw between each one.

I guess this has now been added to the 2.1 wish list.

-Lofton.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]