[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior revert to full-picture view?
It does also apply in the following cases:
- changing the src parameter of the Metafile interface, e.g. cgmDoc.src = ""abc.cgm#somefragment"," if abc.cgm is already open
- using the #xcf(...) syntax in linkURIs inside the CGM, e.g. "abc.cgm#xcf(myxcf.xml)" or "#xcf(myxcf.xml)"
Hi Lofton,The last sentence here should be deleted probably. Somehow we need to change the behavior compared to WebCGM 1.0 to accomplish several things:
please find my comments inline.
- -----Original Message-----
- From: Lofton Henderson [mailto:lofton@rockynet.com]
- Sent: Tuesday, June 14, 2005 5:05 PM
- To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org
- Subject: RE: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior revert to full-picture view?
- At 11:22 AM 6/14/2005 +0200, =?us-ascii?Q?Dieter__Weidenbruck?= wrote:
- [...]
- you are right, and we should change the default.
- Actually, my preferred solution would be to clarify the _replace behavior: for a C2C link, that goes from one object in a picture to another object in the same picture, if the picBehavior is _replace (either by default or explicit setting), then the viewer SHALL NOT reload the picture, but rather shall preserve the existing view state and apply any new objBehaviors.
- [DW] Clarification is the better way.
- More below...
- The viewer shall replace the current picture by the designated picture in the same rectangular area in the same frame or window as the picture which refers to this target. This is the default behavior for CGM-to-CGM links.
- -----Original Message-----
- From: Lofton Henderson [mailto:lofton@rockynet.com]
- Sent: Friday, June 10, 2005 5:32 PM
- To: dieter@itedo.com; cgmo-webcgm@lists.oasis-open.org
- Subject: RE: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior revert to full-picture view?
- Disclaimer: I don't feel strongly about how we resolve the objBehavior issue, as long as: 1.) it's not broken, and 2.) the users are happy with it, and 3.) the users are happy with it. We will need to change existing 1.0 test cases (which test the old 3 behaviors), and implementors will have to implement the new 2.0 stuff (if we don't have 2 implementations, it gets tossed, at least in W3C context).
- New wrinkle: We have been ignoring picBehavior....
- If there is an explicit picBehavior, then 3.1.2.2 says that the picture is reloaded anyway. So the current view or objBehavior is wiped out. Let's look at some examples.
- Example 1: Clearly, _blank (new window) would do this.
- Example 2: Clearly any link from outside, e.g., from HTML, would contain the CGM filename and that would (I believe) lead to (re-)loading the CGM, even if it were the same CGM as the viewer previously loaded.
- Example 3: What about an intra-CGM link? I.e., myCGM.cgm is already loaded and viewed. myObj1 contains a 'linkuri' to myObj2, as follows: #pictseqno(1, _replace).objid(myObj2, highlight_move). Does 3.1.2.2 imply that the picture is reloaded? I believe it does imply that (without judging whether it should or not).
- Example 4: Like example 3, but: #objid(myObj2, highlight_move). What now? 3.1.2.2 says about _replace:
- The viewer shall replace the current picture by the designated picture in the same rectangular area in the same frame or window as the picture which refers to this target. This is the default behavior for CGM-to-CGM links.
Hi Lofton,
see my comments inline.
> -----Original Message-----
> From: Lofton Henderson [mailto:lofton@rockynet.com]
> Sent: Friday, June 10, 2005 12:15 AM
> To: cgmo-webcgm@lists.oasis-open.org
> Subject: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior
> revert to full-picture view?
>
>
> From Ben's comments and Dieter's comments:
> http://lists.oasis-open.org/archives/cgmo-webcgm/200504/msg00017.html
> http://lists.oasis-open.org/archives/cgmo-webcgm/200506/msg00021.html
>
> At 04:34 PM 4/21/2005 -0400, Benoit Bezaire wrote:
> > - When we say: The resulting view is a full-picture view, not a
> > zoomed view... Do we zoom out even if the target rectangle already
> > fits in the viewer's viewport?
>
> At 04:34 PM 4/21/2005 -0400, Dieter wrote:
> >3.1.2.4.3
> >The definition of highlight is in contradiction with the table in
> >3.1.2.4.1. The table suggests that highlighting does not cause
> navigation.
> >Suggestion: Delete "The resulting view is a full-picture view, not a
> >zoomed view."
>
> The present descriptions of 'highlight' object behavior says that it
> reverts to a full picture view. The table, on the other hand,
> says that it
> has no navigation effects. Dieter proposes that the table is
> correct, and
> the text is wrong.
>
> If Dieter's view is correct, then the set of object behaviors is
> broken --
> it has these two problems at least:
>
> i.) No way to get full-picture view. Once the view has changed from full
> picture, e.g., the user pans and zooms an initial full-picture view with
> the viewer controls, there is no object behavior that can get you
> back to a
> full picture view. (If all view changing is removed from 'highlight', a
> 'full' keyword is needed to fix this.)
Understood and agreed. In general navigation to a full view is always
possible by using the URL without any fragment, however, it is a good idea
to add a "full" keyword.
>
> ii.) The 'highlight' keyword is useless. When a program or an
> XCF issues a
> 'highlight' behavior, it has no way of knowing what is the present
> view. Another DOM or WebCGM or XCF transaction may have changed it. Or
> the user may have panned/zoomed the picture with viewer controls. It is
> unknowable, in general, whether the target to be highlighted is
> visible. Therefore, no one would risk using 'highlight' (or
> 'highlight_all'). Only 'move_highlight' or 'zoom_highlight' have any
> usefulness.
It is not useless in my eyes, it becomes much more powerful now. So far,
users rarely used this keyword because of the unwanted navigation effects.
Combinations with navigation are well defined now, so highlight is reserved
for the cases where the implementor well knows what he is doing.
>
> Alternative 1. no change, 'highlight' is a full-picture
> view. (Editorially fix any contradictions.)
> Alternative 2. Highlight does no navigation, leave the problems
> i. and ii.
> broken as described above.
> Alternative 3. Highlight does no navigation, remove 'highlight' from
> table, add 'full', 'full_highlight', and 'full_highlight_all' to
> table (12
> rows in the table.)
Suggestion:
Add alternative 4:
Alternative 4. Highlight does no navigation, add 'full', 'full_highlight',
and 'full_highlight_all'.
NOTE: combinations like 'full_highlight_zoom" etc are not needed of course,
so it is 3 new entries.
I vote for 4.
>
> (Alternative 4. Revert to WebCGM 1.0 definition.)
>
> RECOMMENDATION. Alternative 1.
>
> -Lofton.
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]