Ensmer -- Proposed 3D desktop environment

Dusty · 2004-09-30 17:18:14

This isn't exactly an Arch contribution, but from lively discussions I've seen here, I'm sure that there are many Arch users that might be interested in it.

I'm beginning work on an open source three dimensional user interface called Ensmer for a school project. I haven't got any source code yet, but I can guarantee that there will be some (or I don't pass the course).

I'm currently looking for feedback on the small bit of design I have posted and am hoping to create a small (or large, what the hell?) developer/user/feedback community as I work. Here's the website I've created so far... that is, here's the website I'm in the process of building. I figured I'd release early to get early feedback.

http://io.acad.athabascau.ca/~dustyp/comp495/

If you're interested in research in 3D development, or in the future of the desktop interface, I'd appreciate some feedback on what you think. Feedback can go here or straight to my e-mail address (pick one, like dusty@archlinux.org) for now. If there is enough discussion, I'll probably set up a forum later on, or maybe even an (ugh) mailing list.

At the moment, I am working on a project proposal that I will be submitting to my professor in a week or two. Don't expect too much public release as I work on it, but I may update the site if I come up with new ideas while working on the proposal.

Thanks for feedback and discussion.

Dusty

madhatter · 2004-09-30 19:53:36

hi,
sun is working on an open-source 3d user interface in java, too:
http://wwws.sun.com/software/looking_glass/

seems that they first working on integrating 2d apps in a 3d world, but afaik they'll add 3d apps

Dusty · 2004-09-30 20:35:20

I am aware of Looking Glass, I even wrote a document to get it running on Arch Linux: http://www.archlinux.org/~dusty/lookingglass.html

I'm looking at a much more involved virtual world with Ensmer, along the lines of science fiction. I confess that I didn't spend a lot of time looking at the LG3D code, yet, however.

Dusty

phrakture · 2004-09-30 21:07:08

well, I understand it's for school, but let me just say "a DE in java... ewww"

I'd personally write it in C/C++ using the ogre 3d libs...

aCoder · 2004-10-01 02:53:29

geez... There goes Dusty revolutionizing the way we use computers, isn't that just so predictable?

I'm glad to see you've seem to put a focus on the way user interation is handled, (or, if I misinterpreted, you should). This is a typical serious flaw in interface design, and I could see this setting a new standard if you manage to get it right.

Also, I agree with phrakture, Java!? There must be a reason, is it technical or just a requirement for the course? I'd love to hear a good argument for Java, especially on something like this, since the only good things I here are from raving lunatics trying to design a CPU that understands Java or a Java OS...

cactus · 2004-10-01 03:24:22

well, with java there is the benefit of more rapid prototyping, and if that is what he knows, then there is a change that he can actually get something done...
holy crap! what a concept!
being a cs grad student myself, I sypathize with wanting to complete something for a grade.

As for advice, I would recommend generating a base set of classes that perform the work for you (ie, given an input size, a class creates a window (pane), and hands off control of the pane to another class). That way, once you have the pane code done, you can effectively forget about it.
If you make it so that you can just hand it a name, size, etc., etc., then you can have it generic enough to get it going.
If you need more from it, you can, in true oo-design, just extend the hell out of it with classes and inheritance (java uses multiple inheritance by interfaces with java 1.4...don't know much about java5, except that it has generics..).

I always thought doing gui in java was like pulling your own teeth with a 2x4, while being blindfolded...but you might be hampered by external constraints, knowledge constraints (like I have..i don't know much about drawing in X for instance...always use a toolkit..).

Best of luck...if you get to a point where you can accept further input, or can provide additional details, let us know.
8)

[edit]
Doh! just found the links at the top of the page on your site...commence reading!
[/edit]

phrakture · 2004-10-01 14:33:49

let add to my previous statement:
java is not bad, as of 1.4 the speeds are comparable to c++... according to many benchmarks...
however, java does not have hardware access and most likely does not work very well with current GPUs...
I'm pretty sure the graphical side isn't as good as the other stuff, though I'd have to look up some numbers on it.... perhaps you can design it and later on, if performance is an issue, strap in some C graphical engine code.... dunno. I'd suggest making the rendering engine extensible enough to be able to change the underlying code (replace it with some C extensions later is performance is a problem)

Dusty · 2004-10-01 16:56:25

I'd just as soon avoid the Java debate. My main reason for choosing it is that I have to finish this course in a certain amount of time, and Java is faster to develop than C or C++, especially for someone like me who happens to have mastered Java. The second reason is Java 3D, which is, for me, much easier to code than OpenGL. Contrary to phrakture's statement, it does have direct access to the graphical hardware, as it uses native code to interact with OpenGL OR DirectX (OR potentially other 3D systems). I'll admit that running a JVM is slower than running a compiled app directly, but Java 5 has gone a long ways in speeding this up, and I use the same argument in support of the wasted cycles that people use for Python.

cactus: thanks for the advice. I think I understand it. I'm pretty good with OOP. Since its going to be in Java 3D, I can't quite just forget about the pane (A Canvas3D - its a pain as well as a pane...) because half the classes need acess to it. In my previous attempts, I tried very hard to separate the J3D code from the manipulation code, but J3D isn't well enough designed to support that (if I had time, I'd probably be studying JOGL or Python's Soya3D or even traditional OpenGL itself instead...) But I know Java 3D so I'm using it.

As for further input, I'm about 3/4 done the first draft of my project proposal. I don't know if it would be ethical to release this for feedback (isn't it just like having multiple proofreaders?????), but I think I'll do it.

Totally off topic, perhaps best answered in a private message, tell me more about being a grad student. I'm debating whether to enter the work force when I graduate or pursue further studies... Info from a current grad student might help with this point.

Dusty

EDIT: One more thing, anybody have any ideas for JUnit testing Java3D code?

rasat · 2004-10-01 17:14:42

cactus wrote:

well, with java there is the benefit of more rapid prototyping, and if that is what he knows, then there is a change that he can actually get something done...
holy crap! what a concept!

Its an interesting concept and I am keen to follow it's development. To develop it, not an easy task, I would not put priority in choosing the "right" prog language but in any as long as does the job. The first stage is to implement the concept not final product. Later stage is for the perfection.

phrakture · 2004-10-01 19:32:14

yeah java is much quicker to develop in.

and I apologize, I was not aware that Java 3D interacted directly with DirectX or OpenGL... that's pretty cool.

If you have time, seeing as I'm prolly not as good with Java, let alone Java 3D, as you - maybe you could hack together a glxgears clone - jgears... just so I could see for myself.

and yes, java 5 is cool - I had to laugh when people who do know c++ saw generics and were like "wow what an awesome idea" - welcome back c++ templates! (c# is getting the same functionality in .NET 2.0 too)....
yet c++ templates are still much more powerful, as I can do many things with meta-programming that no other language can do, period..... but I digress...

keep us informed of the work you do man... if you ever get stuck or need a hand let us know, I'm sure many could help ya out.

and about the grad student thing - I skipped it for now... I did Computer Engineering, not science... right now I work in IT (barf) but when my career changes and expands a bit, I'll be going to grad school.
Only advice, if you haven't had any practical workforce experience yet, don't go to grad school - many employers look at people who go straight to grad school w/o work experience as "overqualified and error prone" - practival experience will do you much more good in the long run...

Dusty · 2004-10-01 19:45:53

phrakture wrote:

If you have time, seeing as I'm prolly not as good with Java, let alone Java 3D, as you - maybe you could hack together a glxgears clone - jgears... just so I could see for myself.

Time is pretty tight, I think this project is bigger than I expected.

I believe there is an FPS type application in Java 3D in the Java 3D examples: https://j3d-examples.dev.java.net/

On the second note, I finished a rather clunky first draft of my project proposal:

http://io.acad.athabascau.ca/~dustyp/co … posal.html

I'm most interested in feedback on the logical design section, as parts of it seem... illogical. Also, any questions will be welcome, as I don't think I've explained myself thoroughly in some areas.

I want to write and submit the final draft on Monday, so feedback over the weekend will be best. I'll update the page as I receive feedback.

Dusty

phrakture · 2004-10-01 19:58:49

Hmmm interesting high level design. I'd be really curious to see some detail on this (yeah I know I'll have to wait).

I actually like the physics engine you described, with the gradual drift... and the purpose of it... sounds really good.

Although more detailed than the current design, let me ask a few questions - first off, will the central control module contain the scene graph, or will that be a separate module? Would it be possible to see some sort of flowchart for the event model. I am not sure I understand what you're describing (it'd be good for the documentation too). And on another note, how will state be persisted? Memory? disk? database? I'd be curious to know what you'd be using and why.

Now, I don't fully understand the 3D desktop paradigm, so letme ask a lame question - let's say I have my "run xterm" object... i set it up to look like a big penguin in the 3d world... so I walk over to my penguin and, say, double click him... how/where does the xterm display.... is it a 2D window floating in space that i can walk up to and interact with?

Another thing that came to mind, I am assuming you are going to use some type of 3d model file for objects... the icon paradigm on a 2d desktop.... any thought on the format?

Ok that's all I have for now...

Dusty · 2004-10-02 00:50:56

phrakture wrote:

I actually like the physics engine you described, with the gradual drift... and the purpose of it... sounds really good.

I implemented something like that in a prototype I developed earlier. The navigation and physics models impressed the hell out of me. It works really well, so I'll probably be using the same theory (totally different code, however) in this one.

- first off, will the central control module contain the scene graph, or will that be a separate module?

I've tried various methods of separating Java 3D scenegraph code from the rest of the application, but it just doesn't seem to work. It will probably not be in the central module, but I don't think it will all be in its own module either...

From what you're saying, I don't think I've described how the frontends will work well enough. Basically, they will be permitted to create a BranchGroup that is added to the scenegraph by whatever (hmmm... apparently I haven't thought about this part much) code interacts with the user.

Would it be possible to see some sort of flowchart for the event model. I am not sure I understand what you're describing (it'd be good for the documentation too).

