Am 27.06.2007 um 05:55 schrieb Peter Amstutz: > I've been quiet, but that doesn't mean I haven't been thinking > about VOS > development. I'll try to describe some of the things I've been > working > on recently. > > Most importantly, starting July 9th, I will be devoting half of my > time > (2-3 full days each week) to VOS development. Coding, which has been > stalled for awhile, will resume at that point. > Great to hear, things have been too quiet lately.
> In the mean time, I have been fleshing out various s5 design > details in > my mind. The main subjects have been: > > - Scalability, clustering and recovery from failure. The general > ideas > is to use replication for load balancing and distributed locks for > consistancy control. > This sounds like a radical redesign... so far we had a single local vobject acting as a sequencer for multiple remote vobjects. Obviously, you have something new in mind. Please tell us more :-) > - Programming with continuations as a way of supporting concurrency > without requiring threads. Also how to emulate continuations in > languages that don't support them! > > - Authorization-based access control using object capabilities. I am > still planning to write an email discussing capability security in > VOS. > I remember the discussion about these topics a while back. I'm looking forward to see what has become of them. Again, please tell us more! > - User interface for the 3D client. This is a critical issue on > which > we have spent too little time in the past. > > Let me talk a little bit about the last part. This time around, I'm > going to try and have a prototype 3D client in place even before we've > finished writing the core. That way, we have (hopefully) something > people can play with while development of the underlying network > object > model proceeds. > > I've spent a little while thinking about the interaction mode of the > client, and came up with a few basic principals to follow: > > * It must be very open-ended. The goal is for the application to be > able to configure itself to different task, be it a 3D game, social > space or business purpose. > > * It should be usable by both novices who want a minimal browsing > experience, and experts who are engaged in scene editing or > development. > > * It should be designed to permit plugins or extensions to its > functionality. > I would go a bit further here - use plugins as the *basis* of the software! The main client only needs to provide capabilities for displaying (layered) 3D content and manage plugins. Everything else should be in the plugins themselves. See below... > The model we have been using up until now has been the web browser, > but > it occurred to me that although familiar, this may not be the right > model. Now, what is a highly popular application that is suitable for > both viewing and editing, and is open ended... I think the right > model > is Emacs! > Ok, I am not an Emacs user, so I may not understand your idea in its entirety. Still... > I've put together a mockup screenshot here: > http://interreality.org/~tetron/terangreal%20mockup.png > Looks like Safari! :-) I thought you wanted something different than a web browser? In particular, what use are Tabs here? After all, interacting with a 3D world is about immersion, i.e. you interact with only one virtual reality. It is not at all like sorting thrrough files and shuffling multiple documents around on your desk, so it seems like the wrong metaphor here. Apart from that, it looks like you intend the interface to be purely 2D. Why restrict ourselves to that? Why not a separate 3D overlay, driven by a VOS graph in the same manner as the main 3D world? We discussed this stuff before, this seems to require just a few minor engine features like resetting the z buffer and so on. This solution would make for a much more flashy look in any case - who wants 2D icons if you can have true 3D icons, possibly with animations and all? > At the top, like a web browser, you have the current URL (a vobject) > which you are interacting with. > Well, URLs were originally never intended to be visible in the original browser concepts. In fact, only very few of them are memorizable (http://interreality.org) and suitable for typing in as a starting point of a session. Most others include horribly long paths and cryptic parameters required by the webapp logic behind them. These are not helpful, you dont really want to see them at all. IMO the entire top half including bookmark buttons sould be the display part of a tool plugin, just like everything else, and should only show up if you select this particular tool. > In the upper right corner, you have the "major mode" which defines how > what type of interface to use to present the vobject. For a 3D scene, > you might have a "navigation" major mode used for normal browsing and > chatting, a "construction" major mode which provided controls for > adding > objects and moving objects around. If you clicked on a mesh, you > could > go into an "editing" major mode which allowed for editing polygons and > vertices of an individual mesh. If you selected a material, you could > go into a "material" mode for editing the material properties. > > In addition to these specialized modes, you would have generic major > modes, such as presenting a hierachical tree view of the vobject > structure, or editing text properties. > Let me see if I got that right. A mode is just an (editable) preset of tools to activate/show, associated with a number of vobject types. So whenever you select a particular vobject through the navigation tool, you compare its types to known modes and select the best match? If so, I am not sure what the mode stack in your mockup is for. > Additional major mode could embed a web browser or other document > viewers and editors, operating on resources stored in Vobjects or > on the > web. Ultimately, the system should be entirely reflexive, so that the > user interface is itself described using VOS; this would allow > creating > both 2D and 3D applications within the platform. > Well, ok, but don't make it a priority. There are a lot of fine web browsers and document readers out there already, no need to reinvent the wheel - at least, not just now. So maybe display capabilities should be plug-ins too, though of a different kind than the interaction tools. Let's call them extensions. > The major mode broadly defines how a particular vobject tree is > presented to the user and provides a base set of key and mouse > bindings. > In addition to this, you have minor modes and tools. > > A "tool" would be a piece of code which can be bound to a key or mouse > action. It might operate on the currently selected item, ask the user > for input, or just execute some action. The major mode would > specify a > base set of tool bindings. A tool would be somewhat similar to an > Emacs > interactive function, in that new tools could be defined on the fly > and > would operate on the current environment. Tools which only worked > with > the underlying vobject would also be usable across different major > modes, enabling the user to reuse the same commands even with entirely > different frontend interfaces. > > A "minor mode" would be a set of key or mouse bindings that is > overlayed > on the current major mode. Usually, the user would enter a minor mode > by using a tool. > > For example, the user wishes to grab and rotate a 3D object. The use > the "rotation" tool. This invokes a "rotation" minor mode which > changes > the mouse bindings to allow the user to click and drag to rotate the > object in question. When the user is done, the "rotation" minor mode > removed and the previous mode is restored. > > Under this design, a 3D game would supply a minor mode providing a > complete set of key bindings to the game controls, such as binding the > number keys to "tools" which cast spells. > Sounds fine, the only problem I see is how to determine that the user is done with the current tool/minor mode. There sould be a consistent and obvious way for the user to signal that. The current mode should only be effective in the "main" part of the browser, with an unobtrusive reserved "mode selection" area that is always available and re-grabs mouse/keyboard bindings if you move the mouse over to it or hit ESC or something. > In short, I'm envisioning a sort amalgamation of Firefox, Emacs and > Blender, possibly with some Visual Studio-style detachable "pop-out" > windows (using wxAUI) thrown in for good measure. > > It's crazy, but it just might work. > Amen. Regards, Karsten Otto _______________________________________________ vos-d mailing list [email protected] http://www.interreality.org/cgi-bin/mailman/listinfo/vos-d
