RE: [cgmo-webcgm] ISSUE: does the 'highlight' object behavior revert to full-picture view?

[Dieter Weidenbruck <dieter@itedo.com>]

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.
>
>
>