dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/02/86)
IF Workbench ICONS were stored in a single file per directory rather than in a lot of little files, I would use it (the workbench). With all due respect, if you don't change it soon, I will huck your Workbench and write my own. -Matt
dave@gitpyr.gatech.EDU (David Corbin) (12/04/86)
In article <8612021654.AA00831@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > IF Workbench ICONS were stored in a single file per directory rather >than in a lot of little files, I would use it (the workbench). > With all due respect, if you don't change it soon, I will huck your >Workbench and write my own. > > -Matt and I, along with 'millions' of others, will be waiting for it.... -- David Corbin Atlanta, GA ...!{akgua,allegra,amd,hplabs,ihnp4,masscomp,ut-ngp}!gatech!gitpyr!dave
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner) (12/10/86)
In article <2762@gitpyr.gatech.EDU> dave@gitpyr.UUCP (David Corbin) writes: >In article <8612021654.AA00831@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >> IF Workbench ICONS were stored in a single file per directory rather >>than in a lot of little files, I would use it (the workbench). >> With all due respect, if you don't change it soon, I will huck your >>Workbench and write my own. >> -Matt > >and I, along with 'millions' of others, will be waiting for it.... > >David Corbin Personally, I like to be able to manipulate individual .info files and program/program.info pairs from CLI. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
keithd@cadovax.UUCP (Keith Doyle) (12/13/86)
In article <1087@cbmvax.cbmvax.cbm.UUCP> carolyn@cbmvax.UUCP (Carolyn Scheppner) writes: >>> IF Workbench ICONS were stored in a single file per directory rather >>>than in a lot of little files, I would use it (the workbench). >>> With all due respect, if you don't change it soon, I will huck your >>>Workbench and write my own. >>> -Matt > Personally, I like to be able to manipulate individual .info files >and program/program.info pairs from CLI. > >Carolyn Scheppner -- CBM >>Amiga Technical Support<< Yes, but look at what you just said. It's convenient from the CLI point of view, but not the WORKBENCH point of view (too slow). And why are the .info files there? Not for the CLI but for the Workbench. I like being able to manipulate the files seperately too, (the Apple resource/data fork mess is a pain in the ***), BUT one of the main reasons I don't use the Workbench, is it's poor performance. When I'm looking over the shoulders of a freind on a MAC, the icon interface is snappy enough to be useful. I believe the performance of an icon based interface to be in direct correlation to it's usefulness. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/13/86)
>Keith Doyle: >Yes, but look at what you just said. It's convenient from the CLI point of >view, but not the WORKBENCH point of view (too slow). And why are the >..info files there? Not for the CLI but for the Workbench. > >I like being able to manipulate the files seperately too, (the Apple >resource/data fork mess is a pain in the ***), BUT one of the main reasons >I don't use the Workbench, is it's poor performance. When I'm looking >over the shoulders of a freind on a MAC, the icon interface is snappy >enough to be useful. I believe the performance of an icon based interface >to be in direct correlation to it's usefulness. Look at what you just said .. "BUT one of the main reasons I don't use the Workbench, is it's poor performance". EXACTLY MY POINT. Tell me something... how can people (scope: anybody who uses the workbench) work with an interface that takes 15 seconds to open a window? The functionality that is supposedly lost by going to a single .info file per folder can be regained with utilities. However, the functionality that I consider lost in the current system (slow icon display on open) can only be regained when: (A) C-A writes a more intelligent disk cache (B) C-A changes the interface to use a single file. The added "neatness" is simply a nice aftereffect. Now which method would you use? (B) certainly is easier, and also has side benefits (one example iterated above) that would make many CLI users turn back to the workbench. -Matt
mjp@spice.cs.cmu.edu (Michael Portuesi) (12/15/86)
Keywords: I agree with Matt's sentiments. The performance of the workbench is simply too slow for it to be considered a viable user interface. I personally dislike listening to my drive grind and the 2-second delay between each individual appearance of an icon in a window. I hate being bothered with a bunch of .info files lying around in my directory cluttering up the listing of the important stuff there. I especially don't like the fact that the Workbench totally ignores files without .info files -- making it look to the workbench user that a disk or directory could be totally empty when in fact it is loaded with files. In short, I think the Workbench is ill-designed at best. The Macintosh Finder provides its services in a consistent, quick manner. I'm not saying that the best design is an emulation of Apple's. What I am saying is that the following issues need to be addressed: 1) The performance of the Workbench needs to be accelerated tremendously. I haven't seen 1.2 in action yet, but under 1.1 I don't understand how the novice could tolerate its slowness, let alone the experienced user (read: hacker). 2) The Workbench needs to be more consistent. There should be an icon for every file in the system when the user opens a window. Everything that the CLI can see the Workbench should also be able to see. 3) There should be some sort of mechanism to allow the Workbench to pass CLI-type arguments to its programs. True, the novice user does not need this and should probably be shielded from it, but hackers like me would take the Workbench seriously if this feature existed. How to implement these features/improvements? The icons could be speeded up by putting them all in one file in each directory...or in a great big file in the root directory. Then you could write utilities to install, copy and delete icons. A file that didn't explicitly have an icon definition in the "icon file" would be given a default "vanilla" icon, sort of what the Mac does for files it has no specific definitions for. The argument-passing mechanism could be implemented as a string gadget that appears only when the icon is opened when the new option "Open with Args" is selected instead of "Open" from the "Workbench" menu. Additionally, Preferences could set a default parameter that would pop up the arugment string gadget by default when an icon is double-clicked. When the capability to run CLI programs is added to Workbench, Workbench users will be able to access the full power of the machine in a friendly manner. They won't have to mess around with atrocities like the Workbench DiskCopy which copies a disk in 8 swaps (even when you have an external drive! -- it assumes you use drive 0 only) when the CLI version does it in 3. Default icons for "tools" and "projects" will immediately reduce the number of icons kept around, as every file will no longer require its own individual icon description to be recognized by Workbench. If a custom definition does not exist, the default is used -- and the system only reads ONE file to determine this information for EVERY program in the directory! The image of the default icons could be changed with IconEd or Preferences (the same way Preferences now allows you to change the mouse pointer). As it is, the current Workbench has enough holes in it that I would label it as unsuitable for the novice user. -- +----------------------------------------------------------------------------+ | 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/15/86)
These are some comments on Mike's problems with the workbench, yes we would all like to see it go really fast but no, it doesn't do that yet. In article <1107@spice.cs.cmu.edu>, mjp@spice.cs.cmu.edu (Michael Portuesi) writes: > 1) The performance of the Workbench needs to be accelerated > tremendously. I haven't seen 1.2 in action yet, but under > 1.1 I don't understand how the novice could tolerate its > slowness, let alone the experienced user (read: hacker). This is one of the better features of 1.2, the workbench opening of directories is much improved. (down to one second rather than two) > 2) The Workbench needs to be more consistent. There should be > an icon for every file in the system when the user opens a > window. Everything that the CLI can see the Workbench > should also be able to see. And while in theory this is a good thing, there are a lot of files I would just as soon *not* have the workbench clutter up my screen with. All of the devices come to mind, as do all of the CLI specific commands. There are quite a few files that are of *no* use to the workbench user and he/she would probably resent having to wait for their icons to appear. > 3) There should be some sort of mechanism to allow the > Workbench to pass CLI-type arguments to its programs. > True, the novice user does not need this and should > probably be shielded from it, but hackers like me would > take the Workbench seriously if this feature existed. Ever select info after selecting and Icon? You can pass some things in the ToolTypes field, you can also use extended select to pass filenames. The Wbench startup message has all of that stuff in it. > The icons could be speeded up by putting them all in one file in each > directory...or in a great big file in the root directory. Then you > could write utilities to install, copy and delete icons. A file that > didn't explicitly have an icon definition in the "icon file" would be > given a default "vanilla" icon, sort of what the Mac does for files it > has no specific definitions for. Sorry to disappoint you, however, this would only work if it was the *first* file you wrote to the disk and you never changed it. Since AmigaDOS uses a hashing scheme to locate directory entries it has no compunction about putting directory blocks close together. Thus your "one file" may have pieces of itself all over the disk. A somewhat better approach might be to have an "icon pointer" in directory blocks that points to a linked list of icon file headers in that directory. This would at least prevent you from having to scan the entire directory for .icon files. (There are even free longwords in the Directory block and the FileHead block structures, how about it Andy 1.3?) > The argument-passing mechanism could be implemented as a string gadget > that appears only when the icon is opened when the new option "Open > with Args" is selected instead of "Open" from the "Workbench" menu. > Additionally, Preferences could set a default parameter that would > pop up the arugment string gadget by default when an icon is > double-clicked. It would be a start, personally I would prefer a way of double clicking (shift double click?) If POINTREL requesters really do work in 1.2 then maybe a double menu click would be the way to go. > When the capability to run CLI programs is added to Workbench, > Workbench users will be able to access the full power of the machine > in a friendly manner. They won't have to mess around with atrocities > like the Workbench DiskCopy which copies a disk in 8 swaps (even when > you have an external drive! -- it assumes you use drive 0 only) when > the CLI version does it in 3. Huh? With two drives have you tried, put your source disk in DF0: and you destination in DF1:, drag the DF0: icon over the DF1: icon, it asks you to put workbench back in,(swap 1) you do and it throughs up a confirm requester, and asks you to put the source disk back in so you replace the workbench disk in DF0: with your source disk (swap 2) Then the diskcopy routine copys the disk in DF0: to DF1:, voila copied disk and you only swapped twice. > Default icons for "tools" and "projects" will immediately reduce the > number of icons kept around, as every file will no longer require its > own individual icon description to be recognized by Workbench. If a > custom definition does not exist, the default is used -- and the > system only reads ONE file to determine this information for EVERY > program in the directory! The image of the default icons could be > changed with IconEd or Preferences (the same way Preferences now > allows you to change the mouse pointer). But what about the other stuff the .info file contains, like where on the screen the icon appears, the default tool to run when the user double clicks this icon, options to give to the tool, etc. > As it is, the current Workbench has enough holes in it that I would > label it as unsuitable for the novice user. > Mike Portuesi I wouldn't label it unsuitable, it has improved alot in 1.2 and I assume it will do so even more in 1.3. I hacked together an interface for the Lattice 3.1 C compiler that ran under workbench and it seemed to work out fairly well. Now that some of the tools like Egad! are coming together you should probably be on the lookout for better workbench applications. -- --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.
timothyb@crash.UUCP (Timothy Burleson) (12/16/86)
In article <1107@spice.cs.cmu.edu> mjp@spice.cs.cmu.edu (Michael Portuesi) writes: >I agree with Matt's sentiments. The performance of the workbench is >simply too slow for it to be considered a viable user interface. Wait until you see it on a hard drive! Even a Macintosh looks impressive running off a hard drive. Timothy B. Burleson The Alexandrian Library (619)-576-7424 - 24HRS - 300/1200 BPS {akgua,hplabs!hp-sdd,sdcsvax,nosc}!crash!timothyb
eric@topaz.RUTGERS.EDU (Eric Lavitsky) (12/16/86)
Yes, but every system has it's drawbacks. What happens if you accidentally blow away the file that has *all* the icons in it? By by icons! I think a more useful improvement to the Workbench would be the ability to interrupt certain Workbench tasks before they complete, like directories for instance. If what I want is up there, why should I have to wait for everything else. Another feature I've wanted from the beginning is "mouse ahead". Heck, why can't I click close on some sub-directory window while I'm doing a directory of another disk and have that window dissapear when the other directory completes? Why do I have to go back and click the close box again? Please queue up mouse events for the Workbench, or at least make it an option from Prefences (like CLI on)... Eric -- ARPA: LAVITSKY@RUTGERS or LAVITSKY@RED.RUTGERS.EDU UUCP: ...topaz!eric ...hplabs!well!lavitsky ...ulysses!eric
lachac@topaz.RUTGERS.EDU (Gerard Lachac) (12/16/86)
In article <1107@spice.cs.cmu.edu> mjp@spice.cs.cmu.edu (Michael Portuesi) writes: > 2) The Workbench needs to be more consistent. There should be > an icon for every file in the system when the user opens a > window. Everything that the CLI can see the Workbench > should also be able to see. > This is ridiculous!! Even the Mac doesn't give you this.. (ever play with MacTool??) I can just see it now, opening up my c drawer on the workbench and have 30 icons pop up! How useful!!! :-) > >Workbench users will be able to access the full power of the machine >in a friendly manner. They won't have to mess around with atrocities >like the Workbench DiskCopy which copies a disk in 8 swaps (even when >you have an external drive! -- it assumes you use drive 0 only) when >the CLI version does it in 3. Hmmmm... every time I use to use the WB for diskcopy it was the same 3 swaps... except with a cute little window attached! Hey, I'm not saying the workbench is fantastic, but it does have its merits, even though the implimentation is a little slow. Copying .info files is a really easy way to copy icons. And you have to love those front and back gadgets. I hate it when you click on a Mac window by accident and it pops to the front. Annoying.... lachac@topaz.rutgers.edu
dillon@CORY.BERKELEY.EDU (Matt Dillon) (12/16/86)
>> The icons could be speeded up by putting them all in one file in each >> directory...or in a great big file in the root directory. Then you >> could write utilities to install, copy and delete icons. A file that >> didn't explicitly have an icon definition in the "icon file" would be >> given a default "vanilla" icon, sort of what the Mac does for files it >> has no specific definitions for. > >Sorry to disappoint you, however, this would only work if it was the >*first* file you wrote to the disk and you never changed it. Since >AmigaDOS uses a hashing scheme to locate directory entries it has >no compunction about putting directory blocks close together. Thus >your "one file" may have pieces of itself all over the disk. A somewhat >better approach might be to have an "icon pointer" in directory blocks >that points to a linked list of icon file headers in that directory. >This would at least prevent you from having to scan the entire directory >for .icon files. (There are even free longwords in the Directory block >and the FileHead block structures, how about it Andy 1.3?) Sorry to disappoint you, but the one-file scheme would be extremely effective especially when compared to the 'search the entire directory and read all the info files' scheme. For one, both schemes read exactly the same information (thus your argument falls to the four winds). The whole point is to get rid of the idiotic directory searching. and your comment on about the hashing function doesn't apply at all... it doesn't really matter if it's the first file or not, just as long it is a known file. The new scheme would use a known file name and thus a known hash and for all practical purposes a single seek to get to the base block for the entire folder. Compare this to having to open each X.info file in the current scheme... one for each ICON. >> As it is, the current Workbench has enough holes in it that I would >> label it as unsuitable for the novice user. >> Mike Portuesi > >I wouldn't label it unsuitable, it has improved alot in 1.2 and I assume >it will do so even more in 1.3. I hacked together an interface for the >Lattice 3.1 C compiler that ran under workbench and it seemed to work >out fairly well. Now that some of the tools like Egad! are coming together >you should probably be on the lookout for better workbench applications. I would label it completely unsuitable... and for one reason only: It's too slow. You've talked a lot about it being 'better under 1.2'. Well, I've been using 1.2's specific workbench improvments for the past couple of months (it was in beta 4 ,all later betas, and probably some earlier versions as well), and frankly, the speed up is only somewhat noticeble. You don't seem to understand that placing everything in a single file per folder would be at least an order of magnitude faster (read 10x), if not more. -Matt
fnf@mcdsun.UUCP (Fred Fish) (12/17/86)
In article <8612160732.AA06465@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: >You don't seem to understand that placing everything in a single file per >folder would be at least an order of magnitude faster (read 10x), if not >more. I suspect you are probably right. What we need is a demo program that walks directory trees, doing nothing but putting up icons. When it finds a directory not containing a "quickicons" file, it munches all the existing .icon files and builds a new one. Once the users see how fast it really COULD be, the pressure for change will be on... -Fred -- =========================================================================== Fred Fish Motorola Computer Division, 3013 S 52nd St, Tempe, Az 85282 USA {seismo!noao!mcdsun,hplabs!well}!fnf (602) 438-5976 ===========================================================================
andy@cbmvax.cbm.UUCP (Andy Finkel) (12/18/86)
In article <1107@spice.cs.cmu.edu> mjp@spice.cs.cmu.edu (Michael Portuesi) writes: > 1) The performance of the Workbench needs to be accelerated > tremendously. I haven't seen 1.2 in action yet, but under > 1.1 I don't understand how the novice could tolerate its > slowness, let alone the experienced user (read: hacker). Under V1.2 try addbuffers df0: 30 This helps icon display in Workbench a lot. > 2) The Workbench needs to be more consistent. There should be > an icon for every file in the system when the user opens a > window. Everything that the CLI can see the Workbench > should also be able to see. Or they should be available via a Xerox Star style browsing mechanism, agreed. > > 3) There should be some sort of mechanism to allow the > Workbench to pass CLI-type arguments to its programs. Setting the ToolTypes field of an icon is meant to do just that. But you want a quicker way, I guess. >When the capability to run CLI programs is added to Workbench, >Workbench users will be able to access the full power of the machine >in a friendly manner. They won't have to mess around with atrocities >like the Workbench DiskCopy which copies a disk in 8 swaps (even when >you have an external drive! -- it assumes you use drive 0 only) when >the CLI version does it in 3. Actually, the Workbench Diskcopy program uses drive 0 in a 2 drive system only when invoked improperly. The proper way is to move the icon of the disk you want to copy on top of the disk you want to copy to. (This is possible even in a 1 drive system...just open up one of the icons when its in the drive. Workbench will then continue to display that icon even if you remove it from the drive. Used in this manner, your number of swaps will decrease. BTW, under V1.2, the Workbench Diskcopy and the CLI Diskcopy are the same program. >| Mike Portuesi | andy finkel -- andy finkel Commodore/Amiga {ihnp4|seismo|allegra}!cbmvax!andy or pyramid!amiga!andy Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors. "Never make anything simple and efficient when it can be complex and wonderful."
wagner@utcs.UUCP (12/20/86)
Oh, no, not this again... The performance problem with the icon system is in AmigaDOS's lousy support for file systems with small files and for wildcard searches. Kludging the workbench to make up for a (very fixable) performance problem in the underlying file system is a stupid idea. And fixing the AmigaDOS file system performance problems, as Perry pointed out a while ago, would make hard disks much more usable. I know Matt has the other point of view, and, last round, it was sort of left at an impass. Neither of us convinced the other. I would offer the opposite 'statement' to Matt's: Please fix your file system and drivers. Sooner or later, if you don't, I'll write and distribute a public domain one that works better! Michael P.S. Actually, from some dark hints that Perry dropped a while ago, he may do it before I do.
blgardne@esunix.UUCP (Blaine Gardner) (12/20/86)
Ok Andy, it's nice to know that the WB & CLI copy programs are one & the
same under 1.2. But when are you guys going to fix diskcopy so that it
actually VERIFIES the data that it has written?
Yes, it would be nice for the blasted icons to pop up quicker, but that
seem to me to be trivial compared to a disk copier that will gladly let
you copy your data into the black hole of a bad floppy!
PLEASE fix this awful bug!!!
--
=================================================
"The Admiral is well aware of the regulations..."
=================================================
Blaine Gardner @ Evans & Sutherland
{ihnp4, decvax}!decwrl!esunix!blgardne
560 Arapeen Drive Salt Lake City, Utah 84108 (801) 582-5847wagner@utcs.UUCP (12/20/86)
In article <1107@spice.cs.cmu.edu> mjp@spice.cs.cmu.edu (Michael Portuesi) says some very interesting things. For the most part, my comments are interspersed with his. However, I think it's worth separating the arguements involved into performance and function issues. Matt's original comment was on performance (and usability, as a result). Some of Michael's comments extend the discussion (in very useful ways, mind you). > >I agree with Matt's sentiments. The performance of the workbench is >simply too slow for it to be considered a viable user interface. I >personally dislike listening to my drive grind and the 2-second delay >between each individual appearance of an icon in a window. Agreed. With 1.2, 2Meg expansion and addbuffers 50, it's better, but still a pain. >I hate >being bothered with a bunch of .info files lying around in my >directory cluttering up the listing of the important stuff there. Well, realistically, this is a problem for the CLI user of a workbench drawer. Not really fair. >I >especially don't like the fact that the Workbench totally ignores >files without .info files -- making it look to the workbench user that >a disk or directory could be totally empty when in fact it is loaded >with files. Couldn't agree more. Workbench should certainly put up some sort of default icon for files without matching .info files. I do like the ability to hide files from the eyes of the casual user though. Perhaps more universal use of the .noinfo trick that the CLI uses, or a flag in the .info file that says don't display me? >In short, I think the Workbench is ill-designed at best. The >Macintosh Finder provides its services in a consistent, quick manner. >I'm not saying that the best design is an emulation of Apple's. What >I am saying is that the following issues need to be addressed: > > 1) The performance of the Workbench needs to be accelerated > tremendously. I haven't seen 1.2 in action yet, but under > 1.1 I don't understand how the novice could tolerate its > slowness, let alone the experienced user (read: hacker). Agreed. Clearly this is a performance issue, and can be fixed at either the application (workbench) or underlying level. I claim that fixing the underlying level (amigaDOS file system) provides more benefit in other areas too (although being a bigger project, perhaps). > 2) The Workbench needs to be more consistent. There should be > an icon for every file in the system when the user opens a > window. Everything that the CLI can see the Workbench > should also be able to see. Agreed. This is new function, and would have to be put into the workbench. However, I think the need is more general than is being stated here. ".info" files are not just icons. They contain all sorts of information about how the associated file should be treated, including the name of the program that knows how to process it, and any options that should be set for the processing of this file. There should be default .info files for files that don't have their own. There should be both a system default and defaults for the surrounding drawer(s). Resolution should be by the system. That is, as now, a system call should give back the .info for this file, but it should be extended to resolve the information request with reference to system defaults and so on. Imagine a default file that specified that anything in this drawer was a project to be used with the DPAINT tool, and had this associated imagery. In addition, it should be possible to reference other files for large portions of duplicated data (such as the imagery). This would allow .info files to contain a very small amount of data, only that part that was unique for this associated file, and point off to imagery elsewhere. > 3) There should be some sort of mechanism to allow the > Workbench to pass CLI-type arguments to its programs. > True, the novice user does not need this and should > probably be shielded from it, but hackers like me would > take the Workbench seriously if this feature existed. This actually sounds a little awkward to use, but perhaps I just can't see the need well yet. In any case, a flag in the .info file saying that workbench should prompt for a single string argument would be easy and usefull. Such a .info file (only one) in the c: directory would supply this functionality for all CLI commands. Individual .info files associated with individual commands could provide more specific prompting services and tailoring. Notice, incidentally, that in a parallel discussion about CLI/shell and prompting mechanisms, we are coming around to the idea that, with each command executable, there should be an associated file containing the operand requirements, and that the CLI should look at it and interact with the user before the command is loaded and run. It seems that the .info files are ideally suited to just that. Moreover, both the line mode shell and the workbench could read these same descriptions. Workbench could put up a requestor to get the results...the line mode shell(s) could just issue textual prompts. Amazingly, no one has mentioned one of the things that bothers me the most about the current .info scheme. There can only be one .info file per 'real' file. I would like to have two icons that point to the same executable or tool, with perhaps different options set (i.e. they differ only in the parameters stored in the .info file). I don't think this is possible in the current scheme. Anyone know how to do this currently? >How to implement these features/improvements? >[...] >The argument-passing mechanism could be implemented as a string gadget >that appears only when the icon is opened when the new option "Open >with Args" is selected instead of "Open" from the "Workbench" menu. >Additionally, Preferences could set a default parameter that would >pop up the arugment string gadget by default when an icon is >double-clicked. We seem to have similar ideas here, although I expect that the flag should be tied to the file rather than the action of opening. I mean, either the command can be called from workbench or it can't. If it can't, then it always need the other interface. No? >When the capability to run CLI programs is added to Workbench, >Workbench users will be able to access the full power of the machine >in a friendly manner. They won't have to mess around with atrocities >like the Workbench DiskCopy which copies a disk in 8 swaps (even when >you have an external drive! -- it assumes you use drive 0 only) when >the CLI version does it in 3. You've baffled me completely here. Workbench never asks me to swap disks at all. To copy disks, you just drag one disk icon over the other. If you select the icon and then the menu option duplicate, you invoke the one-disk duplicate (and then you swap). If you don't like this 'feature' of workbench, don't use it. Granted, it would be nice if the utility underlying were to make better use of available memory, but that's the utilities fault, and not the fault of the workbench. Perhaps I miss the point? >Default icons for "tools" and "projects" will immediately reduce the >number of icons kept around, as every file will no longer require its >own individual icon description to be recognized by Workbench. If a >custom definition does not exist, the default is used -- and the >system only reads ONE file to determine this information for EVERY >program in the directory! The image of the default icons could be >changed with IconEd or Preferences (the same way Preferences now >allows you to change the mouse pointer). We seem to pretty much agree here. Although I must admit that I don't know how you would have separate default icons for tools and projects, since you can't tell one from the other without the .info file you seem to be wanting to avoid. There is, of course, provision in AmigaDOS for a string associated with every file. It's called the file comment, or some such, and it's poorly supported at best. There are conceptually three sources of associated information for each file. There is the file comment, manipulated with the FILENOTE command. There is the textual part of the .info file, manipulated with the INFO menu selection. Of course, that's really an editor. Then there is the imagery, manipulated by the ICON editor. Of course, you have to start out by editing an 'icon of the right type' (read, an info file with the right strings already in it). This uglyness comes from seperating the various parts of what is clearly the same function. Perhaps they could put these functions back together in the next release? >As it is, the current Workbench has enough holes in it that I would >label it as unsuitable for the novice user. I have problems with Workbench, but I use both interfaces all the time, and switch back and forth between them. I'd like to see them more compatable, but I think that workbench is already usable for the novice. I think it's unsuitable for the sophisticated user. >| "Talking about music is like dancing about architecture" | >| --Laurie Anderson, "Home of the Brave" | I just love this quote. I left it in out of appreciation. Michael Wagner (wagner@utcs)
keithd@cadovax.UUCP (Keith Doyle) (12/23/86)
In article <1986Dec20.131342.3828@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: >I would offer the opposite 'statement' to Matt's: > >Please fix your file system and drivers. Sooner or later, if you don't, >I'll write and distribute a public domain one that works better! > >Michael This one gets my vote. I want to see the CLI speed up too, not just the Workbench. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa
keithd@cadovax.UUCP (Keith Doyle) (12/23/86)
In article <1986Dec20.144752.5348@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: >>I hate >>being bothered with a bunch of .info files lying around in my >>directory cluttering up the listing of the important stuff there. > >Well, realistically, this is a problem for the CLI user of a workbench >drawer. Not really fair. Sounds like a job for Unix-like 'dot' files (.login, .cshrc etc. ) invisible files that you don't have to see in the CLI unless you specify. >Couldn't agree more. Workbench should certainly put up some sort of >default icon for files without matching .info files. I do like the >ability to hide files from the eyes of the casual user though. Yeah, I mean, like, what kind of 'icon' do you use for a *.info file? (an 'icon' file that is). >Amazingly, no one has mentioned one of the things that bothers me the most >about the current .info scheme. There can only be one .info file per >'real' file. I would like to have two icons that point to the same >executable or tool, with perhaps different options set (i.e. they differ >only in the parameters stored in the .info file). I don't think this is >possible in the current scheme. Anyone know how to do this currently? This sounds like a great idea. Can the Mac do this? Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa
jmpiazza@sunybcs.UUCP (12/24/86)
In article <1278@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >In article <1986Dec20.144752.5348@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: >>... I would like to have two icons that point to the same >>executable or tool, with perhaps different options set (i.e. they differ >>only in the parameters stored in the .info file). I don't think this is >>possible in the current scheme. Anyone know how to do this currently? > >This sounds like a great idea. Can the Mac do this? The Amiga does already. Take a look at the Amiga Basic demos. Each has it's own icon and yet they all point to the Amiga Basic tool. Seems to me that the wheel has already been invented. :-) Flip side, joe piazza --- Cogito ergo equus sum. CS Dept. SUNY at Buffalo 14260 (716) 636-3191, 3180 UU: ...{rocksvax|decvax}!sunybcs!jmpiazza CS: jmpiazza@buffalo-cs BI: jmpiazza@sunybcs GE: jmpiazza
wagner@utcs.UUCP (12/26/86)
I dont think I like the way INEWS does this...so let me provide my own introduction to the cast of characters. >>> is me (original article) >> is keithd@cadovax.UUCP (Keith Doyle) > is jmpiazza@gort.UUCP (Joseph M. Piazza) (no introduction) is me again (remember me?) >>>... I would like to have two icons that point to the same >>>executable or tool, with perhaps different options set (i.e. they differ >>>only in the parameters stored in the .info file). I don't think this is >>>possible in the current scheme. Anyone know how to do this currently? >> >>This sounds like a great idea. Can the Mac do this? I don't know. I've never had a Mac. Anyone know the answer? > The Amiga does already. Take a look at the Amiga Basic demos. Each >has it's own icon and yet they all point to the Amiga Basic tool. Seems to me >that the wheel has already been invented. :-) Um....that's not what I said. Or, at least, that's not what I meant to say. I guess I wasn't very clear. Let me try again. There is already a kind of shorthand implicit in .info files (thank god). First of all, a little terminology. Programs are TOOLS in the workbench. Files that you feed to a program are called PROJECTS. These include BASIC programs, input to word processors, music processors, etc. The .info file for a TOOL points to the program involved. The .info file for a PROJECT points to the input file AND the TOOL that should, by default, process it (other TOOLs can be selected by the user, but lets not diverge here). Several PROJECTs can select the same TOOL. This is the 'shorthand' that is refered to above. I said 'thank god' because otherwise you would have to have a seperate copy of the BASIC interpreter on disk for every BASIC program. My suggestion was that a TOOL (or a PROJECT, for that matter) might have two ICONS (and two .info files), corresponding to different invocation options. For instance, I could have two ICONS, called UNIX and CMS, both of which called up Dave Wecker's VT100 program, but passed it different initialization parameters, so that one called my favorite UNIX system, and one called my favorite CMS system. So, I want Icontype <x>.info Corresponding TOOL Initializer TOOL CMS SYS:c/vt100 CMSinit TOOL UNIX SYS:c/vt100 UNIXinit TOOL PRINTIT SYS:c/vt100 PrettyPrintCMS Notice that the tool isn't called the same thing as the .info file. Notice that .info files point to the same tool. The tool isn't even in the same directory as the .info file. Why is this useful? Suppose I have several uses for a tool like VT100. Sometimes, I converse with UNIX, and I know that I'm using VT100. Sometimes, I converse with CMS. I'd like to call them different things, since the environments look so very different. Sometimes, I want to print a file on the laser printer at work. I have to call it something else...conceptually, it's completely different! But they're all still the VT100 program. The PRINTIT ICON calls up VT100 in script mode, calls work, signs on to CMS, runs KERMIT, sends the file to CMS, has it printed, deletes it from the file system, and signs off. The PRINTIT ICON shouldn't need to have another copy of VT100 attached to it, duplicating all that disk space, just so the user can have a more descriptive name for it! Moreover, I might have PRINTIT ICONS in several different drawers. They may print to different standards (because the drawers are used for different things). I want to be able to run programs out of different drawers, or perhaps in the default PATH (does the workbench implement PATH-like concepts?). Hmmm...I think this is getting too long...I'll stop here. Michael
andy@cbmvax.cbm.UUCP (Andy Finkel) (12/28/86)
In article <1986Dec26.114028.13245@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: > >>>>... I would like to have two icons that point to the same >>>>executable or tool, with perhaps different options set (i.e. they differ >>>>only in the parameters stored in the .info file). I don't think this is >>>>possible in the current scheme. Anyone know how to do this currently? >>> >>>This sounds like a great idea. Can the Mac do this? > >I don't know. I've never had a Mac. Anyone know the answer? > >> The Amiga does already. Take a look at the Amiga Basic demos. Each >>has it's own icon and yet they all point to the Amiga Basic tool. Seems to me >>that the wheel has already been invented. :-) > >Um....that's not what I said. Or, at least, that's not what I meant to say. >I guess I wasn't very clear. Let me try again. > Actually, Michael, why wouldn't a project icon do just what you want... it would allow you to start up a program under a variety of name, using different parameters. It really isn't necessary to expand on the definition of a tool.info file, when the project.info files will do what you want. In both cases, the actual program started is going to have to read the name it was invoked under, and whatever tooltypes parameters that it needs. So what's the difference if its a project.info file that you click on, rather than a tool.info file ? (There's an example of this, in the PCUtils on the V1.2 Extras disk. There's a Project Icon which just invokes the main tool for a different function.) >drawers, or perhaps in the default PATH (does the workbench implement >PATH-like concepts?). No PATH's per say...if you double-click on an icon, by definition, workbench knows where it is. If you're talking about in the default tool, an exact file location is expected there. > >Michael andy finkel -- andy finkel Commodore/Amiga {ihnp4|seismo|allegra}!cbmvax!andy or pyramid!amiga!andy Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors. "Never make anything simple and efficient when it can be complex and wonderful."