I haven't worked very much on the details for the GUI. I would certainly like to go beyond the 2D interface. Sun's Looking Glass project looks kind of fun. It will be interesting to see what happens there.
I had envisioned something beyond that, where you didn't really have windows but more like different rooms, like a music room, a library, a tv room, etc. But as I said I haven't put as much effort into this as the underlying pieces.
One thing I would like to come out of having software built out of separate modules that could be connected is that an app could have different interfaces without having to change the app.
For example, an application would have a control connection to it. It would not have the interface coded into the app itself. Then you could connect an interface, either GUI or command line, to it. Depending upon your preference.
Where to Start?
This is the big question. Should I take the top down approach or a bottom up approach? I read once that "Real programmers do it middle out!". Or perhaps start at both ends and see if I can meet up in the middle somewhere.
Actually my current plan is to build the Object store on top of an existing OS. Find out if it is going to work at all and how well it works. In fact I don't see any reason that one couldn't build practically the whole OS on top of another OS, similar to User Mode Linux.
One other thing I plan to investigate is how well the object paradigm works at lowest levels of the operating system. It seems like a natural fit, but I could be wrong. One of the things in Linux that seems kind of strange to me, although it seems to work pretty well, is the simulating of a SCSI device for IDE and SATA drives. It does seem like it's extra work.
It appears to me that came from a program such as 'cdrecord' that wanted to talk to a SCSI device. Although I'm sure there are other good reasons. But in Object Oriented land it would seem like the application (cdrecord) could be written to talk to a generic object (CD-Drive), which could be instantiated as either a SCSI or IDE object. So I want to investigate this further to see if that would be possible or if I'm up in the night.
I also plan to use as much of existing Open Source as possible. It makes no sense to have to write all device drivers from scratch (and it would take years). So I want to see what drivers can be used from Linux or any of the *BSD's and perhaps wrap them with an object interface. This seems like the beauty of Open Source, that you don't have to start completely from scratch. At a minimum you can at least look at how someone else has done something and try to improve upon it. Standing on the shoulders of giants if you will.
Well, this is already longer than I had intended it to be. And there are more details that I would really like to include. I have started a project at SourceForge for further details. It will be at http://nwos.sourceforge.net/ when I get it set up. I intend to put up copies of my hand scribbled notes, some drawings and some more details in the next few days.
As I stated in the introduction, none of this may actually work. Or it may be so excruciatingly slow that it's unusable. On the other hand with processors now running over 3 GHz, I cannot imagine that would be the case. Seriously, when I'm balancing my checkbook the CPU is probably not too burdened. I know sometimes (like rotating photographs) that you need all the speed you can get. But in the general case I would gladly trade some horsepower for some ease of use and reliability.
In the end this is really all about the famous "Itch I have to Scratch". Since I deal with computers all day, almost everyday, I constantly wonder "does this have to be this complicated?" and "is there a better way?". Perhaps there isn't, perhaps computers, difficulty, and complexity all go hand in hand. But I just have to see for myself. I really cannot give up the idea that there must be a simpler way. It keeps haunting me. Therefore, I have to prove to myself that it either can or can't be done.