Twisted wrote: > On Jun 23, 10:36 am, Martin Gregorie <[EMAIL PROTECTED]> > wrote: > > Actually, what I prefer in (2D and 3D) visual design apps is the > ability to snap to some kind of grid/existing vertices, and to zoom in > close. Then small imprecisions in mouse movement can be rendered > unimportant. > That might work for visual design apps, but it doesn't for CAD, where you may want to point to an arbitrary position with a (scaled) accuracy of microns.
The fact remains that mechanical mice do jump when you click them, though optical mice are better in this respect. > The problem of course being the complete exclusion of type 1 users. > Totally untrue. They are the people that all the standard GUIs are designed for and some (e.g Mackintosh) are very fast to learn. The exclusion is down to the way that the purveyors of GUIs keep spreading bullshit about how any untrained person can use a computer and never mess it up or loose data. Thats not true and never can be: a computer is the most complex device the average person will own or use and is likely to retain that title for the foreseeable future. I grant you that type 2 users are rare, but I think flight simulators may fit this case when used for training. > One with a bog-standard UI but also a "console" or command prompt, > scripting language, and customizable bindings? > Not really. What's needed is a single interface that can be used by anybody from beginner to expert and that, in the case of an error, shows precisely where it got, what caused the action to fail to complete and that allows the user to continue from that point without having to undo/redo the bits that were successful. Its not easy, but it can be done. > ROM BASICs and QBasic (on any really ancient microcomputer, and old > pre-Windows PCs, respectively; the former came with printed manuals > and you could just run prepackaged software from disks very easily; > Hang on: you don't read manuals. You object to using tutorials and to buying books, so its a bit precious to claim this example. > * The word processor with the usual interface where I can define > logical styles, then change them in only one place and affect every > pre-existing occurrence retroactively. > Thats been in Word since DOS days and is part of OpenOffice. Its called a "style sheet". The only WPs I've used that didn't use them were Wordperfect, WordStar, DEC WPS+ and the Wang dedicated WP systems. All were horrid to varying degrees, with Wordperfect and Wordstar tying for worst. > * The word processor with the usual interface where I can also view an > underlying markup representation and hand-hack that, > You're thinking of Wordperfect and its 'Reveal Codes' function. That was the worst idea I've ever seen in a WP, matched only by the illogically arranged set of 12 function keys, each with 4 shifts. > and which likely has the capabilities of the first two as a direct > consequence of the implied architecture. > It didn't. 'Reveal codes' could only let you inspect the current document. Unfortunately it was essential to use it because some input sequences could completely mess up the formatting and the only way to recover was via 'Reveal codes'. The effect was similar to making a data entry clerk use a hex editor on a database to fix keyboarding errors. NOTE: I'm not talking about secretaries using WordPerfect. Those that used it hated it. I'm talking about the experience of IT professionals writing structured text, e.g. system specifications. > * The operating system where you can do powerful stuff with a command > line and a script or two, but can also get by without either. (Windows > fails the former. Linux fails the latter.) > Here you're talking about two different interfaces again. The nearest I've seen to good solutions at OS level were the CL interface provided by ICL's VME mainframes and IBM's AS/400 systems. The latter was particularly good, with a single unified text screen interface which provided help screens, menus and a command line. You could search for and find commands via a menu structure, and then use form filling to provide the arguments, with help available at any stage. If you were writing a script the entire menu and form filling system was available from within the text editor - but when you hit ENTER the completed command was written into your script instead of being executed. Both OS/400 and VME were very consistent in the way they assigned command names and argument keywords. In both OSen it was possible to think "if there's a command to do this it will be called BLAHBLAH", type the name, hit the command completion key and have the argument entry screen pop up ready to be filled in. BTW, in both OSen this capability applied to user-written scripts and programs as well as to the standard command set. Both could claim to be object oriented: the VME command language was derived from Algol-68, arguably the granddaddy of all OO programming languages. > * For that matter, the operating system whose GUI takes the concept > behind OLE to its logical conclusion, and lets the user separately > choose and configure their text editing, this-editing, that-editing, > whosit-viewing, > The AS/400 editor did exactly that. There was only one, but it swapped personality to match the task and was language-aware as well as application aware. It produced form-filling interfaces to help you write command scripts. If you were writing a program it gave language-specific prompts and could run syntax checks on each statement as it was entered. If you didn't want any of that, it would just quietly accept input like any other text editor. > The bog-standard alt, this, that sequences on Windows "come close"; > they do make the menus display, but otherwise they do exactly what you > want, and you can ignore the menus blinking around in your peripheral > vision. > No they don't: you can't easily string them together to act as a single command and the error diagnosis and reporting is remarkably poor. Same goes for Gnome, so I'm not particularly bashing Windows here. -- martin@ | Martin Gregorie gregorie. | Essex, UK org | -- http://mail.python.org/mailman/listinfo/python-list