Quite frankly, I am absolutely lost when it comes to writing or reading diagrams. Apparently I'm not a very visual person or something. Even more frankly, I've been subconciously avoiding this question because I'm not totally sure what I'm doing here. This is why I wanted feedback, it forces me to confront these issues!

I'll try to describe it in words for now and then I'll update the logical design to include such words or possibly a diagram later.

All low level input events will be processed by the central event module. At the moment, I'm only talking about keystrokes and mouse events, since that's all I've got for input here. So in the diagram, we'd have input events on the left with an arrow pointing to the event module.

The central event module then processes the event depending on the current mode. I didn't describe the mode system very well either... chalk it up to the TODO list.

Basically there are three modes, not necessarily exclusive. The foremost mode is navigation mode. In this mode, movements of the mouse will move the user view as described in the design. There is no mouse pointer; the mouse movements are directly related to the user. I get the feeling this wouldn't work too well on a mouse where moving the user far forward would entail moving the mouse off the pad, pick it up, pull it back, and move forward again, but it works REALLY WELL with a trackball. So I'm sticking with it because I have a trackball and love it and highly recommend it for any 3 dimensional interactions.

Inputs to this mode will be forwarded by the event processor to the navigation module where they are processed.

The second mode is selection mode. In this mode, the user has a mouse pointer and can move in in the traditional plane on screen. They can click the mouse over an object to select it. They can select multiple objects in this way. Certain inputs in this mode will manipulate (rotate, move, scale) the selected objects within the world.

