mjp@spice.cs.cmu.edu (Michael Portuesi) (12/19/86)
Keywords: I've been meaning to reply to everybody's comments about my original post, but things got in the way (now that finals are over, I've discovered what it's like to actually sit down and read fiction instead of textbooks). In any case: Having icons for every file --------------------------- Chuck McManis: > 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. [...] > 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. Gerard Lachac: > 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!!! :-) No it isn't. What if I wanted to copy some of those files from the c drawer to a new disk? What if I need to delete a few of these lesser-used commands to free up some space on the disk? If you don't let me see them, I can't manipulate them (unless I use the CLI, of course). Opening up the "System" folder on the Mac reveals the System file, the Finder, the Clipboard...why does the user need to see these? So he can copy them elsewhere and delete them if he has to, that's why. If you don't want to see 30 icons on your screen from the c drawer, don't click on it. And you wouldn't have to wait long for these "useless" icons to appear either, if icons were moved to one file instead of many. As for the other stuff the icon contains (like what tool to run, options, etc) simply put up a requester telling them "There is no tool for this project" or something like that. That's what the Finder does on the Mac. As far as screen location, I'm sure the Workbench could figure a suitable default location to place the icon in a window if its not explicitly specified. Not having an Intuition manual, I don't know exactly what is stored in an icon...but I'm willing to bet it could either be ignored or some reasonable defaults supplied. Charles Poirer: > 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. I didn't think about that...but that's certainly an argument in my favor. > While I'm at it, let me add my vote in favor of uniform filename > expansion at the CLI level. And let me add my vote against it. If the CLI has to expand filenames, then under my proposal the Workbench would have to as well. Nothing like duplication of code in concurrent programs wasting memory. Argument passing ---------------- Chuck McManis: > Ever select info after selecting an 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. Andy Finkel: > Setting the ToolTypes field of an icon is meant to do just that. > But you want a quicker way, I guess. Some things? Can I pass everything that CLI can and where is the documentation for this ToolTypes field? I'm not flaming here...I want to be educated. If the ToolTypes field really does have the functionality I describe then my gripe is null. Andy's not altogether far from the truth that I do want a quick way to pass arguments to a command from Workbench. Implementing an argument-passing Mechanism ------------------------------------------ Chuck McManis: > 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. Charles Poirer: > 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. Okay, that's even better than my original suggestion. This would be faster than selecting Info to access the ToolTypes field. Accelerating performance ------------------------ Matt Dillon (from multiple messages): > What I purpose is simply a reorganization in the disk format (one > .info file per folder rather than lots of little ones). This seems > best since things are already arranged in a directory-uniform style. > Placing all the information in a single file in the root directory is > NOT a good idea. > What some of you are proposing would require modifications to the workbench > message format, and that is simply impractical. Eric Lavitsky: > What happens if you accidentally blow away the file that has *all* > the icons in it? Bye bye icons! Okay, so the best method probably is a file of icons per directory. The "great big file" idea was merely a suggestion...as is all my flaming. Matt, I realize you want to make transparent changes to Workbench...but I really do think some more substantial changes to Workbench should be made at the same time. "User-friendly" does not have to equal "User-useless". Why is changing the Workbench message format impractical? Dan Green: > I think the "ideal" situation would be for the linker to reserve > 512 bytes or so as the header for each program, (and fopen'ing a new > file could pad the top with the header also) and then store the .info > in this area. Of course TYPE would have to be smart enough to skip > the header, which is trivial. And so would MicroEmacs and every other program that deals with stream input. Even I'm not radical enough to modify the format of individual files. Eric Lavitsky: > Please queue up mouse events for the Workbench, or at least make it > an option from Prefences (like CLI on)... Not a bad idea, and I think it's worth implementing, but band-aids don't fix leaky pipes...new pipes do. Diskcopy from workbench ----------------------- Chuck McManis: > 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 [etc...] Gerard Lachac: > Hmmmm... every time I use to use the WB for diskcopy it was the > same 3 swaps... except with a cute little window attached! Looks like I got bit on this one...next time I'll make sure I know what I'm talking about before I engage my mouth. My assessment of the workbench diskcopy was from someone else using it on our user group's two-drive system. He didn't know all the details of its operation, and watching it in use turned me off on it from that point on. I didn't attempt to use it on my own one-drive system until Chuck pointed out it wasn't as bad as I thought...I haven't tried his suggestion on a two drive system, but I'm sure he's correct. On my system, it wanted five swaps, but I also had a number of commands in ram: plus PopCLI and a few other programs running, so I wasn't surprised. I take back everything I said about Workbench diskcopy. Andy Finkel: > BTW, under V1.2, the Workbench Diskcopy and the CLI Diskcopy > are the same program. Nice to hear that...two programs to do the same thing is a little silly, even if I don't know what I'm talking about. -- +----------------------------------------------------------------------------+ | 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" | +----------------------------------------------------------------------------+
louie@sayshell.umd.edu (Louis A. Mamakos) (12/19/86)
I want to agree that having a file per directory to store the icon information
rather than a .info file for each file is a big win. And the best thing of all
is that you can make this COMPLETELY TRANSPARENT TO WELL WRITTEN APPLICATIONS.
The GetDiskObject() and related library calls to manipulate icons from
application programs take the name of the file that the icon refers to, NOT
the actual name of the icon (that is, "foo" rather than "foo.info").
All that is needed is the appropriate hacks to the Workbench to display and
manage this per directory file, and perhaps an "icon mover" program to copy
them. I guess you could use the icon editor to perform this function.
Note that the internal stucture of the .info files has NEVER been documented;
only the memory resident stucture that {Get,Put}DiskObject() manipulates.
Programs that hack with the .info files directly are bogus.sean@ukma.ms.uky.csnet (Sean Casey) (12/24/86)
In article <1394@umd5> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >I want to agree that having a file per directory to store the icon information >rather than a .info file for each file is a big win. And the best thing of all Why not just store the icon information in the original file? Having two files is awfully messy. Sean -- =========================================================================== Sean Casey UUCP: cbosgd!ukma!sean CSNET: sean@ms.uky.csnet ARPA: ukma!sean@anl-mcs.arpa BITNET: sean@UKMA.BITNET
sean@ukma.ms.uky.csnet (Sean Casey) (12/24/86)
In article <5394@ukma.ms.uky.csnet> I write: >Why not just store the icon information in the original file? Having two >files is awfully messy. You know, if you did this, you'd also be getting closer to the Unix ideal. :-) Sean -- =========================================================================== Sean Casey UUCP: cbosgd!ukma!sean CSNET: sean@ms.uky.csnet ARPA: ukma!sean@anl-mcs.arpa BITNET: sean@UKMA.BITNET
hutch@sdcsvax.UCSD.EDU (Jim Hutchison) (12/24/86)
<>
This is a conglomeration of thoughts on the issue of icons for workbench.
If you have them in one file, then when you change the size of, or delete
one, then you have a problem. Admittedly this can be fixed by dragging the
data up from the end to cover the hole, but that seems rather timely, and
messy. Icons are changed rarely, so whatever technique is used it can perhaps
be slow in favor of a greater speed in the more general case.
Most of the speed seems to be lost in searching the entire directory for icons.
Some is lost in the multitude of openings which must be done, but it would seem
that searching a directory and sorting out file types is the bigger part.
Perhaps if each directory had a directory called .icons or Icons or whatever
(where are philosophers when you need them? :-), then you could find that
directory (which could be made first, as the method for optimized boot disks.),
and the icons would all be in there. The check for type could be taken away,
and a pair of processes/tasks could be used to display icons.
Why 2? One to read them from disk (which would go into disk wait a lot), and
another to display them (and perhaps make sure that they taste like icons.
The second would wait on the first and then the first would wait on disk while
the other one was displaying the icons. This method might be practical with
the current icon file scheme, any takers?
As to the notion of waiting, perhaps they would pass messages, perhaps a latch
in a word/byte of memory common to the data space of one of the two.
So the tally is 1 workbench change and 1 icon file change, independent.
--
Jim Hutchison UUCP: {dcdwest,ucbvax}!sdcsvax!hutch
ARPA: Hutch@sdcsvax.ucsd.edu
"The more you drive, the less intelligent you are." - "Repo Man"wagner@utcs.UUCP (12/25/86)
In article <5394@ukma.ms.uky.csnet> sean@ukma.ms.uky.csnet (Sean Casey) writes: >In article <1394@umd5> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >>I want to agree that having a file per directory to store the icon information >>rather than a .info file for each file is a big win. > >Why not just store the icon information in the original file? Having two >files is awfully messy. > >Sean Ah, but putting it in the same file is also messy. I think, in general, one wants the icon (and other) information in the .info file to persist even when an executable is replaced by the compiler, or a table is changed by an editor. Stupid programs should be allowed to ignore .info files and not break things. That's what's wrong with FILENOTE...no programs preserve it, because none know it's there. Michael
stever@videovax.Tek.COM (Steven E. Rice, P.E.) (12/31/86)
In article <254@unirot.UUCP>, Mark Carroll (carroll@unirot.UUCP) writes: > . . . I think workbench is horrible. Its slow, its cumbersome, its not > terribly flexible, its a pain the neck. My use of WOrkbench is opening > the CLI on the workbench disk at work. I cannot STAND all those miserable > .info files.. they're handled pretty poorly. . . . The flip side is that my 3-1/2-year-old son can start up SpeechToy *BY* *HIMSELF*, thanks to the Workbench! (He knows which disk is Kickstart, which is Workbench, and which is the Games disk with SpeechToy on it, so he can go from power off to "This is Amiga speaking." without help.) All you wonderful people at Commodore, please listen to these guys, but not *too* closely! If you can improve performance, fine -- but whatever you do, don't sacrifice ease of use!!! Steve Rice ---------------------------------------------------------------------------- {decvax | hplabs | ihnp4 | uw-beaver}!tektronix!videovax!stever
wagner@utcs.UUCP (01/01/87)
In article <4129@videovax.Tek.COM> stever@videovax.Tek.COM (Steven E. Rice, P.E.) writes: > >The flip side is that my 3-1/2-year-old son can start up SpeechToy *BY* >*HIMSELF*, thanks to the Workbench! (He knows which disk is Kickstart, >which is Workbench, and which is the Games disk with SpeechToy on it, so >he can go from power off to "This is Amiga speaking." without help.) > >All you wonderful people at Commodore, please listen to these guys, but >not *too* closely! If you can improve performance, fine -- but whatever >you do, don't sacrifice ease of use!!! AMEN! Part of what is so important about workbench is that it can be used by neophites, and people who aren't particularly computer literate. Hell, I'm not a 3.5 year old, but I also find workbench easy to use. Michael
carolyn@cbmvax.cbm.UUCP (Carolyn Scheppner) (01/05/87)
In article <1987Jan1.122231.12588@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: > >In article <4129@videovax.Tek.COM> stever@videovax.Tek.COM (Steven E. Rice, P.E.) writes: >> >>The flip side is that my 3-1/2-year-old son can start up SpeechToy *BY* >>*HIMSELF*, thanks to the Workbench! > >AMEN! Part of what is so important about workbench is that it can be >used by neophites, and people who aren't particularly computer literate. I never fully realized the power and simplicity of the whole gadget/menu Intuition interface until this past holiday weekend. With almost no instruction, various visiting relatives were able to use gadgets and menus. They played games and drew pictures and amused themselves for hours. The mouse-clickers included a 4-year-old who can't color inside the lines and an older relative who despite repeated instruction can not insert modular phone connectors. I was amazed. carolyn -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Carolyn Scheppner -- CBM >>Amiga Technical Support<< UUCP ...{allegra,caip,ihnp4,seismo}!cbmvax!carolyn PHONE 215-431-9180 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
keithd@cadovax.UUCP (Keith Doyle) (01/12/87)
In article <1986Dec24.191136.2866@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: >>In article <1394@umd5> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >>Why not just store the icon information in the original file? Having two >>files is awfully messy. > >Ah, but putting it in the same file is also messy. I think, in general, >one wants the icon (and other) information in the .info file to persist >even when an executable is replaced by the compiler, or a table is changed >by an editor. Stupid programs should be allowed to ignore .info files and >not break things. That's what's wrong with FILENOTE...no programs preserve >it, because none know it's there. There's an interesting idea, I wonder if you can append your file data to the end of a *.info file without confusing the system, i.e. will the workbench not try to read an entire 100k *.info file before displaying the icon etc. You could then write a word processor, or paint program or whatever, that saved all of its files with the .info portion as a header, while always keeping the .info at the end of the name. Would cut your directory list in half. Probably wouldn't speed up the workbench much though. While I'm here, I'd like to reiterate my position on this stuff: I don't spend much time in the workbench, I don't CARE much how fast icons appear. What I DO care about is how fast directory lists within applications appear, and how fast the CLI 'dir' command displays. The single 'icon' file approach would work only if all applications, such as DPaint, DMCS, Scribble, etc. etc. etc. read the single 'icon' file to get their directory lists, and kept the file updated. Well big news: they DON'T. I don't spend that much time on a workbench compared to how much time I spend in an application. If you can't either: 1) provide a fix that is transparent to the application, or 2) get all the applications writers to update their code to use a new scheme, then I think all this discussion about icon files is moot. Keith Doyle # {ucbvax,ihnp4,decvax}!trwrb!cadovax!keithd # cadovax!keithd@ucla-locus.arpa
louie@sayshell.umd.edu (Louis A. Mamakos) (01/13/87)
In article <1318@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >In article <1986Dec24.191136.2866@utcs.uucp> wagner@utcs.UUCP (Michael Wagner) writes: >>>In article <1394@umd5> louie@sayshell.umd.edu (Louis A. Mamakos) writes: >>>Why not just store the icon information in the original file? Having two >>>files is awfully messy. >> >>Ah, but putting it in the same file is also messy. I think, in general, >>one wants the icon (and other) information in the .info file to persist >>even when an executable is replaced by the compiler, or a table is changed >>by an editor. Stupid programs should be allowed to ignore .info files and >>not break things. That's what's wrong with FILENOTE...no programs preserve >>it, because none know it's there. First of all, I didn't make the statement 'Why not store the icon information in the original file?', nor would I ever. It is a stupid idea. In the second place, you CAN INDEED STORE ALL THE ICONS IN A SINGLE FILE WITHOUT CHANGING ANY WELL WRITTEN PROGRAMS. Period. You just have to hack icon.library to look in a different place, and create/update icons differently. The solution exists. The problem (can be) is solved. Louis A. Mamakos WA3YMH Internet: louie@TRANTOR.UMD.EDU University of Maryland, Computer Science Center - Systems Programming
AXN100@psuvm.psu.edu (12/02/90)
Is there anyway to make a boot disk other than copying WB and then
deleting everything that you don't want.
Thanksessercm@sage.cc.purdue.edu (Chris Esser) (12/02/90)
In article <90335.120823AXN100@psuvm.psu.edu> AXN100@psuvm.psu.edu writes: > > Is there anyway to make a boot disk other than copying WB and then >deleting everything that you don't want. > > > Thanks Yes, a very easy way. Merely stick a formatted disk in one of the drives, and use the cli command "install." The syntax for a disk in drive 0 is: install drive df0: Once you have done that, the disk has a boot block. You must then create your "s" directory for the disk's startup-sequence, and a "c" directory for the commands you wish to use. Or, once you have installed the disk, just copy what you want on the disk, to the disk. -Chris
joseph@valnet.UUCP (Joseph P. Hillenburg) (12/02/90)
AXN100@psuvm.psu.edu writes: > > Is there anyway to make a boot disk other than copying WB and then > deleting everything that you don't want. > > > Thanks Yeah. Here's basically the minimum for a bootable disk: C: loadwb endcli echo more (MuchMore, PPMore, whatever) L: disk-validator ram-handler port-handler libs: icon.library arp.library (optional but recommended) info.library devs: system-configuration serial.device s: startup-sequence Those take up ~80k. Then just use a program like WB1.3:C/Install or BootDoctor from Amiga Resource. (Much better.) Joseph Hillenburg Secretary, Bloomington Amiga Users Group joseph@valnet.UUCP ...!iuvax!valnet!joseph "Only Apple could slow down a 68030 chip." -Computer Shopper
peterk@cbmger.UUCP (Peter Kittel GERMANY) (12/03/90)
In article <90335.120823AXN100@psuvm.psu.edu> AXN100@psuvm.psu.edu writes: > > Is there anyway to make a boot disk other than copying WB and then >deleting everything that you don't want. Yes, just: 1. FORMAT a blank disk 2. INSTALL it (CLI command) 3. MAKEDIR s 4. Use ED to create a file s/Startup-Sequence All further steps depend on what your software needs as further resources. If you don't know much about Amiga system, this is the hard part. 5. If needed, create subdirectories l, libs, devs, devs/printers, devs/keymaps, c, and fill them with the needed files. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk