[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] Draft Proposals
Hi Benoit, I agree with the grgroup approach since it appears to be more straightforward. I also agree that your description thoroughly covers our discussion in Houston. I am though not sure if I fully understood the interactive behavior of the grgroup you are proposing. I believe Lofton pointed into this direction as well. When you write: " 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'" does this mean that grgroup inherits interactivity like it inherits the visibility attribute? This would certainly make sense to me and it leaves no ambiguities regarding a viewer implementation. In addition: " 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." How does layer fit in here? It is not mentioned in the paragraphs above. Thanks and regards Ulrich -----Original Message----- From: Benoit Bezaire [mailto:benoit@itedo.com] Sent: Montag, 15. November 2004 20:18 To: CGM Open WebCGM TC Subject: [cgmo-webcgm] Draft Proposals 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]