I've been looking into display postcript (DPS, DGS)a bit. It looks like it could be the free software equivelent of MacOS X's quartz. Although you would need to modify X to get the full effect. It seems you could still implement the X protocol for compatability, but the window system itself would be a superset of X.
If the various desktops could standardize at the level of a postscript based windowing system, that would probably eliminate a lot of redundency in the toolkits. Also it would allow almost unlimited flexability in implementing different types of user interfaces at a more comfortable level than X.
This being said, the Computer Science part of me sees that there are many things to be improved. The system model being one of them.
I think it is fair to say that in a new system model we would probably want to raise the level of abstraction a good amount. Objects seem to be an intuitive way to look at the world, and also in practice we have found breaking things into components makes a system easier understand. So it is clear that a modern operating system would probably be both component based and object-oriented (not necessarily in programing sense). Of course this really doesn't tell someone much at all. There are many details, such as what is the level of granularity of objects? Or in other words what is addresable and what is not? Do the objects interact with each other, and how? How can the user control the interaction between objects? These things are key to a system design of this type. In Unix we can pipeline commands and redirect the input and output from and to files. This has proved very effective for text processing, similar ideas are needed for the graphical environment to maximize ones productivity.
As far as the kernel is concerned, it seems the Hurd kernel would make a good basis for such a system.
Also I'm not in total agreement with your ideas. Networking is obviously paramount to any modern operating system. However, I don't know the degree at which networking should be transparent, it should certainly be as easy as possible, but a user should know clearly the difference at all times between what is local and what is remote. Also I don't like the compositional interfaces, this might just be a personal thing, but they seem rather sloppy, and I'm not sure it really helps the user.
Of course when it comes to the high level aspects of the system, the things the user comes in direct contact with, getting these things right is an art rather than a science, you just have to create something let people try it and improve based on their feedback.
Any way, these are very abstract ideas (and maybe vauge too!) of a new system model. Eventually, these ideas will need to be made concrete, and practical.
This is in response to the couple of articles on GUIs, I'd like to participate directly but Advogato doesn't permit this.
I think the first article which examines the seperation between the CLI and GUI I think is on to some thing. While the other article if followed would seem to dig a deeper hole for ourselfs.
Although language is limited in describing the world and the universe, it is the most powerfull descriptive tool we have. The computer in contrast has 3D visualization, 2D imaging, audio, and language in a limited form, as it's form of communication.
Ideally, if we want to improve communication between us and the computer we should maximize the use of what we are best at respectively. This to me suggests an advanced CLI as our main line of communication with the computer. The computer would still have it's advanced visualization capabilities and would maximize their use in respones to user commands and querys.
I think this direction could be pursued easily within our current framework of software. We would need a keyboard driven window manager, possibly similar to ion, which can be made in X. Also a more expresive shell will ultimately be needed. The big question is how would software for such a system be developed. Integration with the shell is going to be a given, but how could be very interesting.
New HTML Parser: The long-awaited libxml2 based HTML parser code is live. It needs further work but already handles most markup better than the original parser.
Keep up with the latest Advogato features by reading the Advogato status blog.
If you're a C programmer with some spare time, take a look at the mod_virgule project page and help us with one of the tasks on the ToDo list!