(I wrote this in a private email to Reed, but I think it is of general interest).
What I have in mind could almost be a sort of "desktop" for VOS, providing a general framework for providing visualization and interaction for vobjects. Thinking about it in that way, it might be desirable to split different views into different processes, so they don't conflict with each other and a crash doesn't take down the whole system... That approach would make it kind of like a window manager or display server. I'm thinking something like: vos io -> abstract handling of input and output vos 2d -> retained mode drawing using the SVG data model vos 3d -> rendering based on A3DL data model (as we come up with it) vos gui -> Abstract GUI controls represented using SVG or A3DL VOS I/O is something we I haven't mentioned, but we will need a layer that explicitly knows about key/mouse input events, and provides an abstract representation for different means of output (character stream, text console, graphical 2D and 3D panes). I need to sit down and write some prototype code to explore this idea more. I'll probably hack out a GUI prototype with "fake" vobjects that provide core functionality without all the asynchronous communication/concurrency/network transparency features that will be in the real VOS. The week of June 9th I am officially part time, so that's when I hope things will get going. On Fri, Jun 29, 2007 at 09:09:36AM -0400, Reed Hedges wrote: > > I think we do need modes for keybindings, and I like the general tool idea. > The GUI should not neccesarily be directly mapped to mode.n ia fixed > configuration though. Instead, there should be a set of GUI elements (side > panes, etc.) for each mode, but they should be flexible in that you can bring > up other GUI elements, minimize elements, and it should remember that layout > configuration for the next time you enter that mode. And, mode transitions > should be tools/bound actions. For example, you define in configuration that > middle mouse click means to "select" an object, and also enter editing mode > with that object selected. By entering edit mode, the GUI layout for that > mode would be displayed, which might include window panes with different > toolboxes or information about the object displayed. But maybe you want some > panes to always be visible in all modes, etc.; maybe you want to hide the > chat > pane while you're in edit mode or minimize it so that there's a little button > on the edge of the screen that brings it back, etc. > > I think tool panes/sidebars that you optionally float and move or iconify are > a > useful way to present buttons, tools, and object trees that makes them easily > accessible and viewable. > > (We should also definately adopt Firefox's method of displaying background > notifications and non-modal dialog boxes by inserting them above or below the > main viewing area rather than as popups :) > > Reed > > > _______________________________________________ > vos-d mailing list > vos-d@interreality.org > http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d -- [ Peter Amstutz ][ [EMAIL PROTECTED] ][ [EMAIL PROTECTED] ] [Lead Programmer][Interreality Project][Virtual Reality for the Internet] [ VOS: Next Generation Internet Communication][ http://interreality.org ] [ http://interreality.org/~tetron ][ pgpkey: pgpkeys.mit.edu 18C21DF7 ]
signature.asc
Description: Digital signature
_______________________________________________ vos-d mailing list vos-d@interreality.org http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
