Currently, I am visualizing what TUNES could become, as a collection of
objects. I know, after reading that, you'll all dumbfoundedly gazing at the
CRT in disbelief, but stick with me; there's more. I see these objects as
communicating. The communication that takes place conforms to certian
standards. These, for some OS functions, would be quite well defined in the
TUNES OS documentation. The protocol information for other objects should be
accessible, simple by asking them. I see an OS, where applications can be built
from applications; where I can write an interface that combines a text-editor
a VR program, and a mathematics program (such as MathCAD (tm)), in order to
create a real-time, interactive, mathematics visualization program. It is my
belief that all commands accessible to a user, in a given application, ought to
be accessible to other programs! This is not totally unlike a combination of
command-line switches and usage of pipes, in DOS and UNIX. It it this
functionality that I sorely miss in MS-Windows (when I use it!), and so many
other OSes. This would allow the automation of ALL KINDS of tasks, and (what
seems to me to be) an unparalleled level of extensibility!!!
example: If I like what a certian program can DO, bu I don't like the
interface, I should be able to re-write the interface (and possible write
some other functions)! I should be able to setup pipes for data-streams, like
utilizing the spell-checker (which should be its own, complete object, anyway)
in a word-processing program to spell check the out-put from a voice-recognition
program, and then send the text to a file.
Also, it seems to me, that I should be able to re-route information exchanged
between objects. A good example of this would be a simple keyboard translation
object or a keyboard macro object, either of which I would like to insert in
the chain between the low-level kb ISR, and the program-kb interface.
It must be kept in mind, though, that there exists an important difference
between doing this locally (for one application) and globaly (for all objects).
Another good example of this might be a text-to-speech converter. It should
be allowed to be inserted between an application and the graphics output object.
If the output (of a certian kind) from a given object can be re-routed, then
this should allow for much freedom in the department of the user-interface. I
think the UI should _not_ be tied to closely to the OS. There might be a
Windowing UI object, that would be required by some programs (especially in the
beginning), but object output to this should be re-routable to other, possibly
more advanced, UI objects that arise later (an would, of course, be compatible
with all of the data-input streams of the previous windowing UI object.)
This level of freedom wouldn't initially tie TUNES to any given position on
things like games. (i.e. this position wouldn't initially make doom-like games
impossible, in the future.)
Am I totally off-base with these ideas? How do these things correlate with
the existing TUNES philosophy?
:Matthew Gruenke