mjp@spice.cs.cmu.edu (Michael Portuesi) (12/15/86)
Keywords: Regarding my previous article, I just thought of another method to implement an argument-passing mechanism for Workbench. Change the icon definition so that the icon contains a template of the allowable syntax for the command. If the command has entirely optional parameters, the command just executes if clicked on with the "Open" option or if double-clicked. If the command has required parameters, the Workbench throws up a requestor box and waits for the user to enter the necessary info. A side effect of this is that the requestor automatically gives the user the syntax of the command. If the user wants to pass arguments to a command that has purely optional arguments, he can select "Open with Args" from the "Workbench" menu or else he can set Preferences to always open a requestor box for commands by default. An icon definition can also state the a command does not accept any parameters at all. In this case, the command is simply executed no matter what method the user takes...double-clicking, "Open" or "Open with Args". Matt, what do you think? -- +----------------------------------------------------------------------------+ | Mike Portuesi | | Carnegie-Mellon University Computer Science Department | | | | ARPA: mjp@spice.cs.cmu.edu | | UUCP: {harvard | seismo | ucbvax | decwrl}!spice.cs.cmu.edu!mjp | | | | "Talking about music is like dancing about architecture" | | --Laurie Anderson, "Home of the Brave" | +----------------------------------------------------------------------------+
cmcmanis@sun.uucp (Chuck McManis) (12/16/86)
Mike Portuesi writes :
.>Change the icon definition so that the icon contains a template of the
.>allowable syntax for the command. If the command has entirely
.>optional parameters, the command just executes if clicked on with the
.>"Open" option or if double-clicked. If the command has required
.>parameters, the Workbench throws up a requestor box and waits for the
.>user to enter the necessary info. A side effect of this is that the
.>requestor automatically gives the user the syntax of the command.
I would suggest that all of you Amiga developers take a look at the
above suggestion and consider it as an enhancement suggestion to
your applications. I know lattice makes it easy to check to see if
you have started from the workbench (argc == 0) it would then be
a simple matter of having your option parsing code throw up a requester
to get any options it needs. Additionally, if the options are
optional (hmmm, you know what I mean) you could check the Tooltypes
for a flag GETOPT that would indicate to your task that you should
always get options from the user.
--
--Chuck McManis
uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com
These opinions are my own and no one elses, but you knew that didn't you.cjp@vax135.UUCP (Charles Poirier) (12/16/86)
I agree about Workbench being too slow and I like your (and Matt's) ideas for improving icon behavior. Let me suggest a tweak for Worchbench arguments: use Left-amiga-click as Open-with-arguments. This can be an alternative to having to go to the Workbench menu, i.e. support both methods. The "big file of icons" seems like a big win to me if one assumes that it is cached. Then closing and opening drawers that have once been opened becomes instantaneous. (Or nearly; you may have to check time of last dir modification.) Amiga needs to support more caching-type ideas. Memory is cheap and getting cheaper. I've seen Workbench windows where the whole drawer was in ram:, and those things are FAST (if you can afford that much ram). But if it's just the icons in ram, you don't use much memory and still get great response on opening the drawers. In fact, how's this tweak: to save on memory used for the icon cache, you can have a workbench menu command where you click on one of the disk icons to delete it, AND its icon map. Otherwise, all disks you've used remain onscreen and their icons remain in-core. Let's not forget, too, that if ALL files are represented in the icons file, then one could use the icons file as a complete directory listing. No more need for all this grinding just to put up a file requester! Use the current directory scheme only for what it is optimized for: single file access by (unglobbed) filename. ARE YOU LISTENING, COMMODORE-AMIGA ?????!!!!! If so, do you like it? While I'm at it, let me add my vote in favor of uniform filename expansion at the CLI level. The comments on other kinds of expansion are well taken, but I say that filenames are far and away the most common form of globbing. Let other realms of expansion use escapes or quotes. That amount of "inconsistency" is compensated by the security of knowing that filename expansion WILL be done. By the way, this should be tweaked in a way that UNIX screws up: for output-redirection, i.e. cmd >foo#?. ALLOW globbing IF the expansion results in ONE file name (error otherwise). And does anyone besides me miss APPEND redirection (UNIX >>)? I thought so. I'm not saying "recreate UNIX", just "fix up AmigaDOS". And then get the AmigaDOS commands to expect multiple args. Heaven forbid you should ever have a whole bunch of files in the wrong dir. Ever try "rename files#? dir" like one can do on UNIX with mv? It's not bloody supported, nor is a loop such as "for i in files#? rename $i dir". You have to type out every one. Unfriendly to the max! Actually, a real "mv" command should support taking a batch of files *off* one disk and moving them to another (deleting them from the first disk). Charles Poirier (USENET)!vax135!cjp
hutch@sdcsvax.UCSD.EDU (Jim Hutchison) (12/17/86)
In article <1696@vax135.UUCP> cjp@vax135.UUCP (Charles Poirier) writes: >... >While I'm at it, let me add my vote in favor of uniform filename >expansion at the CLI level. The comments on other kinds of expansion >are well taken, but I say that filenames are far and away the most >common form of globbing. Let other realms of expansion use escapes or >quotes. That amount of "inconsistency" is compensated by the security >of knowing that filename expansion WILL be done. Yeh, I couldn't agree more. > >By the way, this should be tweaked in a way that UNIX screws up: for >output-redirection, i.e. cmd >foo#?. ALLOW globbing IF the expansion >results in ONE file name (error otherwise). > It's that evil shell you have been using. Unix allows you to replace it, I suggest that you might want to... (here is Berkerley csh) Script started on Tue Dec 16 23:03:02 1986 csvax {1} touch aa ab ac csvax {2} echo hi > a? a?: Ambiguous. csvax {3} echo a? aa ab ac csvax {4} rm ab ac csvax {5} !2 echo hi > a? csvax {6} cat a? hi csvax {7} exit csvax {8} script done on Tue Dec 16 23:03:55 1986 -- Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch ARPA: Hutch@sdcsvax.ucsd.edu Fig is a 5 stage concept.