Of course, configuration and property windows don't need the entire screen. Therefore, they can appear in smaller, document-modal (see below) windows. If you open one, the full-screen view behind it should be grayed out, so that the window containing the things you can do appears lightened up, so that it really gets your attention.
The appearance of MacOS 8/9 also has this effect, but it is lots more confusing because it makes no difference between windows that can't be activated because of a dialog (as in my proposal) and windows that are plain inactive and can be switched to with a single mouseclick.
2.3 The widgets an sich
Nowadays everybody points out that Gnome should be used instead of KDE because it looks more polished, that you should use MacOS X because Aqua looks so cool and that Longhorn is even better because it provides hardware accelerated control drawing. Sounds great? It actually isn't. Those fancy user interfaces waste precious CPU and GPU cycles, making your computer slower than it needs to be, thus making you work slower. In return, you are distracted from your work so that your productivity is even lower.
Looking at future developments, however, it seems to be rather practical to have a resolution indepent GUI. In that way, applications have no problems running on low-res devices such as a palmtop or a TV, while still being able to take advantage of high-res computer screens. To have something to brag about, the VM graphics system should offer nested canvases remembering their content, so that one could say that " the new OS has a GUI in which each control is drawn with hardware acceleration".
3 The document model
After having done away the windows, we should also get rid of applications, because they are also confusing. On Windows, you can open documents in two ways: from an empty application window and from the Explorer. The same applies to creating new documents, but strangely enough not to saving them. On the MacOS, that is also the case and it is even more confusing: an application can be active and running without displaying any windows. That means you see the desktop and the finder, but that the menu bar is different because you are effectively running another application. Those are enough reasons to leave the application model.
Instead, the only thing the user should see are documents. Nothing more and nothing less. When the user clicks a document, it is opened, and when he closes it, the document is closed. What software is used to accomplish this should not be visible in any way. The way this can be implemented is by making applications effectively applets (like KParts or OLE objects). When a document is opened, a new full-screen view is created and the document is embedded into it, along with the application.
3.1 OLE!
The advantage of the applet model above applications is that no seperate logic is needed to provide embedding documents - the parent document's applet just needs to embed another applet into it, and for that applet it is not visible whether it runs full-screen or embedded.
For normal documents, data will come from a file, either on disk or embedded in another document. That's the way it also works on Windows, MacOS and KDE. However, sometimes that is not practical. Imagine that you want to make a chart application. You will probably want to link the data to the spreadsheet it is embedded in. It should be obvious that would not work. Therefore, we need to create the GUI equivalent of pipes, so that you can use (a selection of) your spreadsheet data as the input of the chart applet. That can create powerful systems: functions like bibliographies and tables of contents can be placed in separate applets that can be embedded in the document they are used in.
3.2 DDF
The documents can be stored in any format - the applet can determine it. To make embedding more flexible, a standard output format should be made, however. For this new OS, it should be designed from the ground up - this to support a few important things for the embedding to work properly. The reason for this is that besides the well-known object embedding, it should also provide text embedding, to make things like Table of Contents-applets possible.
Embedding objects is easy. The host applet defines, within the DDF, a region containing a sub-ddf and pastes the output of the embedded applet within it.
Embedding text is more difficult, and that has a reason. With embedded objects, the host decides how large the frame is in which the object is embedded. With embedded text however, the applet needs to decide the size as you can't just rescale a text. Additionally, it would not look nice if embedded texts would not have advanced features like, say, automatic hyphenation. A solution would be to let the host application decode the DDF the embedded object outputs. That is not a clean solution, however, as the host applet needs to sport a complete DDF interpreter.
I believe the solution can come from breaking a monolithic program into several applets. The usual word processor can be split up into two pieces. The first one will be for composing formatted text. Let it support feautures like word wrap and embedding of other texts. The other applet will do the layout: it will put the text (and images) into frames, possibly on multiple pages, supporting text flow, page numbers and so on. In that way, you can still edit complex documents, but you have more flexibility, and can use the same advanced text formatting in both the word processor and the spreadsheet program.
- "Future OS, Page 1/3"
- "Future OS, Page 2/3"
- "Future OS, Page 3/3"