Inputs to this mode will be forwarded to... hmmm. I dunno. Some sort of object manipulation parser I haven't put any thought into yet. Thanks for bringing it up.

The third mode is object mode. In this mode, inputs are forwarded directly to a single selected object. Mouse presses will be forwarded to the object frontend, which will determine (magically, *sigh*) if any significant portion of the object was 'hit' and then invoke some action on the backend. This might be used to press representations of buttons on the object or for invoking some action, etc. Keypresses will probably be forwarded through the frontend as well, but might be forwarded directly to the backend for processing.

I don't want to go into that much detail in my formal proposal, but I should put a little better description of the multi-modal format.

And on another note, how will state be persisted? Memory? disk? database? I'd be curious to know what you'd be using and why.

I had considered both database and disk. I even thought of making it basically a GUI frontend to a fully object oriented database, but that didn't seem flexible enough, somehow.

At the moment, I'll probably just save state to disk because its easy. (compared, for example, to JDBC).

In previous attempts, I've tried serializing the J3D scenegraph. That was the worst programming experience of my life. That's why I'm planning on leaving the saving of state up to the backend, it kind of takes the problem out of my hair, plus it leaves the backend room to work as it likes; for example some backends will interact with database or network, while others will stick to the disk. All Ensmer will have to save is the location and some identifier of each object; that will be to disk.

Frontends will not be serialized, they should be designed to set up their view wholly from the state of the backend they interact with. I think I need better words than frontend and backend here, now I think of it.

