From vrml-ui-owner@vag.vrml.org Thu Mar 13 21:23:53 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id VAA08218; Thu, 13 Mar 1997 21:23:51 -0500 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by kether.vrml.org (8.7.5/1.0) with SMTP id CAA08628 for ; Fri, 14 Mar 1997 02:19:15 GMT Received: from cthulhu.engr.sgi.com (cthulhu.engr.sgi.com [192.26.80.2]) by sgi.sgi.com (950413.SGI.8.6.12/950213.SGI.AUTOCF) via ESMTP id SAA13050; Thu, 13 Mar 1997 18:20:15 -0800 Received: from uniblab.engr.sgi.com (uniblab.engr.sgi.com [198.29.108.116]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id SAA18577; Thu, 13 Mar 1997 18:20:13 -0800 Received: (from pauli@localhost) by uniblab.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id CAA04577; Fri, 14 Mar 1997 02:20:11 GMT From: "Paul Isaacs" Message-Id: <9703131820.ZM4575@uniblab.engr.sgi.com> Date: Thu, 13 Mar 1997 18:20:11 -0800 In-Reply-To: gseidman@zing.ncsl.nist.gov (Gregory Seidman) "Re: a proposal for a widget repository" (Mar 13, 5:31pm) References: <199703132231.RAA07365@zing.ncsl.nist.gov> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: gseidman@zing.ncsl.nist.gov (Gregory Seidman), vrml-ui@vag.vrml.org (vrml user interface) Subject: Re: a proposal for a widget repository Cc: pauli@uniblab.engr.sgi.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO First off, I think the widget repository is a great idea. And I think the proposal Sascha sent is an excellent start. I've got some more specific comments, mostly in reply to what has been said by Bernie Roehl and Gregory Seidman. > From Bernie: > We should probably categorize widgets in some way. There are widgets that > return a continuous value and widgets that return discrete values. The > value that a widget returns can be any of the basic VRML types (SFBool, > SFInt32, SFFloat, SFVec3f, SFRotation), and some widgets may return more > than one type of data or even arrays of various types. I agree. Also, in my work I tend to deal with 3 'strata' of objects for widgets. (Please forgive me for being mouse-centric as I explain this. I know that some of you are concerned with other input devices, and that these thoughts may need to be expanded upon). At the lowest level are 'surfaces I use to intersect the mouse.' When I click and drag, what kind of surface is the mouse passing over? In VRML, we've got PlaneSensor, CylinderSensor and SphereSensor for this purpose. For those of you who are familiar with OpenInventor, these correspond roughly to the various SbProjector classes. It would be difficult to get other variations of these objects without revising the spec, but I think that the current set is sufficient. In the middle level are 'things that move a particular way.' When I drag the mouse over one of the low-level surfaces, the cursor intersects that surface to trace a path through space. I can interpret that path in any number of ways and produce different kinds of motion. For example, I can click-drag over a PlaneSensor and interpret this as angular motion relative to some center (as with a dial or gear) as linear motion (for a slider or uniform-scaling knob) or as planar motion (for a virtual screen cursor or interpreting virtual joystick motion). I can click-drag over a SphereSensor and get rotating motion (as with a trackball or spotlight-direction-controller) or I can get translation-on-a-sphere-surface motion (for positioning flags on a globe). If we categorize and wrap-up these various categories, we can then use them in the next level up to make our widgets. Objects at this middle level correspond to the OpenInventor 'simple draggers' and have no equivalent in the VRML spec. The PROTOS I sent earlier for Translate1DraggerProto and Translate2Dragger are of this variety. At the top level (perhaps this term is inappropriate -- there will doubtless be higher-level constructs presented!) are widgets at the level Bernie described. I agree with his ideas for categorization. Note that if we've got the middle level objects in place, we can then re-use these objects to build our top-level widgets. For example, I can make a slider by bundling a 'thing that moves in a line' with some geometry that sits still as a background, and then having a short script (or bundling in some PROTO) that maps the translation of the 'thing that moves in a line' into the desired range of slider values; the resulting slider value can be the exposed output of the slider. On Mar 13, 5:31pm, Gregory Seidman wrote: > Subject: Re: a proposal for a widget repository > } Sascha Becker writes: > [...] > } > Our proposal: > } > A suggested framework for reusable widgets, including: > } > - fields for positioning, scaling, showing, hiding widgets > > Somewhat reasonable, but I think it is external to the widgets themselves. > This would be, essentially, a Transform and Switch wrapper around the > widget itself. I'm pretty sure I agree in the case of a single widget, but remember that there will also be organizational widgets (for example, something like the dreaded motif form widget), used for laying out some set of sub-widgets. These objects will certainly have parameters related to the ones Sascha proposed. > From Gregory: > } > - API for getting and setting values on valuator widgets > > Absolutely. I would go with set_value and value_changed (since this is what > I have been using in my widgets, after all). And if the widget has two values of interest? I might prefer something more descriptive. > From Gregory: > > } > - plug-in geometry for author customization > > Fairly simple for certain widgets, more comples for others. It makes some > sense to replace slider thumb geometry and the geometry of what it slides > on, but suppose you have a dial? I think plugin geometry will be a problem > for some widgets, very reasonable for others. I feel strongly that every single piece of geometry must be configurable or people will not want to use them. > From Gregory: > > Note that I also have some convienient glue PROTOs (in both > VRMLscript and Java) for connecting widgets with Interpolators, > Transforms, other Widgets, etc. They can be found at > http://zing.ncsl.nist.gov/~gseidman/paper.rev.html in the paper > I submitted to VRML '97. These are cool. I like them. I might prefer to see them broken into lighter-weight classes, but I'm not sure. Either way, something along these lines will be useful. pauli. -- Paul Isaacs, pauli@sgi.com Cosmo VRML Engineering, Silicon Graphics ---- New York Serenity Prayer: ------------------------------------------- God give me the strength to crush those in my way, the money to bribe those who can help me, and the wisdom to know the difference.