Brendan wrote:
Hi,
Some minor notes...
When a power user doesn't know what they're doing, they're learning.
The same GUI should be usable by power-users who know what they're doing, power-users who are learning and non-power users.
Non-power users and power users who are learning need documentation about how to use the software directly (which widget does what). Power users who know what they're doing need documentation for the scripting interface. IMHO this is 2 completely different sets of documentation. Both types of documentation should be presented in an interactive way (i.e. the "What is this?" help from Windows) and in a way that can be printed on paper (i.e. like "man" in *nix).
Agreed. A good GUI for anyone needs discoverability.
Quote:
There should be a "record" button, so a user can use software directly (clicking buttons, selecting things from menus, pressing keyboard shortcuts, etc) and record those actions as an auto-generated script, where running that script repeats the actions they did manually. This is good for quickly creating simple scripts and for learning the scripting language.
In practice this means that a recorder program (perhaps in the window manager?) must lock input focus, log all inputs, and forward them to whichever program should actually receive them. Programs could also emit some kind of script forms to a special "standard scripting" output, which a recorder could read.
I personally like the second approach better, as it doesn't make keyloggers hyper-convenient.
Quote:
All applications should accept the "--hidden" command line argument that starts the application in a special mode where no window is created. This means if you run a script that uses several different applications you don't end up with the screen going insane as applications are started and stopped (but you could omit this argument, so that you can write a script that launches an application and does some stuff in advance before the user takes over).
Got any way to make all applications conform to your standard? It's a good idea, but I don't see how the system can enforce it.
Quote:
There should be a compiler for the scripting language, and people should be able to write normal applications and games using the scripting language (and sell the resulting binaries like any other commercial software if they wish).
Eventually, the OS itself should be ported to this scripting language, and then the scripting language should be ported to other architectures.
Your idea runs into some implementation trouble here. The main point of a shell or scripting language is to treat full-fledged programs (in binary or in another interpreted language) as simple subroutines of the script.
However, an operating system also has the imperative to protect programs from one another. So you can't have a scripting language capable of declaring a pointer to a program's internal memory, because the operating system runs the script interpreter (or compiled script) in a separate protection domain (usually a separate address space) from the invoked program. And that requirement would cripple the language for writing the operating system itself.
Scripting languages also usually need access to named persistent storage as part of their runtime (for fetching those subroutine programs), and you can't write a kernel that requires file-system access.
Finally, how would such a scripting language approach concurrency?
However, this could all work if you came up with a method of protection that allows scripts to access internal program memory in a protected fashion. Performing the protection checks to determine if one routine had the requisite privileges to use arbitrary pointers might add a bit of overhead at run-time, but you could do it.
Once you added inline assembler and the ability to link to assembler routines (for interrupt stubs) to such a language and figured out how to make it allow concurrent subroutine continuations, you could write an operating system in your ideal scripting language. Everything would eventually get compiled down to the scripting language, which you would proceed to compile to binary or byte-code if you so desired.
EDIT: You would also have to add a mechanism to your operating system for linking new top-level functions (programs) into the global function name-space at runtime. This would mimic the way in which adding a program to /usr/bin/ makes it show up in bash's program name-space.
Quote:
I set up a network share and just started dragging stuff across, including installed applications and preference files.
I'd like to pick up on this and say something: not only should GUIs have simple primitive functions, but good GUI scripting languages (as Brendan and I have talked about) should include support for interpreting input from any device. If a system doesn't come with select-drag-and-drop support, the user should be able to add it.