Now, I don't fully understand the 3D desktop paradigm, so letme ask a lame question - let's say I have my "run xterm" object... i set it up to look like a big penguin in the 3d world... so I walk over to my penguin and, say, double click him... how/where does the xterm display.... is it a 2D window floating in space that i can walk up to and interact with?

Forget the 3D desktop paradigm, with Ensmer; I'm leaving that up to Project Looking Glass and Longhorn's Avalon.

My interface will be more directly interacting with objects, not programs. xterm is a program that does various things. In my world, there will be an object associated with each of these various things to do the tasks.

Frankly, I think this plan could undo the whole project because its what they tried to do with the 2D interface, everything is an icon... but that doesn't work efficiently, that's why so many of us are staunch CLIers (me more than anybody). However, making everything an object instead of an icon is a big difference because now the objects have both state and behavior.

Further, I want to avoid there being any objects in Ensmer that interact directly with the filesystem. The problem with files is that they are just data, no behavior... not object oriented. I want Ensmer to bring the user *above* the filesystem.

This of course, is a way in the far future vision.

Another thing that came to mind, I am assuming you are going to use some type of 3d model file for objects... the icon paradigm on a 2d desktop.... any thought on the format?

Its not going to use specific single objects like an icon is just an image. The look of the object will depend on the data. Think of how KDE allows you to preview certain files in the icon, only in Ensmer, the object won't just be a preview, it will be the entire object.

This is why the frontends need to be scripted. I'm thinking of Beanshell or Jython (can't decide, can't decide...) code that basically creates a BranchGroup or other SceneGraph object depending on the backend data. Thus, two frontends should not look exactly the same unless the backend data is identical.

I don't want frontend development to be too much of a chore, but it will at the least have to support interpreting mouse events. One nice thing about using scripting is that it is possible to make quite intricate 3D scripts, but also possible to keep things simple.

Thanks for the feedback!

Dusty

cactus · 2004-10-02 04:49:45

I recommend creating a requirements specification document.

This will give you a chance to more formally lay out what you want it to do. You will be able to see exactly what facets it will require, and likely the creation of the document will bring further understanding in your mind about any aspects that might be cloudy.

For example:
Interface definition (loose at first, becomes more firm with revisions)
Functional requirments
Process descriptions
Constraints
etc.

As for the quote about grad school, that definately applies towards PHd programs. Master's degrees are often considered to be "work force" degrees, as apposed to "research" degrees that PHd degrees are considered.
If you have projects (such as this) on your resume--showing actual processes like creation of documentation, requirements specifications, etc.
Along with familiarity with industry tools and procedures (configuration management, release-miestering, CASE, UML, etc.)
And with a reasonable Master's degree, you will be very attractive to employers.

Especially if you can show that you know what the hell you know... Being able to knock out a grip of code in C or C++ doesn't amount to a super lot anymore..it is good, but coders are a dime a dozen almost. It is the higher level understanding that can set you apart.
Understanding of algorithms, processes, real world knowledge of design and project experience..these are the things many people are looking for it seems.

Besides, once the architecture, design, documentation, and formal specs are done, many companies are outsourcing the code monkeying....

<some of this is my opinion, some is impirical evidence>
*take everything with a grain of salt, it is your life, do with it as you choose*

rasat · 2004-10-02 06:10:50

Dusty wrote:

Forget the 3D desktop paradigm, with Ensmer; I'm leaving that up to Project Looking Glass and Longhorn's Avalon.
My interface will be more directly interacting with objects, not programs.

To click a 3D icon instead of 2D, will be boring/frustrating in long run when expectation is higher. Highly attractive but do nothing more than usual..... typical MS style. Glad that's not Ensmer.

For my information, could Ensmer be said its a 3D navigation enabling to interact with the programs from different angle - not visually, but as per the priority of need or usage. The structure and modules are setup/configured by the user.

Dusty · 2004-10-02 17:14:04

rasat wrote:

For my information, could Ensmer be said its a 3D navigation enabling to interact with the programs from different angle - not visually, but as per the priority of need or usage. The structure and modules are setup/configured by the user.

I'm not certain I understand the question?

I'd rather say that users won't be interacting with 'programs' anymore. Think of monolithic programs like an e-mail application. I would rather the user had only to interact directly with objects representing e-mails. They don't have to organize them into the e-mail client's folders; they can keep e-mails related to one project in an area of the world dedicated to that project, and e-mails related to another project in that project's area of the world. Address book information would be the same. There are PIM programs that try to interact with other programs, but they don't work very well. Better to have an object representing each person you know, with various indicators of their address and other information.

