From www-vrml-owner@vag.vrml.org Sat Mar 1 20:15:08 1997 Return-Path: Received: from speckle.ncsl.nist.gov by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id UAA22266; Sat, 1 Mar 1997 20:15:07 -0500 Received: from kether.vrml.org (vrml.organic.com) by speckle.ncsl.nist.gov (4.1/SMI-3.2-del/cas.6) id AA24175; Sat, 1 Mar 97 20:14:57 EST Received: from localhost (daemon@localhost) by kether.vrml.org (8.7.5/1.0) with SMTP id BAA18846; Sun, 2 Mar 1997 01:10:35 GMT Received: by vag.vrml.org (bulk_mailer v1.5); Sun, 2 Mar 1997 01:09:15 +0000 Received: (from majordom@localhost) by kether.vrml.org (8.7.5/1.0) id BAA18773 for www-vrml-out; Sun, 2 Mar 1997 01:09:13 GMT Received: from cs.brown.edu (cs.brown.edu [128.148.128.2]) by kether.vrml.org (8.7.5/1.0) with ESMTP id BAA18769 for ; Sun, 2 Mar 1997 01:09:07 GMT Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id UAA02227 for ; Sat, 1 Mar 1997 20:10:13 -0500 (EST) From: Sascha Becker Received: (sab@localhost) by point.cs.brown.edu (8.8.3/BrownCS1.0) id UAA23882; Sat, 1 Mar 1997 20:10:00 -0500 (EST) Date: Sat, 1 Mar 1997 20:10:00 -0500 (EST) Message-Id: <199703020110.UAA23882@point.cs.brown.edu> To: www-vrml@vag.vrml.org Subject: Widgets/UI/Navigation Working Group Sender: owner-www-vrml@vag.vrml.org X-Info: To remove yourself from this list, send the command "unsubscribe" to www-vrml-request@vag.vrml.org. Precedence: bulk Status: RO User Interface and/or Widgets and/or Navigation Working Group At VRML '97, Mark Pesce called for a standard of prototype widgets for VRML 2.0. This idea triggered me to propose a "Widgets" working group, which several people then suggested expanding to "User Interface" in general. Dozens of people gave me their contact info and expressed interest in that sort of working group. The question we now face is how many working groups do we form, and what each group's focus should be. I see two possibilities: One Group, Many Purposes ------------------------ In this scenario, we form a single umbrella group, "User Interface," and perhaps issue several RFP's, for each of several topics: widget standards, navigation standards, and whatever people had in mind for "user interface" specifically. One Group, One Purpose -------------------------- In this scenario, we form at least one group, "Widgets," with a narrow focus: building a common set of VRML widgets, and a mechanism for adjusting these widgets for particular applications. People interested in broader topics of user interface, or different foci in the field, would be free to start their own working groups. I favor the second scenario, because IMHO user interface is too broad and vague a topic to productively address as a whole. Widgets are a more concrete problem domain, with a clear deliverable: a set of VRML widgets. I am eager to help coordinate a Widgets working group. What, exactly, do I mean by VRML widgets? Here's a few ideas, with influences from Inventor and the Brown Graphics Group, among others * Heads-Up Display (HUD) * Forms (a la HTML) * Direct-Manip Geometries: vectors, line segments, points * Buttons: toggle, radio, push * Viewpoint manips * Sliders * etc. Please contact me at sab@cs.brown.edu if you are interested in participating in a Widgets or UI working group-- I'm especially interested in your ideas on how our efforts could best be directed. -Sascha Becker sab@cs.brown.edu http://www.cs.brown.edu/research/graphics http://www.cs.brown.edu/people/sab From sab@cs.brown.edu Sun Mar 2 17:57:50 1997 Return-Path: Received: from cs.brown.edu by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id RAA01895; Sun, 2 Mar 1997 17:57:48 -0500 Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id RAA14099; Sun, 2 Mar 1997 17:57:46 -0500 (EST) Received: from cs.brown.edu (localhost [127.0.0.1]) by point.cs.brown.edu (8.8.3/BrownCS1.0) with ESMTP id RAA01580; Sun, 2 Mar 1997 17:57:43 -0500 (EST) Message-Id: <199703022257.RAA01580@point.cs.brown.edu> X-Mailer: exmh version 1.6.6 3/24/96 To: gseidman@zing.ncsl.nist.gov cc: sab@cs.brown.edu Subject: thanks for your vrml-ui comments Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 02 Mar 1997 17:57:43 -0500 From: Sascha Becker Status: RO May I re-post your comments to the discussion list I'm putting together? (I'll include you on the list, as well.) Your widgets work sounds like a good bit of fuel for discussion-- the problems you mention with particular widgets are, IMHO, worthy of investigation by a larger group with a shared goal of building a standardized 3D widget library. If a group of us builds a requirements document, then requests and reviews proposals for a widget library, we can eventually present the VRB with what we think is the best way to standardize VRML widgetry. Endorsement by the VRB would hopefully mean not a spec change but becoming a "recommended practice" for browser writers to implement and support; this is the way lots of the working groups' output will be brought to light. As for the brown cs program, it sounds like you're a great match for the graphics lab, and they'd have to be wearing very dark glasses to miss that. A lot of the VRML heavy hitters (including myself) will be graduating this may, and Andy just got elected to the Consortium's Board of Directors-- are you starting to get the picture? If your application didn't include mention of your work with VRML and 3D widgets, why don't you drop andy a line yourself, avd@cs.brown.edu, and describe your work briefly? -Sascha From sab@cs.brown.edu Mon Mar 3 13:55:57 1997 Return-Path: Received: from cs.brown.edu by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id NAA12738; Mon, 3 Mar 1997 13:55:55 -0500 Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id NAA02204; Mon, 3 Mar 1997 13:55:41 -0500 (EST) Received: from cs.brown.edu (localhost [127.0.0.1]) by point.cs.brown.edu (8.8.3/BrownCS1.0) with ESMTP id NAA07456; Mon, 3 Mar 1997 13:55:28 -0500 (EST) Message-Id: <199703031855.NAA07456@point.cs.brown.edu> X-Mailer: exmh version 1.6.6 3/24/96 To: Bernie Roehl cc: bill@yisup.com (Bill Enright), pell@newfire.com, sulam@construct.net, steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net, misty@well.com, matsuda@arch.sony.co.jp, joel@blacksun.com, shags@nortel.com, pauli@sgi.com, braden@shadow.net, michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com, robert@oz.com, philippe@vdi.com, gseidman@zing.ncsl.nist.gov, jch@jch.com, bl@pobox.com Subject: Re: vrml-ui/vrml-widgets In-reply-to: Your message of "Mon, 03 Mar 1997 10:29:25 EST." <199703031529.KAA29943@watt.uwaterloo.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Mar 1997 13:55:28 -0500 From: Sascha Becker Status: RO Bernie wrote: > >Are we planning to look strictly at navigation, or are we interested in >examining manipulation as well? Certainly navigating through 3D space and >moving an object through 3D space have many elements in common. > I'm personally interested in manipulation more than navigation, but there's probably a good deal of overlap. If I implement slider, dashboard, pushbutton, and trackball widgets as PROTO'S with configurable geometry, then (shazam!) I can implement the cosmo dashboard with any geometry I like. In other words, part of navigation ui is just the general widgets problem applied to a bound viewpoint. In private mail to me, there's been significantly more interest in a widgets-only group than a more general ui group. Perhaps mapping out the problems we're facing would help us to define our goals-- here's a rough list I've created, please contribute more. (Note that I don't think that all of these issues are necessarily appropriate for a widgets group-- this list is more intended as grounds for discussion about * Spatial Navigation - navigation controls that a world author can configure to be appropriate to each world, both in terms of geometry and behavior. - a mechanism for browser sensitivity to user preferences for navigation, ie, "start up with a walk viewer if the file doesn't specify otherwise." - non-standard devices to control navigation, so that a user can decide to drive the fly viewer with a joystick or the examiner viewer with a spaceball. - a mechanism for specifying additional basic viewer types, beyond examine/walk/fly. - standards for keyboard navigation-- which keys are used, what they mean in each viewer type. * WWW Navigation/Information - mechanisms for world authors to specify how the presence of anchors in the scene will be revealed. This is another case of "the ui is the content is the ui"-- an inappropriate cue could disrupt the feel of the world. - similar mechanisms for specifying the appearance of an inline while it's loading - ditto for textures. * Widgetry - Joel Dubiner's list: > A text entry area > A Cursor/Caret insertion point > Scroll Bars > Drop Down/Hierarchical Menus > Slider Bars > Tool Bar > List Menu > Minimize/Maximize/Resize controls > Selection tool (with single and group selection semantics) > Common idioms for selection states: unselected, activated, inactive, > process pending > Radio Buttons > Check Boxes > User Prompt (status line) > Context-sensitive help (baloon help) - Valuators: geometry widgets that spit out values. I expect these will be helpful in building simple interactive systems, when combined with routes. - Layout tools for widgets. I'd like to be able to make a row/column grid of widgets, size them all down to fit a particular region of space, then make all of that a child of a billboard node. * Devices: - standard mechanism for using 3D and 6D input devices in VRML browsers. It would be good if device manufacturers could write a single driver that would work for all the browsers. - picking metaphors for >2D input devices-- it gets a lot more complicated, especially with a very jumpy device. Without careful ui design, lots of >2D interface devices are useless for picking, only good for navigation. Brown's done some work on this in the last few years-- contact me for references, or see http://www.cs.brown.edu/research/graphics/res earch/pub - stereo viewers-- either the user or the world author needs to specify things like interocular distance, minimum frame rate for stereo, fishbowl vr vs. immersive vr, etc. * Implementation issues: - Architecture: will the extensions we want be implemented as PROTOs, reserved-word PROTOS, more official nodes (I just threw that in for the sake of completeness; changing the spec is *not* a goal of mine wherever possibly avoidable) - Manpower: should the output of our group simply be a document, RFPs, and recommendations on proposals we receive, or should we try as a group to solve the problems we select? Please not a revised list of recipients. I'll get us on an official mailing list within a few days. -Sascha From broehl@ece.uwaterloo.ca Mon Mar 3 15:33:02 1997 Return-Path: Received: from ece.uwaterloo.ca by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id PAA13113; Mon, 3 Mar 1997 15:32:59 -0500 Received: from watt.uwaterloo.ca (watt.uwaterloo.ca [129.97.56.5]) by ece.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id PAA13888; Mon, 3 Mar 1997 15:32:17 -0500 (EST) From: Bernie Roehl Received: (from broehl@localhost) by watt.uwaterloo.ca (8.8.5/8.8.5) id PAA02177; Mon, 3 Mar 1997 15:32:15 -0500 (EST) Message-Id: <199703032032.PAA02177@watt.uwaterloo.ca> Subject: Re: vrml-ui/vrml-widgets To: sab@cs.brown.edu (Sascha Becker) Date: Mon, 3 Mar 1997 15:32:12 -0500 (EST) Cc: broehl@ece.uwaterloo.ca, bill@yisup.com, pell@newfire.com, sulam@construct.net, steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net, misty@well.com, matsuda@arch.sony.co.jp, joel@blacksun.com, shags@nortel.com, pauli@sgi.com, braden@shadow.net, michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com, robert@oz.com, philippe@vdi.com, gseidman@zing.ncsl.nist.gov, jch@jch.com, bl@pobox.com In-Reply-To: <199703031855.NAA07456@point.cs.brown.edu> from "Sascha Becker" at Mar 3, 97 01:55:28 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Sascha Becker writes: > I'm personally interested in manipulation more than navigation, > but there's probably a good deal of overlap. If I implement > slider, dashboard, pushbutton, and trackball widgets as PROTO'S > with configurable geometry, then (shazam!) I can implement the > cosmo dashboard with any geometry I like. In other words, part > of navigation ui is just the general widgets problem applied to > a bound viewpoint. I definitely agree. I was just a bit concerned because many of the messages to this list have specifically mentioned navigation. > - Layout tools for widgets. I'd like to be able to make a row/column > grid of widgets, size them all down to fit a particular region of space, then > make all of that a child of a billboard node. That's an interesting thought. Of course, that widget grid would itself be a widget. > * Devices: > - standard mechanism for using 3D and 6D input devices in VRML > browsers. It would be good if device manufacturers could write a single > driver that would work for all the browsers. Right, agreed. Under Windows95, that's already in place (DirectInput), and I believe there's something analogous to that in the Mac world. So far as I know, there's no standard for 3D and 6D input devices under Unix. Of course, it would be even better if the device manufacturers would agree on a standard over-the-wire protocol, at least for serial devices. > - picking metaphors for >2D input devices-- it gets a lot more > complicated, especially with a very jumpy device. Yes, agreed. It's fortunate that the various "sensor" nodes (notably the TouchSensor) were redesigned a while back to make them suitable for use in immersive environments. > - stereo viewers-- either the user or the world author needs > to specify things like interocular distance, minimum frame rate for > stereo, fishbowl vr vs. immersive vr, etc. Hmm... to me, that's a browser issue. -- Bernie Roehl University of Waterloo Dept of Electrical and Computer Engineering Mail: broehl@sunee.uwaterloo.ca Voice: (519) 888-4567 x 2607 [work] URL: http://sunee.uwaterloo.ca/~broehl/bernie.html From sab@cs.brown.edu Mon Mar 3 15:35:28 1997 Return-Path: Received: from cs.brown.edu by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id PAA13136; Mon, 3 Mar 1997 15:35:26 -0500 Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id OAA03581; Mon, 3 Mar 1997 14:39:45 -0500 (EST) Received: from cs.brown.edu (localhost [127.0.0.1]) by point.cs.brown.edu (8.8.3/BrownCS1.0) with ESMTP id OAA08001; Mon, 3 Mar 1997 14:39:38 -0500 (EST) Message-Id: <199703031939.OAA08001@point.cs.brown.edu> X-Mailer: exmh version 1.6.6 3/24/96 To: Bernie Roehl cc: joel@blacksun.com (Joel Dubiner), bill@yisup.com, pell@newfire.com, sulam@construct.net, steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net, misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com, braden@shadow.net, michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com, robert@oz.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, sab@cs.brown.edu, vidinick@aol.com Subject: Re: vrml-ui/vrml-widgets: Widget List In-reply-to: Your message of "Mon, 03 Mar 1997 13:53:56 EST." <199703031853.NAA01428@watt.uwaterloo.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Mar 1997 14:39:36 -0500 From: Sascha Becker Status: RO In message <199703031853.NAA01428@watt.uwaterloo.ca>, Bernie Roehl writes: [quotes Joel's list of 2D widgets] >Almost all of the above are strictly 2D metaphors, mostly text-oriented. >I doubt if there's much to be gained from having text-oriented widgets >in a 3D environment, since text entry and editing is really a 2D activity. The advantage of 2D or text widgets that exist in a 3D scene is simply that they allow the user to perform non-spatial tasks in a semi-immersive space. This capability is desirable when the 2D widgets are controlling an aspect of the 3D scene (ie, the brightness of a spotlight) or referring to a component of the 3D scene (ie, a form next to a sculpture in a virtual museum that records the users comments on the sculpture.) Putting these controls directly in the scene enriches the metaphor (lighting technichian in a theatre, visitor to a gallery) where seperate 2D widgets might interfere with it. >The rest of Joel's list is much more interesting: > >> Slider Bars >> Tool Bars >> Selection tool (with single and group selection semantics) *** don't forget hierarchical selection semantics, ie, how does the user indicate whether a click on a model's right index finger refers to the finger, hand, forearm, arm, or the entire model? >> Common idioms for selection states: unselected, activated, inactive, >> Radio Buttons >> Check Boxes > >All of these are potentially adaptable to a 3D context. > >In addition, we should be looking for widgets that are by their >very nature three-dimensional. I think we would do well to look >to the real world for guidance in finding those widgets. >Cindy's steering wheel is the first example that springs to mind, of >course. I completely agree-- I think that's where the work of this group will get very interesting. >What we need to do is identify new types of widgets that are suitable for >a 3D (and potentially immersive) environment. Much as I dislike Cosmo >Player's controls, they're a step in the right direction. [...] >Joel proposes: >> >> 1) informal brainstorming for another week or so, then: >> 2) the creation of a list of class names and behaviors >> 3) the creation of a formal design document >> 4) the creation of a standard EXTERN_PROTO library for UI widgets > >That sounds reasonable. > I'm worried about committing a working group to delivering an _implementation_ of a widget library, as opposed to issuing a set of requirements and then selecting from a variety of implementations. (I'm thinking of the initial VRML 2.0 standard selection process as a model.) I guess the point is moot if no-one other than the members of this list are actually interested in developing such a library. -Sascha From www-vrml-owner@vag.vrml.org Mon Mar 3 16:20:11 1997 Return-Path: Received: from speckle.ncsl.nist.gov by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id QAA13352; Mon, 3 Mar 1997 16:20:09 -0500 Received: from by speckle.ncsl.nist.gov (4.1/SMI-3.2-del/cas.6) id AB03491; Mon, 3 Mar 97 16:18:20 EST Received: from localhost (daemon@localhost) by kether.vrml.org (8.7.5/1.0) with SMTP id TAA04894; Mon, 3 Mar 1997 19:29:48 GMT Received: by vag.vrml.org (bulk_mailer v1.5); Mon, 3 Mar 1997 19:28:37 +0000 Received: (from majordom@localhost) by kether.vrml.org (8.7.5/1.0) id TAA04756 for www-vrml-out; Mon, 3 Mar 1997 19:28:35 GMT Received: from glacier.binc.net (glacier.binc.net [205.173.176.10]) by kether.vrml.org (8.7.5/1.0) with SMTP id TAA04743 for ; Mon, 3 Mar 1997 19:28:27 GMT Received: from xxx.binc.net by glacier.binc.net (8.6.12/4.03) id NAA25790; Mon, 3 Mar 1997 13:29:28 -0600 Message-Id: <331B25AC.31AD@mailbag.com> Date: Mon, 03 Mar 1997 13:25:32 -0600 From: Gavin Bell Reply-To: gavin@acm.org X-Mailer: Mozilla 3.01Gold (Win95; I) Mime-Version: 1.0 To: www-vrml@vag.vrml.org Cc: rikk@best.com Subject: Reminder: Review the VRML97 Editor's Draft Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-www-vrml@vag.vrml.org X-Info: To remove yourself from this list, send the command "unsubscribe" to www-vrml-request@vag.vrml.org. Precedence: bulk Status: RO Another reminder: There is a new version of the VRML 2.0 spec available at: http://vag.vrml.org/VRML97/DIS/ or http://vrml.sgi.com/moving-worlds/spec.DIS/ PLEASE: Take a close look at it and help the editors (Rikk Carey and Dick Puk) find the mistakes in it. Rikk will be posting a list of major changes (all of which are quite minor) soon. If you are implementing or have implemented part of a browser, I would particularly encourage you to take the time to read the parts of the spec that apply to what you've implemented. We might have changed something inadvertently, or the spec might have been clarified in a way that makes your implementation non-conformant. If you're managing a team implementing a browser or tool: make them read the new spec, your products will work better and you won't kick yourself when you find out it is too late for us to fix some problem in the spec that makes it impossible for your product to work correctly... If you do find problems: Please bundle them together (it is much harder to deal with a constant stream of tiny email messages) and send them to Rikk Carey, rikk@best.com. As always, www-vrml is the place to discuss anything that might be controversial or non-obvious. -- Gavin Bell -- gavin@acm.org -- http://www.mailbag.com/users/gavin From broehl@ece.uwaterloo.ca Mon Mar 3 16:27:07 1997 Return-Path: Received: from ece.uwaterloo.ca by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id QAA13442; Mon, 3 Mar 1997 16:27:03 -0500 Received: from watt.uwaterloo.ca (watt.uwaterloo.ca [129.97.56.5]) by ece.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id PAA14093; Mon, 3 Mar 1997 15:44:29 -0500 (EST) From: Bernie Roehl Received: (from broehl@localhost) by watt.uwaterloo.ca (8.8.5/8.8.5) id PAA02300; Mon, 3 Mar 1997 15:44:27 -0500 (EST) Message-Id: <199703032044.PAA02300@watt.uwaterloo.ca> Subject: Re: vrml-ui/vrml-widgets: Widget List To: sab@cs.brown.edu (Sascha Becker) Date: Mon, 3 Mar 1997 15:44:26 -0500 (EST) Cc: broehl@ece.uwaterloo.ca, joel@blacksun.com, bill@yisup.com, pell@newfire.com, sulam@construct.net, steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net, misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com, braden@shadow.net, michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com, robert@oz.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, sab@cs.brown.edu, vidinick@aol.com In-Reply-To: <199703031939.OAA08001@point.cs.brown.edu> from "Sascha Becker" at Mar 3, 97 02:39:36 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Sascha Becker: > *** don't forget hierarchical selection semantics, ie, how does > the user indicate whether a click on a model's right index > finger refers to the finger, hand, forearm, arm, or the entire > model? Absolutely. > I'm worried about committing a working group to delivering > an _implementation_ of a widget library, as opposed to issuing > a set of requirements and then selecting from a variety of > implementations. (I'm thinking of the initial VRML 2.0 standard > selection process as a model.) You know, I'm not sure that the two situations are really the same. Certainly widget specification and construction has the potential to be an open-ended, ongoing activity -- unlike the VRML 2.0 standard process which was very specifically focussed. I think we need to: 1. Describe (at least in general terms) how widgets should be designed 2. Organize a list of the kinds of widgets people would find useful in VRML, and who's working on creating them The first gives developers some guidelines, the second helps us avoid getting five different steering wheels and no toggle switches (for example). > I guess the point is moot if no-one > other than the members of this list are actually interested in > developing such a library. I think that's *very* likely. After all, just turn it around: Anyone who's interesting in developing such a library will probably join the list. -- Bernie Roehl University of Waterloo Dept of Electrical and Computer Engineering Mail: broehl@sunee.uwaterloo.ca Voice: (519) 888-4567 x 2607 [work] URL: http://sunee.uwaterloo.ca/~broehl/bernie.html From sab@cs.brown.edu Mon Mar 3 16:46:16 1997 Return-Path: Received: from cs.brown.edu by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id QAA13751; Mon, 3 Mar 1997 16:46:12 -0500 Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id QAA07229; Mon, 3 Mar 1997 16:34:29 -0500 (EST) Received: from cs.brown.edu (localhost [127.0.0.1]) by point.cs.brown.edu (8.8.3/BrownCS1.0) with ESMTP id QAA12120; Mon, 3 Mar 1997 16:34:10 -0500 (EST) Message-Id: <199703032134.QAA12120@point.cs.brown.edu> X-Mailer: exmh version 1.6.6 3/24/96 To: Bernie Roehl cc: joel@blacksun.com, bill@yisup.com, pell@newfire.com, sulam@construct.net, steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu, philippe@e-spaces.com, otto@interport.net, misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com, braden@shadow.net, michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com, robert@oz.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, vidinick@aol.com, john.martellaro@lmco.com, rcg@rd.engr.sgi.com, mpesce@netcom.com, jonpruyn@inkstone.com, sab@cs.brown.edu Subject: vrml-widgets group output [Was Re: vrml-ui/vrml-widgets: Widget List] In-reply-to: Your message of "Mon, 03 Mar 1997 15:44:26 EST." <199703032044.PAA02300@watt.uwaterloo.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Mar 1997 16:34:10 -0500 From: Sascha Becker Status: RO In message <199703032044.PAA02300@watt.uwaterloo.ca>, Bernie Roehl writes: >Sascha Becker: >> I'm worried about committing a working group to delivering >> an _implementation_ of a widget library, as opposed to issuing >> a set of requirements and then selecting from a variety of >> implementations. (I'm thinking of the initial VRML 2.0 standard >> selection process as a model.) > >You know, I'm not sure that the two situations are really the same. >Certainly widget specification and construction has the potential >to be an open-ended, ongoing activity -- unlike the VRML 2.0 standard >process which was very specifically focussed. > >I think we need to: > > 1. Describe (at least in general terms) how widgets should be designed > > 2. Organize a list of the kinds of widgets people would find useful in > VRML, and who's working on creating them > >The first gives developers some guidelines, the second helps us avoid >getting five different steering wheels and no toggle switches (for example). For #1, above, I think we can and should get rather specific about the technical details of how widgets should be _implemented_, though perhaps remain vague about the fuzzy issues of widget _design_. That is, I think we need some naming conventions for widgets, guidelines for poly count and scene graph structure, a standard mechanism for documenting the widgets' behaviors, (both at user-level and author-level), and a model for how widgets will be used in the scene (ie, SFFields for input and output values, positioning external or internal to the widget, particularly relevant for widgets subject to a layout manager.) I also think we need a central repository for wg-blessed widget implementations and their documentation. Also, your breakdown above leaves out the possibility of multiple versions of the same widget, each of which have the same behavior but different geometry. If the steering wheel I write is sufficiently general, I'd like to be able to plug in geometry for a porsche steering wheel, a caddy, an indycar, etc. Buzzwords: allow the user to modify "look" without touching "feel." > >> I guess the point is moot if no-one >> other than the members of this list are actually interested in >> developing such a library. > >I think that's *very* likely. After all, just turn it around: Anyone >who's interesting in developing such a library will probably join the list. > Agreed. Our numbers swell hourly... From broehl@ece.uwaterloo.ca Mon Mar 3 17:07:09 1997 Return-Path: Received: from ece.uwaterloo.ca by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id RAA13964; Mon, 3 Mar 1997 17:07:05 -0500 Received: from watt.uwaterloo.ca (watt.uwaterloo.ca [129.97.56.5]) by ece.uwaterloo.ca (8.8.5/8.8.5) with ESMTP id QAA16688; Mon, 3 Mar 1997 16:56:13 -0500 (EST) From: Bernie Roehl Received: (from broehl@localhost) by watt.uwaterloo.ca (8.8.5/8.8.5) id QAA03436; Mon, 3 Mar 1997 16:56:09 -0500 (EST) Message-Id: <199703032156.QAA03436@watt.uwaterloo.ca> Subject: Re: vrml-widgets group output [Was Re: vrml-ui/vrml-widgets: Widget List] To: sab@cs.brown.edu (Sascha Becker) Date: Mon, 3 Mar 1997 16:56:08 -0500 (EST) Cc: broehl@ece.uwaterloo.ca, joel@blacksun.com, bill@yisup.com, pell@newfire.com, sulam@construct.net, steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu, philippe@e-spaces.com, otto@interport.net, misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com, braden@shadow.net, michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com, robert@oz.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, vidinick@aol.com, john.martellaro@lmco.com, rcg@rd.engr.sgi.com, mpesce@netcom.com, jonpruyn@inkstone.com, sab@cs.brown.edu In-Reply-To: <199703032134.QAA12120@point.cs.brown.edu> from "Sascha Becker" at Mar 3, 97 04:34:10 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO Sascha Becker writes: > I think we can and should get rather specific > about the technical details of how widgets should be _implemented_, > though perhaps remain vague about the fuzzy issues of widget > _design_. That is, I think we need some naming conventions > for widgets, guidelines for poly count and scene graph structure, > a standard mechanism for documenting the widgets' behaviors, > and a model for how widgets will be used in the scene To me, those are design issues rather than implementation -- but it's clear that we agree on what needs to be specified. The reason I would like to see hardware devices (such as joysticks and spaceballs and whatnot) included under "widgets" is because they would have most of those same properties. And the issue of whether a user moves around by using a real trackball or a virtual one should be determined strictly by whether or not a real one is available to them. > I also think we need a central repository for > wg-blessed widget implementations and their documentation. Definitely. Probably on the Consortium site...? > Also, your breakdown above leaves out the possibility > of multiple versions of the same widget, each of which > have the same behavior but different geometry. Good point. I would suggest that each widget have a default geometry which can be overridden when the widget is instanced. -- Bernie Roehl University of Waterloo Dept of Electrical and Computer Engineering Mail: broehl@sunee.uwaterloo.ca Voice: (519) 888-4567 x 2607 [work] URL: http://sunee.uwaterloo.ca/~broehl/bernie.html From robert@oz.com Mon Mar 3 17:22:13 1997 Return-Path: Received: from xanadu.oz.com by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id RAA14041; Mon, 3 Mar 1997 17:22:11 -0500 Received: from robofly by xanadu.oz.com (8.8.3/OZnet/12-01-97); Mon, 3 Mar 1997 15:41:44 -0800 Message-Id: <3.0.32.19970304013625.008cf210@xanadu.oz.com> X-Sender: robert@xanadu.oz.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 04 Mar 1997 01:36:39 -0800 To: Sascha Becker , Bernie Roehl From: Robert Bjarnason Subject: Re: vrml-ui/vrml-widgets: Widget List Cc: joel@blacksun.com (Joel Dubiner), bill@yisup.com, pell@newfire.com, sulam@construct.net, steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net, misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com, braden@shadow.net, michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, sab@cs.brown.edu, vidinick@aol.com, gunnar@this.is, ragnar@this.is, ramman@centrum.dk, mpesce@netcom.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO Hi, [>-Sascha wrote:] >The advantage of 2D or text widgets that exist in a 3D scene is simply that >they allow the user to perform non-spatial tasks in a semi-immersive >space. This capability is desirable when the 2D widgets are controlling >an aspect of the 3D scene (ie, the brightness of a spotlight) or >referring to a component of the 3D scene (ie, a form next to a sculpture >in a virtual museum that records the users comments on the sculpture.) >Putting these controls directly in the scene enriches the metaphor >(lighting technichian in a theatre, visitor to a gallery) where seperate >2D widgets might interfere with it. After being the head of the lighting departament @ the Icelandic Opera for almost two year's, I really identify with virtual lightning tech guy. I've designed light's for operas like Othello and the Magic Flute. I want to share with you a little fantasy that takes place in cyberspace. { I turn on my VRML console, [select] the show/opera/play I'm working on. I immerse into they scene @ they same location as when I turned off my console last night. I'm currently in OB (Out of body) mode, I walk my avatar around in the set. I stop by the bed, I [command] my avatar to sit down. Then I [turn] my viewpoint so I'm facing my avatar and [zoom] in to his head. I [hit] the Widgets hotkey and a 3D VRML selection panel unfolds from the left of me. I [select] the time line, I [slide] through time until I'm in Act IV, light cue 298, I [select]. I [hit] the main Widgets hotkey and the 3D VRML panel folds back and disappears. There is an light blue (cold) light on my avatars face, I look up from the VRML console and [grab] the script, that is beside the console on my (real/unreal) living room table. I [look] up Act IV, "oh, no" I must have been sleepy last night, the ghost doesn't appear until in cue 299 and things have to be warm until then because this is the most romantic scene in this whole techno-opera. I look back @ the console, [hit] my control panel key, [select] the light grid. The scene it self goes 75% transparent and fly's into the background, 3D grid with all my lights appears. I quickly [select] all the lights I need with my pointing device. I [select] the color module (http://wish.i.had.alink.to.mpesce's.vrml97.demo/) and [give] the light approximately the right flavor. I [hit] the panel hide button and it's folds back and disappears. I'm back in the scene, I still have the [controls] for the brightness of all the [selected] lights, I [zoom] out from my avatar and look @ it from [many] viewpoints and [adjust] the color heat @ the same time until I'm happy ... } With warm regards, Robert Vidar Bjarnason Ambassador robert@oz.com From robert@oz.com Mon Mar 3 19:49:42 1997 Return-Path: Received: from xanadu.oz.com by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id TAA15110; Mon, 3 Mar 1997 19:49:40 -0500 Received: from robofly by xanadu.oz.com (8.8.3/OZnet/12-01-97); Mon, 3 Mar 1997 18:10:28 -0800 Message-Id: <3.0.32.19970304040508.007b9340@xanadu.oz.com> X-Sender: robert@xanadu.oz.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 04 Mar 1997 04:05:21 -0800 To: Sascha Becker , Bernie Roehl From: Robert Bjarnason Subject: Thoughts on Layers Cc: joel@blacksun.com (Joel Dubiner), bill@yisup.com, pell@newfire.com, sulam@construct.net, steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net, misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com, braden@shadow.net, michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, sab@cs.brown.edu, vidinick@aol.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO Hi, Where do the widgets fit in the layer system of our being ? Proposal> (int) Layer 1 - (reserved) (int) Layer 2 - The soul (int) Layer 3 - Unconsciousness (ext) Layer 4 - Consciousness (ext) Layer 5 - Our body (ext) Layer 6 - The keyboard (ext) Layer 7 - The Widgets (int) Layer 8 - Content Our goal is to try to connect L2 to L8. Then L2 routes back info into L4. L7 is mission critical, if it's not enable to communicate transparently to L3 we have a broken chain. L4 must not have to deal with L7 except in the learning phaze of L7. With warm regards, Robert Vidar Bjarnason Ambassador robert@oz.com From pauli@uniblab.engr.sgi.com Mon Mar 3 20:23:06 1997 Return-Path: Received: from sgi.sgi.com by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id UAA15210; Mon, 3 Mar 1997 20:23:03 -0500 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 RAA15395; Mon, 3 Mar 1997 17:20:37 -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 RAA04519; Mon, 3 Mar 1997 17:20:21 -0800 Received: (from pauli@localhost) by uniblab.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id BAA23816; Tue, 4 Mar 1997 01:18:36 GMT From: "Paul Isaacs" Message-Id: <9703031718.ZM23814@uniblab.engr.sgi.com> Date: Mon, 3 Mar 1997 17:18:34 -0800 In-Reply-To: Bernie Roehl "Re: vrml-ui/vrml-widgets: Widget List" (Mar 3, 3:44pm) References: <199703032044.PAA02300@watt.uwaterloo.ca> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: Bernie Roehl , sab@cs.brown.edu (Sascha Becker) Subject: Re: vrml-ui/vrml-widgets: Widget List Cc: joel@blacksun.com, bill@yisup.com, pell@newfire.com, sulam@construct.net, steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net, misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com, braden@shadow.net, michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@relay.engr.SGI.COM, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu, ouch@relay.engr.SGI.COM, thinktank@infomaniacs.com, robert@oz.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, vidinick@aol.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com" Status: RO -- --PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com Content-Type: text/plain; charset=us-ascii Hi everyone, I'm glad this group has formed and I'm sure I'll have plenty to say as time goes by. As far as approach and organization, I'll sit back for now since I mostly agree with what's been said. In particular, I like Mike Pell's comments on Widgets: "I believe that the working group should _not_ try to propose or impose an "official" set of user interface widgets on authors or the Consortium. What would be great, in my opinion, is for the working group to publish a set of high quality widgets for authors to either use either "as is" or to extend to their fit their needs. As much as I see the value in standardization in user interface widgets for operating systems, I also see it as stifling creativity. The consumers of VRML content will ultimately decide which "look and feel" suits their own needs. Let's encourage experimentation by authors, but give them a solid base to work from. In this spirit, and just for fun, I've attached some PROTOs I've been using for a project I'm working on. They (or some variation) may prove useful as building blocks for a widget set. If not, some of you may enjoy using them anyway. The two protos roughly correspond to the Inventor classes SoTranslate1Dragger and SoTranslate2Dragger. They add two configurable geometries and appearances to the PlaneSensor for a two-state draggable object. One appearance/geometry combo is shown in the inactive state, the other is shown while the object is being dragged. The first may be dragged in a line (min/max will apply) and the second may be dragged in a plane. I'll be making other classes to complete the Inventor suite of 'simple draggers' and I'll be happy to share these as they develop. My feeling is that any widget set will need a set of dragger-like PROTOS as a support layer. To try these, you'll need to stick all 6 attached files in one directory, then read the test files into your browser. The attached files are: testTranslate1Dragger.wrl testTranslate2Dragger.wrl Each of these contains a couple of draggers used in different ways. They show how the geometry can be changed and a couple use the min/max features to limit motion. translate1DraggerProto.wrl translate2DraggerProto.wrl These are the PROTO files for the two dragger classes. geometryProtos.wrl appearanceProtos.wrl PROTOs for some geometries and appearances that I use frequently. Implementation Gotcha: The tricky part about turning a SENSOR into a dragger is insuring that: [1] You can put the dragger somewhere by setting an input field [2] You can know where the dragger is placed by reading an output field. Getting this right is tricky, because the only way to put the sensor somewhere is to set its set_offset field. However outputs can come from the sensor in two places (offset_changed and translation_changed) and you have to monitor both of these to get the desired result. So you have to connect the input to the Sensor's set_offset field, and then you have to connect BOTH the Sensor's offset_changed and translation_changed fields to the PROTO's output field. (I chose to do this indirectly by routing these first to the Geometry's translation and then from the Geometry's translation to the PROTO's output). Everything else is fairly straightforward. I chose to make the myGeometry and myActiveGeometry fields be actual geometry nodes. For true generality, it would probably be better to allow these to be arbitrary scene graphs and stick them in toto inside the dragger instead of setting them as a geometry field. 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. --PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com X-Zm-Content-Name: testTranslate1Dragger.wrl Content-Description: Text Content-Type: text/plain ; name="testTranslate1Dragger.wrl" ; charset=us-ascii #VRML V2.0 utf8 EXTERNPROTO Blue [] "appearanceProtos.wrl#Blue" EXTERNPROTO Magenta [] "appearanceProtos.wrl#Magenta" EXTERNPROTO Red [] "appearanceProtos.wrl#Red" EXTERNPROTO RylonFlames [] "appearanceProtos.wrl#RylonFlames" EXTERNPROTO White [] "appearanceProtos.wrl#White" EXTERNPROTO Yellow [] "appearanceProtos.wrl#Yellow" EXTERNPROTO ArrowheadGeom [] "geometryProtos.wrl#ArrowheadGeom" EXTERNPROTO Horizontal4UnitBar [] "geometryProtos.wrl#Horizontal4UnitBar" EXTERNPROTO VerticalNubbin [] "geometryProtos.wrl#VerticalNubbin" EXTERNPROTO Translate1Dragger [ exposedField SFNode myAppearance exposedField SFNode myGeometry exposedField SFNode myActiveAppearance exposedField SFNode myActiveGeometry field SFFloat maxPosition field SFFloat minPosition eventIn SFVec3f translation_in field SFVec3f translation_init eventOut SFVec3f translation_out eventOut SFBool isActive_out ] "translate1DraggerProto.wrl" Group { children [ Transform { translation 0 2 0 children Translate1Dragger { myAppearance Red {} myGeometry Box {} myActiveAppearance Yellow {} myActiveGeometry Cone {} } } Transform { children [ Translate1Dragger { myAppearance Magenta {} myGeometry VerticalNubbin {} myActiveAppearance Yellow {} myActiveGeometry VerticalNubbin {} minPosition -2 maxPosition 2 } Shape { appearance Blue {} geometry Horizontal4UnitBar {} } ] } Transform { translation 0 -2 0 children Translate1Dragger { myAppearance RylonFlames {} myGeometry ArrowheadGeom {} myActiveAppearance Yellow {} myActiveGeometry ArrowheadGeom {} minPosition 0 maxPosition 100 } } ] } --PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com X-Zm-Content-Name: testTranslate2Dragger.wrl Content-Description: Text Content-Type: text/plain ; name="testTranslate2Dragger.wrl" ; charset=us-ascii #VRML V2.0 utf8 EXTERNPROTO Blue [] "appearanceProtos.wrl#Blue" EXTERNPROTO Magenta [] "appearanceProtos.wrl#Magenta" EXTERNPROTO Red [] "appearanceProtos.wrl#Red" EXTERNPROTO RylonFlames [] "appearanceProtos.wrl#RylonFlames" EXTERNPROTO White [] "appearanceProtos.wrl#White" EXTERNPROTO Yellow [] "appearanceProtos.wrl#Yellow" EXTERNPROTO Translate2Dragger [ exposedField SFNode myAppearance exposedField SFNode myGeometry exposedField SFNode myActiveAppearance exposedField SFNode myActiveGeometry field SFVec2f maxPosition field SFVec2f minPosition eventIn SFVec3f translation_in field SFVec3f translation_init eventOut SFVec3f translation_out eventOut SFBool isActive_out ] "translate2DraggerProto.wrl" Group { children [ Transform { translation 0 2 0 children Translate2Dragger { myAppearance Red {} myGeometry Box {} myActiveAppearance Yellow {} myActiveGeometry Cone {} } } Transform { children [ Translate2Dragger { myAppearance Magenta {} myGeometry Sphere { radius .1 } myActiveAppearance Yellow {} myActiveGeometry Sphere { radius .1} minPosition -.5 -.5 maxPosition .5 .5 translation_init -.5 -.5 0 } Shape { appearance Blue {} geometry Box { size 1 1 .05 } } ] } ] } --PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com X-Zm-Content-Name: translate1DraggerProto.wrl Content-Description: Text Content-Type: text/plain ; name="translate1DraggerProto.wrl" ; charset=us-ascii #VRML V2.0 utf8 PROTO Translate1Dragger [ exposedField SFNode myAppearance Appearance {} exposedField SFNode myGeometry Box {} exposedField SFNode myActiveAppearance Appearance {} exposedField SFNode myActiveGeometry Box {} field SFFloat maxPosition -1 field SFFloat minPosition 0 eventIn SFVec3f translation_in field SFVec3f translation_init 0 0 0 eventOut SFVec3f translation_out eventOut SFBool isActive_out ] { Transform { children [ DEF SENSOR PlaneSensor { set_offset IS translation_in isActive IS isActive_out } DEF GEOM_XFORM Transform { children DEF GEOM_SWITCH Switch { whichChoice 0 choice [ Shape { appearance IS myAppearance geometry IS myGeometry }, Shape { appearance IS myActiveAppearance geometry IS myActiveGeometry } ] } translation_changed IS translation_out } DEF TRANSLATE_1_DRAGGER_SCRIPT Script { field SFFloat maxPosition IS maxPosition field SFFloat minPosition IS minPosition field SFVec3f translation_init IS translation_init eventIn SFBool isActive_in eventOut SFInt32 whichChoice_out eventOut SFVec2f maxPos_out eventOut SFVec2f minPos_out eventOut SFVec3f translation_out url "vrmlscript: function initialize() { // setting the second values to 0 clamps the translation in the // y direction, so motion occurs only in x. maxPos_out = new SFVec2f( maxPosition, 0 ); minPos_out = new SFVec2f( minPosition, 0 ); translation_out = translation_init; } function isActive_in(value,time) { if (value == FALSE) whichChoice_out = 0; else whichChoice_out = 1; }" } ] } ROUTE SENSOR.offset_changed TO GEOM_XFORM.set_translation ROUTE SENSOR.translation_changed TO GEOM_XFORM.set_translation ROUTE SENSOR.isActive TO TRANSLATE_1_DRAGGER_SCRIPT.isActive_in ROUTE TRANSLATE_1_DRAGGER_SCRIPT.whichChoice_out TO GEOM_SWITCH.whichChoice ROUTE TRANSLATE_1_DRAGGER_SCRIPT.maxPos_out TO SENSOR.maxPosition ROUTE TRANSLATE_1_DRAGGER_SCRIPT.minPos_out TO SENSOR.minPosition ROUTE TRANSLATE_1_DRAGGER_SCRIPT.translation_out TO SENSOR.set_offset } --PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com X-Zm-Content-Name: translate2DraggerProto.wrl Content-Description: Text Content-Type: text/plain ; name="translate2DraggerProto.wrl" ; charset=us-ascii #VRML V2.0 utf8 PROTO Translate2Dragger [ exposedField SFNode myAppearance Appearance {} exposedField SFNode myGeometry Box {} exposedField SFNode myActiveAppearance Appearance {} exposedField SFNode myActiveGeometry Box {} field SFVec2f maxPosition -1 -1 field SFVec2f minPosition 0 0 eventIn SFVec3f translation_in field SFVec3f translation_init 0 0 0 eventOut SFVec3f translation_out eventOut SFBool isActive_out ] { Transform { children [ DEF SENSOR PlaneSensor { set_offset IS translation_in isActive IS isActive_out maxPosition IS maxPosition minPosition IS minPosition } DEF GEOM_XFORM Transform { children DEF GEOM_SWITCH Switch { whichChoice 0 choice [ Shape { appearance IS myAppearance geometry IS myGeometry }, Shape { appearance IS myActiveAppearance geometry IS myActiveGeometry } ] } translation_changed IS translation_out } DEF TRANSLATE_2_DRAGGER_SCRIPT Script { field SFVec3f translation_init IS translation_init eventIn SFBool isActive_in eventOut SFInt32 whichChoice_out eventOut SFVec3f translation_out url "vrmlscript: function initialize() { translation_out = translation_init; } function isActive_in(value,time) { if (value == FALSE) whichChoice_out = 0; else whichChoice_out = 1; }" } ] } ROUTE SENSOR.offset_changed TO GEOM_XFORM.set_translation ROUTE SENSOR.translation_changed TO GEOM_XFORM.set_translation ROUTE SENSOR.isActive TO TRANSLATE_2_DRAGGER_SCRIPT.isActive_in ROUTE TRANSLATE_2_DRAGGER_SCRIPT.whichChoice_out TO GEOM_SWITCH.whichChoice ROUTE TRANSLATE_2_DRAGGER_SCRIPT.translation_out TO SENSOR.set_offset } --PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com X-Zm-Content-Name: appearanceProtos.wrl Content-Description: Text Content-Type: text/plain ; name="appearanceProtos.wrl" ; charset=us-ascii #VRML V2.0 utf8 PROTO Magenta [] { Appearance { material Material { diffuseColor 0.8 0 0.266667 emissiveColor 0.102041 0 0.0340136 } } } PROTO Red [] { Appearance { material Material { diffuseColor 1.0 0 0.0 emissiveColor 0.1 0 0 } } } PROTO White [] { Appearance { material Material { diffuseColor 0.8 0.8 0.8 emissiveColor 0.1 0.1 0.1 } } } PROTO Yellow [] { Appearance { material Material { diffuseColor 0.8 0.8 0 emissiveColor 0.1 0.1 0 } } } PROTO Lavender [] { Appearance { material Material { diffuseColor 0.8 0 0.8 emissiveColor 0.102041 0 0.1 } } } PROTO Blue [] { Appearance { material Material { diffuseColor 0 0.710535 0.8 emissiveColor 0 0.0906295 0.102041 } } } PROTO RylonFlames [] { Appearance { material Material { diffuseColor .6 .6 1 emissiveColor .06 .06 .1 } } } --PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com X-Zm-Content-Name: geometryProtos.wrl Content-Description: Text Content-Type: text/plain ; name="geometryProtos.wrl" ; charset=us-ascii #VRML V2.0 utf8 # A crosshair shape, .3x.3x2 units PROTO ArrowheadGeom [] { IndexedFaceSet { coord Coordinate { point [ 0 .3 0, 1 .3 0, 1 -.3 0, 0 -.3 0, 1 .6 0, 1.5 0 0, 1 -.6 0] } coordIndex [ 0, 1, 2, 3, -1, 4, 5, 6, -1 ] solid FALSE } } PROTO VerticalNubbin [] { Box { size .05 .5 .15 } } # A skinny box, .5x.1x.1 PROTO Horizontal4UnitBar [] { Box { size 4 .1 .1 } } --PART-BOUNDARY=.19703031718.ZM23814.engr.sgi.com-- From cph@vesta.cms.dmu.ac.uk Mon Mar 3 22:50:07 1997 Return-Path: Received: from macondo.dmu.ac.uk by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id WAA15708; Mon, 3 Mar 1997 22:50:04 -0500 Received: from vesta.cms.dmu.ac.uk (root@vesta.cms.dmu.ac.uk [146.227.102.3]) by macondo.dmu.ac.uk (8.6.12/8.6.11) with ESMTP id DAA25459; Tue, 4 Mar 1997 03:44:16 GMT Received: from sargent.cms.dmu.ac.uk (cph@sargent.cms.dmu.ac.uk [146.227.102.121]) by vesta.cms.dmu.ac.uk (8.8.5/1.5V) with ESMTP id DAA06655; Tue, 4 Mar 1997 03:38:45 GMT From: Chris Hand Received: (from cph@localhost) by sargent.cms.dmu.ac.uk (8.8.5/1.4C) id DAA03624; Tue, 4 Mar 1997 03:38:37 GMT Message-Id: <199703040338.DAA03624@sargent.cms.dmu.ac.uk> Subject: Re: vrml-ui/vrml-widgets: Widget List To: pauli@uniblab.engr.sgi.com (Paul Isaacs) Date: Tue, 4 Mar 1997 03:38:37 +0000 (GMT) Cc: broehl@ece.uwaterloo.ca, sab@cs.brown.edu, joel@blacksun.com, bill@yisup.com, pell@newfire.com, sulam@construct.net, steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net, misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com, braden@shadow.net, michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@relay.engr.SGI.COM, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu, ouch@relay.engr.SGI.COM, thinktank@infomaniacs.com, robert@oz.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, vidinick@aol.com In-Reply-To: <9703031718.ZM23814@uniblab.engr.sgi.com> from "Paul Isaacs" at Mar 3, 97 05:18:34 pm Reply-To: cph@dmu.ac.uk X-Chris-Fax: +44 116 254-1891 X-Chris-Phone: +44 116 257-7498 X-Chris-WWW: http://www.cms.dmu.ac.uk/~cph/ Content-Type: text Status: RO I think my brain has just about recovered from the trip back to England, so here are some initial reactions to the discussion so far: * Selection doesn't mean "click" -- we need to make sure that our UI thinking allows for a wide variety of 3D input devices *properly* (as opposed to the passing references made in the VRML2.0 spec). Perhaps having a small number of usage scenarios would help to make this mindset more common, e.g. Michael has a mouse, Stephanie has a spaceball *and* mouse (TWO-HANDED INPUT IS NOT AGAINST THE LAW!) and Jaron is fully immersed with head-tracked HMD and a glove or two. :) * Creativity vs standards -- we definitely need to generate and evaluate some ideas/implementations soon. Since the results will be open, we need to create a "gene pool" to start with before we can have evolution... the successful creations will be adopted and may be improved by anyone who's interested. But having a standard set of tools is also pretty important, since (as Mark said) naive users want to grab stuff and start playing according to their expectations. So, I would suggest we can have both: there are some some obvious candidates for immediate implementation (mostly direct analogues of 2D widgets, e.g. sliders, buttons), but there is also a need for more complex, "less obvious" widgets which use or require 3D. For example, there are many flavours of bounding-box-with-graspable-handles-for-rotating-object in use or reported in the literature, with different functionality. We might implement several kinds of these and let people play with them for a while (or even -- gasp! -- get interested HCI people to perform proper user trials) before trying to standardise on them. As a comment on "stifling creativity", this was my original reaction, but remember: VRML users/programmers will always be able to extend nodes themselves (creatively), which isn't anywhere near so easy in most 2D GUIs. Personally I'm all in favour of ignoring UI standards when you want to, as long as you "know what you're doing" (Metatools stuff was a good example). * Our focus needs to include input devices and not just widgets (otherwise we'll all still be using mice, badly). Bernie's recent point about whether users make use of a virtual or a real trackball is *really important*. We must make sure that input devices and the interaction techniques used are abstracted apart in a suitable way. We should also encourage input device manufacturers to provide suitable nodes with their kit. At least one Input Device Guy I spoke to last week (Todd Yocum at Cybernet) says they intend to do this -- perhaps there's some input device forum we can infiltrate/influence...? * Structure of working groups: I think having too many groups may be counter-productive. On reflection I think a Widgets group (covering software objects for Object Manipulation, Viewpoint Manipuation and misc. other Application Control tasks) plus an Input Devices group might be enough, but we need to carefully work out what the nodes that each group produces will require of each other. Finally, to re-iterate comments from the UI panel: the last 10 years has seen *lots* of papers from SIGGRAPH, CHI, UIST and various graphics journals reporting results on 3D interaction techniques. It's really important that we BUILD on this work rather than starting from scratch. We really do have something to offer the 3D UI community *in general* here -- a portable platform for prototyping and experimenting with 3D interaction techniques and widgets. This is exactly what we need to accelerate the evolution of 3D interfaces. Chris -- Chris Hand, Senior Lecturer | Dept of Computer Science, e-mail: cph@dmu.ac.uk | De Montfort University, The Gateway WWW: http://www.cms.dmu.ac.uk/~cph/ | LEICESTER, UK LE1 9BH From gseidman Sun Mar 2 17:22:40 1997 Subject: Re: Widgets/UI/Navigation Working Group To: sab@cs.brown.edu (Sascha Becker) Date: Sun, 2 Mar 1997 17:22:40 -0500 (EST) In-Reply-To: <199703020110.UAA23882@point.cs.brown.edu> from "Sascha Becker" at Mar 1, 97 08:10:00 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2904 Status: RO } User Interface and/or Widgets and/or Navigation Working Group } } At VRML '97, Mark Pesce called for a standard of prototype widgets for } VRML 2.0. This idea triggered me to propose a "Widgets" working group, } which several people then suggested expanding to "User Interface" in } general. Dozens of people gave me their contact info and expressed } interest in that sort of working group. The question we now face is } how many working groups do we form, and what each group's focus should } be. I have widgets. I have been doing widgets. I like widgets. See http://zing.ncsl.nist.gov/~gseidman/vrml/widgets.html to take a look. } What, exactly, do I mean by VRML widgets? Here's a few ideas, with } influences from Inventor and the Brown Graphics Group, among others } * Heads-Up Display (HUD) I've tried working with this, but I've found it very difficult, particularly as an EXTERNPROTO. } * Forms (a la HTML) The difficulty with this is capturing keyboard input. The only standard way of doing this is with a Java window external to the VRML browser. This would require a spec change. } * Direct-Manip Geometries: vectors, line segments, points I have a Line-To kind of widget already. It works pretty well. It is available at the URL above. (A non-PROTO version that does not crash CosmoSGI 1.0.1 is available at http://zing.ncsl.nist.gov/~gseidman/vrml/comparison/linetest.wrl) } * Buttons: toggle, radio, push I have one kind of button that can be wired as radio buttons or toggle (I am not sure what you mean by push). I also have a light switch. } * Viewpoint manips This is not entirely clear to me. You mean something like the CosmoSGI Walk handle? } * Sliders I have several different kinds of sliders. } * etc. I also have a knob (like a car radio volume knob), a dial (like the volume dial on the front of many CDROM drives), an up-down widget (like a digital tuner control, which can be either continuous or discrete), and a Text popup thing (which is only sort of a widget). By the way, I would rename the above: Direct manipulation: viewpoint manipulators, movement of objects, etc. Boolean control: button, switch Continuous control: sliders, knob, dial, up-down Discrete control: switch, up-down, pop-up text ...and I would let the Visualization group continue working on the HUD, as they said they have been. } Please contact me at sab@cs.brown.edu if you are interested in } participating in a Widgets or UI working group-- I'm especially } interested in your ideas on how our efforts could best be } directed. I am interested. This is my favorite stuff. By the way, I applied to the Brown Graduate School in Computer Science and, if accepted, I would be delighted to work on this stuff with you. If you find the work I have done interesting and useful, please mention my name to appropriate people there. } -Sascha Becker } sab@cs.brown.edu --Greg From gseidman Mon Mar 3 23:40:41 1997 Subject: what I sent to Sascha To: cph@dmu.ac.uk Date: Mon, 3 Mar 1997 23:40:41 -0500 (EST) Cc: pauli@uniblab.engr.sgi.com, broehl@ece.uwaterloo.ca, sab@cs.brown.edu, joel@blacksun.com, bill@yisup.com, pell@newfire.com, sulam@construct.net, steve@division.com, brush@vnet.ibm.com, qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu, mikko.blomquist@cs.tut.fi, philippe@e-spaces.com, otto@interport.net, misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com, braden@shadow.net, michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@relay.engr.SGI.COM, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu, ouch@relay.engr.SGI.COM, thinktank@infomaniacs.com, robert@oz.com, philippe@vdi.com, jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, vidinick@aol.com X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 2706 Status: RO I sent this message to Sascha in response to the original message, and meant to give permission for it to be sent out to everyone. Here is what I sent: Subject: Re: Widgets/UI/Navigation Working Group To: sab@cs.brown.edu (Sascha Becker) Date: Sun, 2 Mar 1997 17:22:40 -0500 (EST) From: gseidman } User Interface and/or Widgets and/or Navigation Working Group } } At VRML '97, Mark Pesce called for a standard of prototype widgets for } VRML 2.0. This idea triggered me to propose a "Widgets" working group, } which several people then suggested expanding to "User Interface" in } general. Dozens of people gave me their contact info and expressed } interest in that sort of working group. The question we now face is } how many working groups do we form, and what each group's focus should } be. I have widgets. I have been doing widgets. I like widgets. See http://zing.ncsl.nist.gov/~gseidman/vrml/widgets.html to take a look. } What, exactly, do I mean by VRML widgets? Here's a few ideas, with } influences from Inventor and the Brown Graphics Group, among others } * Heads-Up Display (HUD) I've tried working with this, but I've found it very difficult, particularly as an EXTERNPROTO. } * Forms (a la HTML) The difficulty with this is capturing keyboard input. The only standard way of doing this is with a Java window external to the VRML browser. This would require a spec change. } * Direct-Manip Geometries: vectors, line segments, points I have a Line-To kind of widget already. It works pretty well. It is available at the URL above. (A non-PROTO version that does not crash CosmoSGI 1.0.1 is available at http://zing.ncsl.nist.gov/~gseidman/vrml/comparison/linetest.wrl) } * Buttons: toggle, radio, push I have one kind of button that can be wired as radio buttons or toggle (I am not sure what you mean by push). I also have a light switch. } * Viewpoint manips This is not entirely clear to me. You mean something like the CosmoSGI Walk handle? } * Sliders I have several different kinds of sliders. } * etc. I also have a knob (like a car radio volume knob), a dial (like the volume dial on the front of many CDROM drives), an up-down widget (like a digital tuner control, which can be either continuous or discrete), and a Text popup thing (which is only sort of a widget). By the way, I would rename the above: Direct manipulation: viewpoint manipulators, movement of objects, etc. Boolean control: button, switch Continuous control: sliders, knob, dial, up-down Discrete control: switch, up-down, pop-up text ...and I would let the Visualization group continue working on the HUD, as they said they have been. [...] } -Sascha Becker } sab@cs.brown.edu --Greg From bill@yisup.com Tue Mar 4 13:00:47 1997 Return-Path: Received: from proxy2.ba.best.com by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id NAA26452; Tue, 4 Mar 1997 13:00:45 -0500 Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy2.ba.best.com (8.8.5/8.8.3) with ESMTP id JAA07120; Tue, 4 Mar 1997 09:51:18 -0800 (PST) Received: from [206.86.217.60] (demolish.vip.best.com [206.86.217.60]) by shellx.best.com (8.8.5/8.8.3) with ESMTP id JAA29223; Tue, 4 Mar 1997 09:49:33 -0800 (PST) X-Sender: demolish@best.com Message-Id: In-Reply-To: <199703032134.QAA12120@point.cs.brown.edu> References: Your message of "Mon, 03 Mar 1997 15:44:26 EST." <199703032044.PAA02300@watt.uwaterloo.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 4 Mar 1997 09:51:28 -0800 To: Sascha Becker , Bernie Roehl From: Bill Enright Subject: vrml-widgets: base funtionality Cc: joel@blacksun.com, pell@newfire.com, sulam@construct.net, steve@division.com, brush@vnet.ibm.com, cph@dmu.ac.uk, qwang@nist.gov, jean-francis.balaguer@cern.ch, munzner@cs.stanford.edu, philippe@e-spaces.com, otto@interport.net, misty@well.com, matsuda@arch.sony.co.jp, shags@nortel.com, pauli@sgi.com, braden@shadow.net, michaelp@netscape.com, kluster@sgi.com, riccardo.fiorentino@ktx.com, gb@sgi.com, dea@media.mit.edu, jde@tomedii.demon.co.uk, dfa4y@virginia.edu, slk@sgi.com, houck@watson.ibm.com, w.e.baskin@larc.nasa.gov, matt@cicadaweb.com, rob@engr.sgi.com, erik_chaum@code20.nuwc.navy.mil, bill@lcinc.com, athomas@mrl.nyu.edu, ouch@engr.sgi.com, thinktank@infomaniacs.com, robert@oz.com, gseidman@zing.ncsl.nist.gov, philippe@vdi.com, jch@jch.com, bl@pobox.com, 3isa@qlink.quensu.ca, vidinick@aol.com, john.martellaro@lmco.com, rcg@rd.engr.sgi.com, mpesce@netcom.com, jonpruyn@inkstone.com, sab@cs.brown.edu Status: RO Take a look at the basic Mac (I know, I know) control manager. Controls can= be defined as these *things* that output a range of values when= manipulated. There's a way to plug in your own representations for parts= of these controls, but the basic function stays the same. The system uses= the control manager to create the standard look and feel, but if you wanna= break the rules, the api is there to be hacked. How do we describe the basic functionality of a widget in such a way that we= can build the various widgets from the basic functionality. Perhaps we can= create or simply describe the equivalent of a Control Manager that lets us= build the various widgets we need on top of it. Would this help? Is this= possible? I believe that it 1) would help and 2) is possible. If I had a= simple package of VRML 2.0 nodes (perhaps minus the geometries) that let me Show and Hide=20 Draw/Update Handle Events/Track (from arbitray source(s)) Move/Resize Plug In different control and tracking functions (i.e. custom, not standard= ) Set Min/Max values Then I'd have a nice, working, consistent framework. My creativity would be= happily stifled and I would rule the world. =3D8^o bill@yisup.com From pauli@uniblab.engr.sgi.com Tue Mar 4 18:34:35 1997 Return-Path: Received: from sgi.sgi.com by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id SAA09857; Tue, 4 Mar 1997 18:34:28 -0500 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 PAA18987 for <@sgi.engr.sgi.com:gseidman@zing.ncsl.nist.gov>; Tue, 4 Mar 1997 15:34:23 -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 PAA04705 for <@cthulhu.engr.sgi.com:gseidman@zing.ncsl.nist.gov>; Tue, 4 Mar 1997 15:34:23 -0800 Received: (from pauli@localhost) by uniblab.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id XAA27594 for gseidman@zing.ncsl.nist.gov; Tue, 4 Mar 1997 23:34:22 GMT From: "Paul Isaacs" Message-Id: <9703041534.ZM27592@uniblab.engr.sgi.com> Date: Tue, 4 Mar 1997 15:34:22 -0800 In-Reply-To: gseidman@zing.ncsl.nist.gov (Gregory Seidman) "what I sent to Sascha" (Mar 3, 11:40pm) References: <199703040440.XAA16119@zing.ncsl.nist.gov> X-Mailer: Z-Mail (3.2.3 08feb96 MediaMail) To: gseidman@zing.ncsl.nist.gov (Gregory Seidman) Subject: Re: what I sent to Sascha Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Status: RO Greetings Kindred Spirit, >> I have widgets. I have been doing widgets. I like widgets. Ditto. I'm the guy who wrote the Inventor dragger/manipulator stuff, as well as the 3D widgets for CosmoWorlds. >> See >> http://zing.ncsl.nist.gov/~gseidman/vrml/widgets.html to take a look. I just took a look at the website you mentioned in your posting. Great stuff! Hopefully I'll get a chance to read your paper as well. I'm working on some related-but-different stuff and if you like I'll let you know as I put things out on my website. Keep up the good work! 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. From vrml-ui-owner@vag.vrml.org Wed Mar 5 04:46:49 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id EAA12707; Wed, 5 Mar 1997 04:46:47 -0500 Received: from proxy3.ba.best.com (root@proxy3.ba.best.com [206.184.139.14]) by kether.vrml.org (8.7.5/1.0) with ESMTP id JAA02087 for ; Wed, 5 Mar 1997 09:41:57 GMT Received: from shellx.best.com (shellx.best.com [206.86.0.11]) by proxy3.ba.best.com (8.8.5/8.8.3) with ESMTP id BAA26961 for ; Wed, 5 Mar 1997 01:40:51 -0800 (PST) Received: from [206.86.217.60] (demolish.vip.best.com [206.86.217.60]) by shellx.best.com (8.8.5/8.8.3) with ESMTP id BAA29570 for ; Wed, 5 Mar 1997 01:40:26 -0800 (PST) X-Sender: demolish@best.com Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Mar 1997 01:42:22 -0800 To: vrml-ui@vag.vrml.org From: Bill Enright Subject: REPOST: base functionality Status: RO Take a look at the basic Mac (I know, I know) control manager. Controls can= be defined as these *things* that output a range of values when= manipulated. There's a way to plug in your own representations for parts= of these controls, but the basic function stays the same. The system uses= the control manager to create the standard look and feel, but if you wanna= break the rules, the api is there to be hacked. How do we describe the basic functionality of a widget in such a way that we= can build the various widgets from the basic functionality. Perhaps we can= create or simply describe the equivalent of a Control Manager that lets us= build the various widgets we need on top of it. Would this help? Is this= possible? I believe that it 1) would help and 2) is possible. If I had a= simple package of VRML 2.0 nodes (perhaps minus the geometries) that let me Show and Hide=20 Draw/Update Handle Events/Track (from arbitray source(s)) Move/Resize Plug In different control and tracking functions (i.e. custom, not standard= ) Set Min/Max values Then I'd have a nice, working, consistent framework. My creativity would be= happily stifled and I would rule the world. =3D8^o bill@yisup.com From vrml-ui-owner@vag.vrml.org Wed Mar 5 14:31:33 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id OAA24409; Wed, 5 Mar 1997 14:31:32 -0500 Received: from xanadu.oz.com (root@[207.105.191.57]) by kether.vrml.org (8.7.5/1.0) with ESMTP id TAA06749 for ; Wed, 5 Mar 1997 19:25:21 GMT Received: from robofly by xanadu.oz.com (8.8.3/OZnet/12-01-97); Wed, 5 Mar 1997 13:31:30 -0800 Message-Id: <3.0.32.19970305232639.008d6730@xanadu.oz.com> X-Sender: robert@xanadu.oz.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 05 Mar 1997 23:26:40 -0800 To: vrml-ui@vag.vrml.org From: Robert Bjarnason Subject: Open standards Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO Hi, Prove of point> We should prove that VRML Widgets can be used with VRML, and other open Internet standards to create compelling consumer ($) content/product's. Future of 3D Widgets in general> How will Microsoft and other large scale Widgets distributors react to this innovative, there are high stakes. What is Windows 95 now (Widgets/Devices/DOS/Network)? With warm regards, Robert Vidar Bjarnason Ambassador robert@oz.com From vrml-ui-owner@vag.vrml.org Fri Mar 7 13:23:08 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id NAA23073; Fri, 7 Mar 1997 13:22:56 -0500 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by kether.vrml.org (8.7.5/1.0) with SMTP id SAA08882 for ; Fri, 7 Mar 1997 18:13:54 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 KAA12140 for <@sgi.engr.sgi.com:vrml-ui@vag.vrml.org>; Fri, 7 Mar 1997 10:15:05 -0800 Received: from rd.engr.sgi.com (rd.engr.sgi.com [198.29.108.114]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id KAA29965 for <@cthulhu.engr.sgi.com:vrml-ui@vag.vrml.org>; Fri, 7 Mar 1997 10:15:04 -0800 Received: (from rcg@localhost) by rd.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id KAA10616; Fri, 7 Mar 1997 10:15:03 -0800 Date: Fri, 7 Mar 1997 10:15:03 -0800 From: rcg@rd.engr.sgi.com (Rich Gossweiler) Message-Id: <199703071815.KAA10616@rd.engr.sgi.com> To: vrml-ui@vag.vrml.org Subject: widgets Reply-To: rcg@sgi.com Status: RO A while back I made some simple widgets which I put on my web-page and gave to the world, no strings attached. I think the push-button and the toggle-button need a re-write, but the slider is good-to-go. I set up my page to have a GIF image of the widget, a stand-alone proto (for easy inclusion into your world) and an example world using the widget: Scroll down to the widget section of http://reality.sgi.com/rcg/vrml/vrmlIndex.html ----- Rich Gossweiler (rcg@sgi.com) MS 982 http://reality.sgi.com/rcg 415.933.6572 The opinions I express are my own and do not necessarily reflect those of my company. From vrml-ui-owner@vag.vrml.org Sat Mar 8 04:28:53 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id EAA28390; Sat, 8 Mar 1997 04:28:51 -0500 Received: from xanadu.oz.com (root@[207.105.191.57]) by kether.vrml.org (8.7.5/1.0) with ESMTP id JAA24523 for ; Sat, 8 Mar 1997 09:27:13 GMT Received: from robofly by xanadu.oz.com (8.8.3/OZnet/12-01-97); Sat, 8 Mar 1997 01:28:26 -0800 Message-Id: <3.0.32.19970308132840.008dc740@xanadu.oz.com> X-Sender: robert@xanadu.oz.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Sat, 08 Mar 1997 13:28:41 -0800 To: From: Robert Bjarnason Subject: Re: [vrml-ui] Sounds like we're getting somewhere Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Status: RO Hi, >--------------------------------------------- >Re: Working Group Charter > >Sascha Becker wrote: >> ...we should be building a set of >> public-domain, fully-functional, customizable 2D and 3D >> widgets which are amenable to arbitrary input devices. > >This seems to be a great first cut at a charter statement. >Here's my attempt at a little more generalized one: > >The VRML User Interface Working Group has been formed to provide insights, >expertise and examples of VRML 2.0 user interfaces. By providing a freely >distributable set of professional quality, fully-functional, highly >customizable user interface widgets and worlds, the Working Group hopes to >foster exciting advances in the area of immersive 3D user interface design. Goals> * Define a standard for arbitrary input devices. * Implement adaptive AI into our widgets. * Work with artists to create compelling look & feel. * Cooperation with the VRML binary format WG in terms of response time. * Encourage browser developers to move their UI-widgets into VRML. >I would really hate to see "cyberspace" have a tired and worn user >interface cast upon it. There are so many great new ideas, let's not be too >hasty in suggesting that what we have today is good enough for the next >decade. The Desktop is dead. Deal with it. I hope we will see much diversity in 3D UI-widgets in soon, you should be able to switch widgets and still continue to work in the same application. If this is going to be realized in the future, we need some kind of a standard/framework on some level for people to start building on ? With warm regards, Robert Vidar Bjarnason Ambassador robert@oz.com From vrml-ui-owner@vag.vrml.org Sat Mar 8 12:26:16 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id MAA04329; Sat, 8 Mar 1997 12:26:14 -0500 Received: from r2d2.mcom.com (h-205-217-237-47.netscape.com [205.217.237.47]) by kether.vrml.org (8.7.5/1.0) with ESMTP id RAA26841 for ; Sat, 8 Mar 1997 17:23:35 GMT Received: from dredd.mcom.com (dredd.mcom.com [205.217.237.54]) by r2d2.mcom.com (8.7.5/8.7.3) with ESMTP id JAA22959 for ; Sat, 8 Mar 1997 09:24:15 -0800 (PST) Received: from jch-isdn.mcom.com ([205.217.243.40]) by dredd.mcom.com (Netscape Mail Server v2.02) with SMTP id AAA2789; Sat, 8 Mar 1997 09:24:15 -0800 Message-ID: <3321768B.78DB@netscape.com> Date: Sat, 08 Mar 1997 09:24:11 -0500 From: jch@netscape.com (Jan Hardenbergh) Reply-To: jch@netscape.com Organization: Netscape Communications X-Mailer: Mozilla 3.01Gold (Win95; I) MIME-Version: 1.0 To: Robert Bjarnason CC: vrml-ui@vag.vrml.org Subject: Re: [vrml-ui] Sounds like we're getting somewhere References: <3.0.32.19970308132840.008dc740@xanadu.oz.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Status: RO > >decade. The Desktop is dead. Deal with it. Has everyone checked out Gelentner's Life Streams? Written up in WIRED, netgrep it. It has a very intuitive post WIMP interface to information streams. The globe, etc. > I hope we will see much diversity in 3D UI-widgets in soon, you should be > able to switch widgets and still continue to work in the same application. > If this is going to be realized in the future, we need some kind of a > standard/framework on some level for people to start building on ? There are two forces, one which wants to make EXTERNPROTOs for a bunch of standard widgets - sliders, box draggers, etc... One interfaces are clear, the visual & interactions methods can be varied, but the VRML App does not need to change. Hey, we could be talking about a VRML style sheet, soon. -- YON jch@netscape.com / "If you spend enough time talking to the Jan Hardenbergh / Martians, everything becomes clear" Tamara Munzner www.arts.gla.ac.uk/IPA/ipa.html From vrml-ui-owner@vag.vrml.org Tue Mar 11 20:38:33 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id UAA07809; Tue, 11 Mar 1997 20:38:32 -0500 Received: from cs.brown.edu (cs.brown.edu [128.148.128.2]) by kether.vrml.org (8.7.5/1.0) with ESMTP id BAA14241 for ; Wed, 12 Mar 1997 01:35:01 GMT Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id UAA03503 for ; Tue, 11 Mar 1997 20:36:14 -0500 (EST) From: Sascha Becker Received: (sab@localhost) by point.cs.brown.edu (8.8.3/BrownCS1.0) id UAA21291 for vrml-ui@vag.vrml.org; Tue, 11 Mar 1997 20:36:09 -0500 (EST) Date: Tue, 11 Mar 1997 20:36:09 -0500 (EST) Message-Id: <199703120136.UAA21291@point.cs.brown.edu> To: vrml-ui@vag.vrml.org Subject: a proposal for a widget repository Status: RO Mike Pell and I have been talking offline, and have come up with an outline of a user interface element repository. We see this repository as a deliverable from this group; we would still call the group vrml-ui, but initially focus on developing this repository. The group would be responsible for designing and creating the repository and associated technology, as well as a core set of a dozen or so widgets as examples of how to use the repository. The community at large would then submit widgets to the repository; the wg would catalogue widget submissions (hopefully a lightweight task) according to what they do and to what degree they fit the suggested framework. We expect that the members of this working group would in fact be the principal contributors to the repository, but want the repository to be open to submissions from all corners. The Problem: - Not enough people know how to build interesting or good vrml widgets - It's unecessarily hard to add a self-revealing user interface to VRML worlds. - Some people have lots of insight, and are willing to make their efforts public, but their efforts are distributed all over the web, not easy to find - Also, their efforts follow a diverse API. we'd like a consistent framework. - We want to foster community expertise in developing 3D user interface design - ... and make VRML a platform that 3D ui designers choose for their research and experimentation Our proposal: A suggested framework for reusable widgets, including: - fields for positioning, scaling, showing, hiding widgets - API for getting and setting values on valuator widgets - javadoc-style documentation (automatic documentation generation) - plug-in geometry for author customization A repository of: - reusable, customizable widgets & ui elements, either meeting the framework above or not - sample world files showing the widgets in use - insights into widget writers' design decisions - insights into widget writers' implementation strategies - resources for widget/ui designers Why this is a good thing: - The framework would provide widget developers with a template for each new widget, thus reducing the cost of widget development. - Widgets that adhere to the framework standards would be highly interoperable. A world author would not need to rely on a single vendor for all his widgets; instead he could simply plug in geometry with a unified look. - The widget source would show people how to hack their own widgets. Sample code is a fantastic way to learn. - Common widget behaviors could be abstracted out, allowing world authors to customize geometry without touching code. If more control is desired, the author can hack the widget source and build their own widget. - The designers' description of why they did what they did, and the resource list, would help spread UI design knowledge to the VRML community. Issues: - Where do we draw the line betwen generally smart objects and user interface elements? - Versioning: what happens if I update my slider, which you use? what happens if I change a field name? - There is strong support on the list for dealing with input devices and navigation. to what degree, and how, should the widget repository address these issues? - Since each browser supports different languages for internal messaging, a completely accessible widget would need three parallel implementations, one for each of VRMLScript, JavaScript, and Java. - Does the flexibility inherent in the framework design cause a performance hit? -Sascha sab@cs.brown.edu From gseidman Tue Mar 11 22:55:54 1997 Subject: Re: choosing a chair or co-chairs To: vrml-ui@vag.vrml.org (vrml user interface) Date: Tue, 11 Mar 1997 22:55:54 -0500 (EST) In-Reply-To: <199703120146.UAA21400@point.cs.brown.edu> from "Sascha Becker" at Mar 11, 97 08:46:01 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 1454 Status: RO } I'm interested in chairing or co-chairing this working } group, whether it comes out to Widgets or User Interface } or whatever. Is anyone else interested in chairing or } co-chairing? I would be interested in co-chairing. I don't think I could be the one and only chair, however. My bio is not quite as impressive as Sascha's, but I have produced ten or eleven working VRML widgets. Bio: I'm a senior CS major at University of Maryland College Park and accepted (and going to) Brown University for grad school (in their Graphics Group, I assume/hope). I intend to get a Ph.D. with work in (3D) HCI. I've worked at NIST for the last three years and messed with user interfaces in everything from PHIGS to World Toolkit using a dataglove to VRML widgets. } For those of you who joined the list after my initial post, } here's my bio again: } I'm a senior at Brown University, concentrating in Computer Science, } particularly graphics and human-computer interaction. I've worked } on several 3D interaction techniques as part of my participation } in the Brown Graphics Group (http://www.cs.brown.edu/research/graphics) } and worked with VRML for two summer internships, first at SGI where } I worked on WebSpace Author, then at Intervista where I developed } VRML 2.0 demos. I'm about to go work at First Virtual (www.fv.com) } where I'll be creating VRML advertisements which require ui to } support in-scene transactions. } } -Sascha --Greg From vrml-ui-owner@vag.vrml.org Tue Mar 11 20:47:14 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id UAA07863; Tue, 11 Mar 1997 20:47:13 -0500 Received: from cs.brown.edu (cs.brown.edu [128.148.128.2]) by kether.vrml.org (8.7.5/1.0) with ESMTP id BAA14290 for ; Wed, 12 Mar 1997 01:44:51 GMT Received: from point.cs.brown.edu (point.cs.brown.edu [128.148.33.134]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id UAA03649 for ; Tue, 11 Mar 1997 20:46:06 -0500 (EST) From: Sascha Becker Received: (sab@localhost) by point.cs.brown.edu (8.8.3/BrownCS1.0) id UAA21400 for vrml-ui@vag.vrml.org; Tue, 11 Mar 1997 20:46:01 -0500 (EST) Date: Tue, 11 Mar 1997 20:46:01 -0500 (EST) Message-Id: <199703120146.UAA21400@point.cs.brown.edu> To: vrml-ui@vag.vrml.org Subject: choosing a chair or co-chairs Status: RO I'm interested in chairing or co-chairing this working group, whether it comes out to Widgets or User Interface or whatever. Is anyone else interested in chairing or co-chairing? For those of you who joined the list after my initial post, here's my bio again: I'm a senior at Brown University, concentrating in Computer Science, particularly graphics and human-computer interaction. I've worked on several 3D interaction techniques as part of my participation in the Brown Graphics Group (http://www.cs.brown.edu/research/graphics) and worked with VRML for two summer internships, first at SGI where I worked on WebSpace Author, then at Intervista where I developed VRML 2.0 demos. I'm about to go work at First Virtual (www.fv.com) where I'll be creating VRML advertisements which require ui to support in-scene transactions. -Sascha From gseidman Thu Mar 13 17:31:42 1997 Subject: Re: a proposal for a widget repository To: vrml-ui@vag.vrml.org (vrml user interface) Date: Thu, 13 Mar 1997 17:31:42 -0500 (EST) In-Reply-To: <199703131454.JAA13422@watt.uwaterloo.ca> from "Bernie Roehl" at Mar 13, 97 09:54:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3926 Status: RO } 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. } > - 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). } > - javadoc-style documentation (automatic documentation generation) Hrm. A bit more difficult. I'm rather inclined to have documentation external to the definition, especially since one can expect that these widgets will be sent over the net as EXTERNPROTOs and the smaller the file, the quicker the transfer. } > - 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. } 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. Absolutely. I suggest we develop a widget taxonomy including discrete vs. continuous, data types, etc. } > Issues: } > - Versioning: what happens if I update my slider, which you } > use? what happens if I change a field name? } } So long as everything that worked before the change continues to work, } it's just a better version of the same widget. If you change field } names or alter the functionality in some way, it should be considered } to be a new widget. It would be very nice if there were some way to } do the equivalent of "subclassing" using VRML, but there's not. There is subclassing in VRML, though it is perhaps not as clear. If you want to add something to a widget, include an instance of the widget in a new PROTO. There is no such thing as public subclassing, but IS allows private subclassing (sorry, I'm taking a very thorough object-oriented class this semester). } > - Since each browser supports different languages for internal } > messaging, a completely accessible widget would need three parallel } > implementations, one for each of VRMLScript, JavaScript, and Java. } } I would say forget about VRMLScript; it's just an offshoot of JavaScript, } and SGI has indicated they'll be migrating towards JavaScript instead. And I would say forget about JavaScript unless you absolutely need something from it. VRMLscript is easier to implement that JavaScript and, since VRMLscript is designed to be a proper subset of JavaScript, any browser that runs JavaScript runs VRMLscript. } That does mean that widgets will still need two implementations, but I } think that should be left up to the author of the widget. Our widget } collection should clearly indicate which language (if any) is required } for each widget. I have implemented all of my widgets in both VRMLscript and Java. I find the translation very easy with practice. The differences in API are not terribly big (e.g. adding a setValue() or getValue() for Java), and going from functions named for events and a single event-handling function is not a big deal either. (Yes, I develop with VRMLscript and port to Java.) 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. } Bernie Roehl --Greg From vrml-ui-owner@vag.vrml.org Thu Mar 13 17:33:14 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id RAA07377; Thu, 13 Mar 1997 17:33:12 -0500 Received: from zing.ncsl.nist.gov (zing.ncsl.nist.gov [129.6.84.33]) by kether.vrml.org (8.7.5/1.0) with SMTP id WAA07638 for ; Thu, 13 Mar 1997 22:30:32 GMT Received: by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id RAA07365; Thu, 13 Mar 1997 17:31:43 -0500 From: gseidman@zing.ncsl.nist.gov (Gregory Seidman) Message-Id: <199703132231.RAA07365@zing.ncsl.nist.gov> Subject: Re: a proposal for a widget repository To: vrml-ui@vag.vrml.org (vrml user interface) Date: Thu, 13 Mar 1997 17:31:42 -0500 (EST) In-Reply-To: <199703131454.JAA13422@watt.uwaterloo.ca> from "Bernie Roehl" at Mar 13, 97 09:54:34 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Status: RO } 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. } > - 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). } > - javadoc-style documentation (automatic documentation generation) Hrm. A bit more difficult. I'm rather inclined to have documentation external to the definition, especially since one can expect that these widgets will be sent over the net as EXTERNPROTOs and the smaller the file, the quicker the transfer. } > - 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. } 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. Absolutely. I suggest we develop a widget taxonomy including discrete vs. continuous, data types, etc. } > Issues: } > - Versioning: what happens if I update my slider, which you } > use? what happens if I change a field name? } } So long as everything that worked before the change continues to work, } it's just a better version of the same widget. If you change field } names or alter the functionality in some way, it should be considered } to be a new widget. It would be very nice if there were some way to } do the equivalent of "subclassing" using VRML, but there's not. There is subclassing in VRML, though it is perhaps not as clear. If you want to add something to a widget, include an instance of the widget in a new PROTO. There is no such thing as public subclassing, but IS allows private subclassing (sorry, I'm taking a very thorough object-oriented class this semester). } > - Since each browser supports different languages for internal } > messaging, a completely accessible widget would need three parallel } > implementations, one for each of VRMLScript, JavaScript, and Java. } } I would say forget about VRMLScript; it's just an offshoot of JavaScript, } and SGI has indicated they'll be migrating towards JavaScript instead. And I would say forget about JavaScript unless you absolutely need something from it. VRMLscript is easier to implement that JavaScript and, since VRMLscript is designed to be a proper subset of JavaScript, any browser that runs JavaScript runs VRMLscript. } That does mean that widgets will still need two implementations, but I } think that should be left up to the author of the widget. Our widget } collection should clearly indicate which language (if any) is required } for each widget. I have implemented all of my widgets in both VRMLscript and Java. I find the translation very easy with practice. The differences in API are not terribly big (e.g. adding a setValue() or getValue() for Java), and going from functions named for events and a single event-handling function is not a big deal either. (Yes, I develop with VRMLscript and port to Java.) 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. } Bernie Roehl --Greg 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. From vrml-ui-owner@vag.vrml.org Fri Mar 14 10:42:41 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id KAA16317; Fri, 14 Mar 1997 10:42:39 -0500 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by kether.vrml.org (8.7.5/1.0) with SMTP id PAA12655 for ; Fri, 14 Mar 1997 15:33:20 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 HAA17442 for <@sgi.engr.sgi.com:vrml-ui@vag.vrml.org>; Fri, 14 Mar 1997 07:34:28 -0800 Received: from rd.engr.sgi.com (rd.engr.sgi.com [198.29.108.114]) by cthulhu.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) via ESMTP id HAA05901 for <@cthulhu.engr.sgi.com:vrml-ui@vag.vrml.org>; Fri, 14 Mar 1997 07:34:28 -0800 Received: (from rcg@localhost) by rd.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id HAA25577; Fri, 14 Mar 1997 07:34:27 -0800 Date: Fri, 14 Mar 1997 07:34:27 -0800 From: rcg@rd.engr.sgi.com (Rich Gossweiler) Message-Id: <199703141534.HAA25577@rd.engr.sgi.com> To: vrml-ui@vag.vrml.org (vrml user interface) Subject: Tris-stratificiation In-Reply-To: <9703131820.ZM4575@uniblab.engr.sgi.com> References: <199703132231.RAA07365@zing.ncsl.nist.gov> <9703131820.ZM4575@uniblab.engr.sgi.com> Reply-To: rcg@sgi.com Status: RO Another advantage to Pauli's tri-stratification is that I find myself making at least two types of widgets: efficient ones (bare minimum polygon count, functional) and more visually pleasing ones. Both could stem from the same middle-level class that Pauli described. I also find myself building widgets that affect one simple aspect (a floating point value, a vec3f or a color) and using these building-block atomic widgets as input to compound "filter" scripts that take some set of input types and produce different output types (e.g. floats to vec3f). So that is a useful division for me (atomic and compound/filters). So useful are little time-widgets (pulse a time-beat or alarm-trigger a time after X seconds) that I include these in my atomics, even though they are not necessarily user-driven. Given some coverage with the atomics and filters, it is pretty easy to string these widgets together. Paul Isaacs writes: | 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. From vrml-ui-owner@vag.vrml.org Fri Mar 14 11:57:14 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id LAA17264; Fri, 14 Mar 1997 11:57:13 -0500 Received: from sgi.sgi.com (SGI.COM [192.48.153.1]) by kether.vrml.org (8.7.5/1.0) with SMTP id QAA13373 for ; Fri, 14 Mar 1997 16:53:35 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 IAA06885 for <@sgi.engr.sgi.com:vrml-ui@vag.vrml.org>; Fri, 14 Mar 1997 08:54:50 -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 IAA17762 for <@cthulhu.engr.sgi.com:vrml-ui@vag.vrml.org>; Fri, 14 Mar 1997 08:54:49 -0800 Received: (from pauli@localhost) by uniblab.engr.sgi.com (950413.SGI.8.6.12/960327.SGI.AUTOCF) id QAA06692; Fri, 14 Mar 1997 16:54:44 GMT From: pauli@uniblab.engr.sgi.com (Paul Isaacs) Message-Id: <199703141654.QAA06692@uniblab.engr.sgi.com> Subject: Re: Tris-stratificiation To: rcg@sgi.com Date: Fri, 14 Mar 1997 08:54:44 -0800 (PST) Cc: vrml-ui@vag.vrml.org In-Reply-To: <199703141534.HAA25577@rd.engr.sgi.com> from "Rich Gossweiler" at Mar 14, 97 07:34:27 am X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 8bit Status: RO > > > Another advantage to Pauli's tri-stratification is that I find myself > making at least two types of widgets: efficient ones (bare minimum > polygon count, functional) and more visually pleasing ones. Both could > stem from the same middle-level class that Pauli described. At either the middle-level or high-level, all geometry needs to be replaceable for use as you describe. The middle level is for "move one thing this one way." Here I picture the fields having names like 'translation' and 'rotation,' to reflect this. It's at the higher level where we wrap it up to be a valuator, or bundle it with other parts/widgets. And it's at this higher level where fields might more reflect their use with names like 'sliderValue,' 'diffuseColor' (where this is actually an aggregate culled from 3 separate sliders) etc. > I also find myself building widgets that affect one simple aspect (a > floating point value, a vec3f or a color) and using these building-block > atomic widgets as input to compound "filter" scripts that take some set of > input types and produce different output types (e.g. floats to > vec3f). So that is a useful division for me (atomic and compound/filters). These 'filter' scripts are the kind of thing Gregory Seidman examines in the paper he posted. He also broaches the topics of logic gates and an arithmentic calculator. > > So useful are little time-widgets (pulse a time-beat or alarm-trigger a > time after X seconds) that I include these in my atomics, even though > they are not necessarily user-driven. Yes! I agree. The time sensor can be programmed to do lots of different things. Wrapping these up into specifically tuned PROTOS is a whole other useful category. So let's see, we got a whole bunch of 'atomic' elements coming up: TimeControls Draggers Gates TypeConverters MathFunctions What other 'pet categories' do people have? Do any of you out there dislike this way of thinking? Why? What other approaches might we take? pauli. From gseidman Fri Mar 14 15:28:35 1997 Subject: Pluggable geometry To: vrml-ui@vag.vrml.org (vrml user interface) Date: Fri, 14 Mar 1997 15:28:35 -0500 (EST) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 950 Status: RO Well, okay, I revamped my widgets so that they (some of them) can take geometry as exposedFields. For some it was important that the geometry passed in be an SFNode for the geometry field in a Shape, but wherever possible the geometry is an MFNode exposedField. The revamping has broken a couple of the PROTOs, the Button and LightSwitch in particular, under CosmoSGI 1.0.1. In any case, if you haven't taken a look at http://zing.ncsl.nist.gov/~gseidman/vrml/refer.wrl yet (look at the source, don't bother browsing it), you probably should. I have the appropriate EXTERNPROTO references (listing all fields/events) for essentially every PROTO I have made available. Note that the PROTOs do not break under Liquid Reality, though there is some weirdness with the Mapping PROTO, possibly a bug in my Java code. Demos of the widgets themselves (using only default geometry) remain at http://zing.ncsl.nist.gov/~gseidman/vrml/widgets.html --Greg From gseidman Fri Mar 14 16:55:59 1997 Subject: Twisting extrusion as widget To: vrml-ui@vag.vrml.org (vrml user interface) Date: Fri, 14 Mar 1997 16:55:59 -0500 (EST) Cc: www-vrml@vag.vrml.org (vrml) X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 661 Status: RO Okay, so at the suggestion of the VRML-UI mailing list I have revamped several of my widgets to have geometry fields allowing real customization of the widgets. Yeah, sure, it works, but a slider is a slider no matter how it works, right? Well, no, not exactly, not if it is a Nifty Twisty Thingy as well. For those of you who enjoyed the original Nifty Twisty Thingy, I now bring you the TwistSlider (which, I suppose, could become a PROTO at some point if there is any demand). see http://zing.ncsl.nist.gov/~gseidman/vrml/twistsliderdemo.wrl It is nothing more than my BoxSlider with the geometry replaced. Take a look at the source for details. --Greg From sab@cs.brown.edu Mon Mar 17 23:46:37 1997 Return-Path: Received: from cs.brown.edu by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id XAA23456; Mon, 17 Mar 1997 23:46:35 -0500 Received: from poplar.cs.brown.edu (poplar.cs.brown.edu [128.148.38.3]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id XAA07170; Mon, 17 Mar 1997 23:46:29 -0500 (EST) Received: from cs.brown.edu (localhost [127.0.0.1]) by poplar.cs.brown.edu (8.7.1/BrownCS1.0) with ESMTP id XAA01854; Mon, 17 Mar 1997 23:46:27 -0500 (EST) Message-Id: <199703180446.XAA01854@poplar.cs.brown.edu> X-Mailer: exmh version 1.6.6 3/24/96 To: gseidman@zing.ncsl.nist.gov cc: sab@cs.brown.edu Subject: vrml-ui biz-buzz Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Mar 1997 23:46:27 -0500 From: Sascha Becker Status: RO Hi Greg-- So, looks like we're gonna be co-chairs-- cool! I hear you'll be visiting Brown soon; we should definitely sit down and hammer stuff out f2f. I'll be at JavaOne from April 1-6, and moving to San Diego in late April; it'd be good if you could come up before that. As far as I can tell, the big thing we need to do as co-chairs now is to come up with a charter-- that would be especially good to do f2f, IMHO. Also, the CHI'97 meeting is coming up-- will you be attending? (I won't.) Either way, we need to come up with an agenda for that meeting, and it'd be good if we could have the proposed charter for them to discuss there. Mike Pell will be there, and he's agreed to lead the meeting. Right now, where would you like to see the group go? Or, as Don B. is fond of saying, "what does success look like?" To me, the widget repository we're talking about is "success," or rather, an implementation of the widget repository that addresses these needs/problems: - plug-n-play geometry - well-documented sample code - widgets that are written with a behavior model amenable to living worlds and maybe the db work group - iron out the inherent problems of widgetry design in VRML enough that it is a solid platform for 3d ui designers. - input device-friendly widgets - widgets that are easily composable, either into functional or spatial groups - a set of core widgets that demonstrates how the widget repository is supposed to work - widget categories according to both function and level in Pauli's stratification Last thing to deal with is, pretty soon we should name ourselves co-chairs-- this is probably an announcement that you should make, so people start to get a feel for you as one of the mechanics leaders, too. If you're up for that, how about running a draft of that email by me-- I don't think it'll be politically sensitive with this nice bunch of folks, but it's worth being careful about. FYI, my home phone is 401 274-9699, and my work fone is 401 863 7693, and I'm generally available noon to late, late night-- give a call if you want to talk. -Sascha From vrml-ui-owner@vag.vrml.org Tue Mar 18 01:33:54 1997 Return-Path: Received: from kether.vrml.org by zing.ncsl.nist.gov (SMI-8.6/SMI-SVR4) id BAA24031; Tue, 18 Mar 1997 01:33:53 -0500 Received: from cs.brown.edu (cs.brown.edu [128.148.128.2]) by kether.vrml.org (8.7.5/1.0) with ESMTP id GAA05891 for ; Tue, 18 Mar 1997 06:31:40 GMT Received: from poplar.cs.brown.edu (poplar.cs.brown.edu [128.148.38.3]) by cs.brown.edu (8.8.5/8.7.1) with ESMTP id BAA08783 for ; Tue, 18 Mar 1997 01:32:52 -0500 (EST) From: Sascha Becker Received: (sab@localhost) by poplar.cs.brown.edu (8.7.1/BrownCS1.0) id BAA04332; Tue, 18 Mar 1997 01:32:49 -0500 (EST) Date: Tue, 18 Mar 1997 01:32:49 -0500 (EST) Message-Id: <199703180632.BAA04332@poplar.cs.brown.edu> To: vrml-ui@vag.vrml.org Subject: [vrml-ui] more on the Tri-Stratification of Widget Components Status: RO I want to try to re-state Pauli's widget stratification with some changes of my own, characterize each level according to whether or not it is spatial, visible, and mathematical, and then present some examples of components in each category. This kind of classification suggests a component-based widget architecture, which just makes me endlessly happy. * Level 1 is for "surfaces I use to intersect the mouse"-- these objects are spatial, and invisible, and for the most part non-mathematical (the browser does the math, not the VRML object.) They output spatial information, but in general it's raw spatial information, in object-space, unbounded, unmonged. Time controls can also fit in here, I think. * Level 2 is for "things that move in a particular way", or, to restate, "a simple way to interpret level 1 widget output." This level maps from one representation of spatial, object-space information to another, more constrained representation of the same information, ie, (to use Pauli's example), from representing the point of the click-ray's intersection with a SphereSensor as translation to representing it as a rotation. Changing the representation includes clamping the values, disallowing certain actions based on state, and changing discrete values into continuous. In Pauli's presentation, this level has geometry associated with it, though I think all the geometry should be inserted in Level 3; I don't see why you need geometry here, and in fact the geometry may depend on what the third level does (ie, the slider's thumb color changes as you drag.) This level filters the values input from Level 1 to create bounded dragging behavior. Filter scripts and compound-building scripts fit in to this level. It is purely mathematical, not sitting in space anywhere or having any associated geometry, assuming that the Level 1 widget will output a value in normalized object-space. This level determines the "feel" of a widget. * Level 3 is the first "useful" level of widgets-- I'm having a hard time coming up with a succinct phrase to describe this level. It maps from Level 2 widget output into the user-specified "space," ie, a value in between min and max for a slider. It also adds geometry (inactive in Pauli's stratification, both inactive and active i