ralph@mit-atrp.UUCP (Amiga-Man) (07/18/87)
So, suddenly it came to me late one night: "How to pass file names(via icons) into iconifiable, or even non-iconifiable programs, instead of using "text" based file requestors." The big challenge is how to do this in a completely compatible way, without requiring changes in DOS or the workbench. Here's the gig. Each program which is written having two pieces of executable: (1) The actual code for the entire function. Call it "X-prog". (2) An argument service routine (which is very small). Call it "X" Now, a user starts up program (like an editor), and decides they need the editor to open another buffer with some other file. Simple: (1) Iconify or push the edit window to the back. (2) Find the icon for the file of interest on the workbench screen. (3) Double click it or Shift-click it and the icon for "X". Now, the icons for the files can have a default tool of "X". This program grabs the filename and passes it to "X-prog", who knows how to listen to "X". At this point, "X-prog" can automatically pop to the front and activate (after having opened the file), or we can leave that to the user. Also, we have a little icon for "X" itself, so that any icon (even one with the wrong default tool) can be passed in via "Shift-selecting" it. This way we can also pass multiple files in as well (Gosh, an icon driven C compiler !). The important reason for seperating the talking function from the real program is to allow the user to start "X-prog" during boot up, and have it running all the time. This makes it "resident" in the old CLI-resident style. I don't mind keeping "X" around on RAM disk for repeated individual invokations, but it has to be small. I don't want to be forced to keep a copy of "X-prog" in RAM for call each time. I just want to call it once and keep it running. That way it only uses one copy of itself, not two (the one on RAM disk and the one I'm running). Also, this idea even has advantages for CLI type folks. Now you also pop the window to the back, and using *your* favorite command line interface go find the file, then pass it in by calling "X" from your command interface. Oh, one additional constraint. If "X" is called but "X-prog" is not running, then "X" should start it up, and then pass the filenames in. This makes things automatic. ----------- Justification: This kind of consistant user interface is vital. Take a new user, we teach them how to open disk icons, open drawers, start programs, etc. Now, said user is in an editor, and needs another file read in. A file requestor pops up. "Huh?" exclaims the user, who had already set up all the important data files as icons in a workbench drawer which is open just behind the editor screen. This user should be able to just point to the file they want, *NOT* have to *TYPE* it's name in to some arbitrary file requestor. Heck, some programs have good file requestors, some don't, but with the icons, everybody knows the game ! Get the picture ? I'm pretty proud of this idea, and I'll be writing all my programs this way. Maybe someone else had this idea already ? Anyway, if not feel free to use it. I just wish we'd all use it so the programs we all run will be easier to use. It was inspired by the evolving interface to FACC (thanks, ASDG !) that I've heard about. Now that I think about it, it's also alot like the concept of having libraries on the disk which load as needed. Hmm. An editor as a library. It's getting to be a pretty air-tight idea. Comments ? Now, if we could just fix the slow drawer openings, we'd be crankin ! C'mon 1.3, combine those icons into a single file on a drawer-by-drawer basis ! PLEASE ?