cactus: could you explain this requirements specification document in more detail? How does it differ from this proposal? Is there a link describing what such a document should contain?

I want to have a fairly complete design at the logical level, but I'm planning on trying to use iterative development for the coding, rather than the traditional physical design then implementation procedure (everybody knows this doesn't work, ask Linus. ).

Dusty

wdemoss · 2004-10-02 19:18:57

I had considered both database and disk. I even thought of making it basically a GUI frontend to a fully object oriented database, but that didn't seem flexible enough, somehow.

Check out http://www.prevayler.org/wiki.jsp, a simple object database base. Just a thought.

-wd

cactus · 2004-10-02 19:47:44

Dusty wrote:

cactus: could you explain this requirements specification document in more detail? How does it differ from this proposal? Is there a link describing what such a document should contain?
I want to have a fairly complete design at the logical level, but I'm planning on trying to use iterative development for the coding, rather than the traditional physical design then implementation procedure (everybody knows this doesn't work, ask Linus. ).
Dusty

http://www.tuffley.aust.com/tcs20001.htm
Just did a google, haven't had a chance to look at how good of an example it is...

Requirements specs are interative (or at least, they should be). Requirements should fit into any development process. In fact, it is one of the things that QA use. Test cases are built off the requirments, or at least, they should be.
There is nothing wrong with doing design first. the key is whether or not you can go back and modify the design. Traditional methods (waterfall) did not allow this. Current iterative models do. Extreme, RUPP, and many other banana-throwing-monkey-processes.

I will check the link if I have time. So, it might be useful, it might now...
was just a quick googling for "requirments specification"

Dusty · 2004-10-02 21:05:50

wdemoss: thanks for the link, I find it very interesting. I'll research it some more next week. If it actually is what I am understanding it to be, it might be just what I'm looking for.

