[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re[2]: [cgmo-webcgm] Draft Proposals
Hi, I think there are two main problems we are trying to solve here: 1) maintaining structured documents when CGM files are exchanged between authoring tools. 2) writing CGM files that doesn't flash all the time because ATA uses refloc. The famous 'Ctrl+G' function that is found in all popular authoring tools (Illustrator, CorelDraw etc...) should be mapped to what in WebCGM? Dieter's proposal from Feb 2002 was 'grgroup'. In Houston we talked about 'grobject' + static="true" (or something similar). I'm now proposing a different 'grgroup' that what Dieter proposed 2 years ago. ATA has the 'behavior' attribute, so probably 'grobject' + behavior="static", unfortunately that's underspecified (what happens if static grobject is within a non-static grobject?) Forrest seems to be proposing 'grobject' + interactivity="inherit". Nobody in Houston proposed to add the 'behavior' attribute to WebCGM, why? I'll presume there are problems with it. It would be nice if someone could enumerate them so that we make sure we're not making the same mistakes _again_. So let's rule out 'behavior' since nobody proposed it. We are left with: A) 'grgroup'. B) 'grobject' + static. C) 'grobject' + interactivity="inherit". For the second problem, ATA would probably output; according to me A) current 'grobject'; in Houston we were talking about B) 'grobject' + interactivity="on" and Forrest is also currently proposing C) 'grobject' + interactivity="on". Forrest, your current proposal seems underspecified; ex: what should happen if a 'grobject' has a screentip but interactivity="inherit"? what is the event target if I click on a 'grobject' with interactivity="inherit"; the current 'grobject' is the event target or an ancestor with interactivity="on" the event target? I have a feeling that if you improve your proposal, we'll end up with what we had in Houston with the exception that 'static' == interactivity="inherit". I've tried to address all the technical points that were mentioned in Houston in this latest proposal. I'd like to know if my proposal is technically flawed? or if people think that 'grobject' + something is better; I'd like to know why? Cheers, -- Benoit mailto:benoit@itedo.com Monday, November 15, 2004, 3:11:49 PM, Forrest wrote: FC> All, FC> I have another proposal that might solve the special behavior issues FC> with the static attribute and not require a new grgroup object. We FC> we change the values for the interactive attribute of a grobject to FC> "on", "off" or "inherit". FC> If the interactive attribute attribute was set to inherit, the grobject FC> would always inherit its interactive statue from its ancestors. FC> This would allow application to contain generic groups that would FC> not have any interactivity unless it was a member of a interactive FC> group. You could also specify that if the attribute was set to inherit, FC> it could not be changed by the DOM of the companion file. FC> Forrest FC> At 01:18 PM 11/15/2004, Benoit Bezaire wrote: >>Hi all, >> >>Here's a writeup on some of the things we talked about in Houston. >>This is a draft proposal so please send feedback. If time >>permitting, we can talk about during Tuesday's telecon. >> >>Regarding the 'grgroup' or 'grobject' + static proposal... in Houston >>we mostly talked about 'grobject' + static, but my personal opinion is >>that 'grgroup' is cleaner. If the group disagrees with me, I can >>certainly change the wording and go with the 'grobject' + static >>approach instead; I don't have a strong opinion on this. >> >>Cheers, >> >> >> ------------------------------------------------------------------- >> >> *** 'interactivity' attribute *** >> Value: on | off >> Initial: on >> Applies to: 'layer', 'grobject', 'para' and 'subpara'. >> Inherited: yes >> >> The 'interactivity' attribute indicates if an object may receive >> mouse events. When the 'interactivity' of an object is set to off, >> events for this object are disabled. This has the effect of >> disabling event handlers, cursor changes, highlighting, screentip >> and hyperlinking for the given node and its descendant. An object >> that is the target of a link always responds to highlighting, >> regardless of its 'interactivity' attribute value. >> >> >> ------------------------------------------------------------------- >> >> *** 'visibility' attribute *** >> Value: on | off >> Initial: on >> Applies to: 'layer', 'grobject', 'para', 'subpara'. >> Inherited: yes >> >> The 'visibility' attribute indicates if an object is visible or not. >> A non-visible object behaves like a non-interactive object (i.e., >> it cannot be clicked or highlighted). This does not imply that the >> 'interactivity' attribute is changed to off; but simply that the >> user agent must not respond to mouse events. >> >> >> -------------------------------------------------------------------- >> >> *** A new 'grgroup' definition *** >> The application structure of type 'grgroup' is being proposed for >> WebCGM 2.0. The addition of the 'grgroup' APS (or the existing >> 'grobject) + static attribute) is needed to enhance interchange >> of WebCGM files between authoring tools. The 'grobject' APS >> unfortunately has different implications (interactiveness) in >> various CGM profiles and is therefore not the ideal candidate for >> grouping graphical primitives. The 'grgroup' APS is being proposed as >> a mechanism of choice for grouping graphical primitives in authoring >> tools. Grouping various objects is a frequent user operations in >> all commonly used authoring tools (CGM based or not). By >> standardizing a grouping method, authoring tools will be able to >> more easily maintain the file structure intended by the user. >> >> Apart from the APS ID, a 'grgroup' cannot have any other attributes. >> The 'visibility' attributes is also excluded. >> >> The application structure 'grgroup' is meant to group basic >> graphical primitives; a frequent user operation. The content of a >> 'grgroup' is however, not limited to graphical primitives. The >> allowed content of a 'grobject' is the same as the one allowed for >> the 'grobject' application structure. >> >> Like the other application structure types, the 'grgroup' supports >> inheritance (i.e., it is possible to make a 'grgroup' non-visible by >> inserting it within an object which support the 'visibility' >> attribute). >> >> Unlike the application structures, the 'grgroup' is not interactive. >> It does not receive mouse events like other application structures. >> The content of a 'grgroup' can however be interactive if that >> content is a direct child of a 'grobject', 'para' or 'subpara'. >> Additionally, if a mouse event is triggered on the geometry of a >> 'grgroup', an ancestor node may respond to the event if that >> ancestor node is of type 'grobject', 'para' and 'subpara'. See the >> Event interface for more information regarding mouse events. >> >> >> --------------------------------------------------------------------- >> >> *** Event Interface (add this to the interface section) *** >> There exists three levels of interactivity in WebCGM: >> - User-initiated actions such as a mouse click can be captured by >> the host environment and execute scripts. >> - The user can initiate hyperlinks to Web pages or other WebCGM >> illustrations. >> - User agent, users are able to zoom into and pan around WebCGM >> content. >> >> When a mouse event occurs, the WebCGM user agent determines the >> target element of a mouse event. The target element is the topmost >> graphics element whose relevant graphical content is under the >> mouse at the time of the event. An application structure of type >> 'grgroup' cannot be a target of a mouse event. Instead, if the >> mouse pointer was over a 'grgroup' when the event occurred; its >> closest ancestor element of type 'layer', 'grobject', 'para' or >> 'subpara' will be designated as the target element. When an element >> is not displayed (i.e., 'visibility' attribute is set to off) or >> made non-interactive (i.e., 'interactivity' attribute is set to >> off), that element cannot be the target of mouse events. >> >> The event is either initially dispatched to the target element, to >> the Picture element or not dispatched depending on the following: >> >> -If there are no graphics elements whose relevant graphics content is >> under the mouse (i.e., there is no target element), the event is not >> dispatched. >> -Otherwise, there is a target element. If there is an event handler >> at the Picture level with event capturing for the given event, then >> the event is dispatched to the Picture. >> -Otherwise, if the target element has an appropriate event handler >> for the given event, the event is dispatched to the target element. >> -Otherwise, the Picture element is checked to see if it has an >> appropriate event handler. The event is dispatched to the Picture if >> one is found. >> -Otherwise, the event is discarded. >> >> The processing order for mouse events is as follows: >> >> -Events handlers assigned to a WebCGMPicture get the event first via >> the potential event bubbling. If none of the activation event >> handlers take an explicit action (by invoking the preventDefault() >> WebCGM DOM method) to prevent further processing of the given event, >> then the event is passed on for: >> -Cursor change, screentip and hyperlink processing. If a hyperlink >> is invoked in response to a user interface event, the hyperlink >> typically will disable further activation event processing (e.g., >> hyperlink to another Web page). If link processing does not disable >> further processing of the given event, then the event is passed on >> for: >> -Document-wide event processing, such as user agent facilities to >> allow zooming and panning of a WebCGM document. >> >> >> --------------------------------------------------------------------- >> >> Regards, >> >>-- >> Benoit mailto:benoit@itedo.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]