cactus: That link they want to charge you for, but I did a similar search on google and found some templates. I think it might be a little too formal for me, because there's no customer. That is, the developer (me) is the customer (me), so we don't have to communicate (well, I *do* talk to myself frequently, but usually I understand what I'm saying...). Perhaps I just don't know how to solidify my plans that much without code.

However, I have been thinking of writing some informal (plain language so that non-developers know what I'm talking about) use-case scenarios and similar. I do have the formal requirements summarized in the proposal, but they're at a pretty high level compared to the details requested by these requirements docs.

Dusty

cactus · 2004-10-02 23:05:23

hmm...yeah, bad link.
sorry bout that...

here is one that I did quite a while ago...I just found it again today...it was sitting in an old cvs repo..lol
http://www.solarblue.net/docs/RSD.pdf

rasat · 2004-10-03 05:11:45

Dusty wrote:

However, I have been thinking of writing some informal (plain language so that non-developers know what I'm talking about) use-case scenarios and similar.

To make it into a cool presentation, what's really all about and how it works, maybe you already thought about it, make also a live CD.

Dusty · 2004-10-04 20:22:55

I've rewritten the proposal from scratch; this is basically my final copy:
http://io.acad.athabascau.ca/~dustyp/co … posal.html

I believe its a lot more understandable and readable than the first version.

I'll be submitting it later today. I haven't checked it over for spelling or grammar errors yet (like to let it sit a while before I do that), so feel free to play the grammar nazi too (yeah, its time to turn the tables on Dusty...).

I'll be writing up some non-technical use cases later; these will be designed to introduce the project to non-programmers. I'll post them when I get them finished.

I'm going to test prevayler tomorrow and research some other libraries that I might want to use. I hope to start coding on Wed or Thur and to have a very hardly useable release up by Monday. Assuming I can get CVS access somewhere (my university is supposed to be seting it up, but I'm going to apply for project status at either sourceforge or java.net (unless somebody can tell me about a open source service that provides subversion access *besides* berlios.de...) as well.

Thanks for any further feedback and questions.

Dusty

wdemoss · 2004-10-04 23:32:34

You got me wondering about the os subversion hosting, after a quick search I could only find http://www.cvsdude.org/ which offers subversion hosting also.

-wd

cactus · 2004-10-05 00:49:56

why subversion?
Why not cvs..for simple single person use it would seem supirior just because you can get it so many places, and it is easy to use..
If you need something more complex (ie distributed), why not use something good like gnu arch?

http://wiki.gnuarch.org/moin.cgi/SubVer … Comparison

I tried SVN, just didn't like it very much. The fact that it runs as a webdav folder always seemed like a pain. I found it harder to setup than CVS as well...
but, to each their own....

svn does have some good plusses over cvs though..
http://subversion.tigris.org/
just for single user, cvs works fine for me..and for something bigger, I think I would go for gnu-arch..

Dusty · 2004-10-05 03:32:42

first: wdemoss, thanks for the link. That's two extremely potentially useful links you've given me now.

Edit: I found another subversion host, oriented to open source projects:
http://svnhosting.org/index.php?option= … &Itemid=26
I'd really like to find something running gforge, but only found alioth (debian only) and objectweb (middleware only).

cactus: I like subversion's client side interface, and the web access seems intelligent to me. Dunno about the server side stuff, never really thought about it. Xentac originally got me started on subversion, and since then I find CVS to be kind of clunky when I try to use it. He's also recommended arch to me, but I have no experience with it. I'm adding it to my list of things to research tomorrow (tomorrow is research and experiment day).

Now, the real news. I made a couple very minor changes to the project proposal and submitted it to my supervisor.

I've written another introductory document that is meant to be oriented to non-technical users. I want to capture the interest of people that don't know what 'scenegraph' or even 'java' means. It's organized as a collection of informal use cases... I think a lot of people might find it interesting:

http://io.acad.athabascau.ca/~dustyp/co … cases.html

I'm very interested in both technical and nontechnical opinions and feedback on these, as well as possible other use cases that might help define the requirements of the system.

Thanks to everyone that has questioned my design so far! I'm amazed at how well the feedback has solidified some of the more difficult issues in my head... its gone from "something I might be able to pull off" to "something I can do", and I haven't even started coding yet. I'm deeply indebted to you guys already. As repayment, I've decided to give free copies of the finished product to... everybody and anybody!!! *applause*

Dusty

Arch Linux

#1 2004-09-30 17:18:14

Ensmer -- Proposed 3D desktop environment

#2 2004-09-30 19:53:36

Re: Ensmer -- Proposed 3D desktop environment

#3 2004-09-30 20:35:20

Re: Ensmer -- Proposed 3D desktop environment

#4 2004-09-30 21:07:08

Re: Ensmer -- Proposed 3D desktop environment

#5 2004-10-01 02:53:29

Re: Ensmer -- Proposed 3D desktop environment

#6 2004-10-01 03:24:22

Re: Ensmer -- Proposed 3D desktop environment

#7 2004-10-01 14:33:49

Re: Ensmer -- Proposed 3D desktop environment

#8 2004-10-01 16:56:25

Re: Ensmer -- Proposed 3D desktop environment

#9 2004-10-01 17:14:42

Re: Ensmer -- Proposed 3D desktop environment

#10 2004-10-01 19:32:14

Re: Ensmer -- Proposed 3D desktop environment

#11 2004-10-01 19:45:53

Re: Ensmer -- Proposed 3D desktop environment

#12 2004-10-01 19:58:49

Re: Ensmer -- Proposed 3D desktop environment

#13 2004-10-02 00:50:56

Re: Ensmer -- Proposed 3D desktop environment

#14 2004-10-02 04:49:45

Re: Ensmer -- Proposed 3D desktop environment

#15 2004-10-02 06:10:50

Re: Ensmer -- Proposed 3D desktop environment

#16 2004-10-02 17:14:04

Re: Ensmer -- Proposed 3D desktop environment

#17 2004-10-02 19:18:57

Re: Ensmer -- Proposed 3D desktop environment

#18 2004-10-02 19:47:44

Re: Ensmer -- Proposed 3D desktop environment

#19 2004-10-02 21:05:50

Re: Ensmer -- Proposed 3D desktop environment

#20 2004-10-02 23:05:23

Re: Ensmer -- Proposed 3D desktop environment

#21 2004-10-03 05:11:45

Re: Ensmer -- Proposed 3D desktop environment

#22 2004-10-04 20:22:55

Re: Ensmer -- Proposed 3D desktop environment

#23 2004-10-04 23:32:34

Re: Ensmer -- Proposed 3D desktop environment

#24 2004-10-05 00:49:56

Re: Ensmer -- Proposed 3D desktop environment

#25 2004-10-05 03:32:42

Re: Ensmer -- Proposed 3D desktop environment

Board footer