rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) (02/23/89)
Maybe now is the time to say what I want in 1.4 instead of asking why the
things aren't there when it comes.
- New files should have their icons rendered automatically by workbench.
Having to close the window and reopening it is not good.
(Send a FILECREATED/DELETED) message to all tasks wanting to find out
whether files have been created/deleted in certain directories.
- If I drag an icon onto the workbench screen outside it's window it should
stay there until I move it back (should be there after boot).
- A printer icon would be a nice hack. Just drag what you want to print onto
the icon and drop it..
- A postscript printer driver.
- A extendable preferences program (calling sub-preferences-program)
This would give place for extra preferences. For example a
dmouse-preferences and the like. Maybe the features of dmouse could be
included as standard (selectable with preferences of course).
- An autoexec-directory: execute all programs and scripts in this
drawer on startup. Then I would only have to drag icons into this
directory to make them part of my startup.
- More intuition things. Like a scrolling `requester'. *Standard* font
and file requesters [GimmeFileName] (don't like the jungle). Draggable
gadgets. A library of routines making intuition programming *easy*.
- A 'national.library' with information about date-format, collating sequences
and other things that vary between countries.
If these things are already there, fine. Otherwise, don't say nobody asked for
them.
hmm, I probably forgot something.
----
Robin Rosenberg, ]bo Akademi, FINLAND
Address: Finn|, 22340 Geta, ]LAND - FINLAND
or Studentbyn 40A3, 20510 ]BO, FINLAND
Translation: ']' is an 'A' with a ring on top, '|' is an 'o' with two dots.usenet@cps3xx.UUCP (Usenet file owner) (03/01/89)
In article <5442@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes: >Maybe now is the time to say what I want in 1.4 instead of asking why the >things aren't there when it comes. > Me too. Make programs resident *automatically* if their pure bit is set. Then purge them, as is done with other things, automatically when memory is low. This should work from CLI, SHELL, WORKBENCH or anyprogram that uses LoadSeg or Execute. You should have the option of locking a program in memory so it will not be purged, but in general there should be no need to worry about which programs to residentize. Make the NewShell and *real* shell with actual built in commands for shell scripting; even messydos does this. I suppose this would not be too necessary if an AREXX like thing is supplied. Make the workbench programmable with WorkBench Scripts. YOu could make a command file to automatically open disks, drawers, programs. If there was a record option then WorkBench could write the script itself. None of this should depend on absolute coordinates on the sceen or in a window; it would all have to be done by filenames and such. Obviously I have not worked out the details for this idea.
panzer@apple.ucsb.edu (Panzer, John Robert) (03/01/89)
Another thing: Have the list of resident commands survive a reboot. (If viruses can do it, so can the Good Guys :^) -John Panzer
jms@antares.UUCP (Joe Smith) (03/01/89)
In article <5442@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes: >Maybe now is the time to say what I want in 1.4 instead of asking why the >things aren't there when it comes. > ... >- An autoexec-directory: execute all programs and scripts in this > drawer on startup. Then I would only have to drag icons into this > directory to make them part of my startup. If this is implemented, make sure it doesn't have the same problems as the AUTO folder on the Atari ST. Several initialization programs will not work unless they are executed in a particular order. I like the idea of being able to include a new startup by simply moving its icon into the drawer, as long as there is a way to say "execute these files first, it this order, then everything else in this directory". -- Joe Smith (408)922-6220 | jms@antares.Tymnet.COM or jms@opus.Tymnet.COM McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!antares!jms PO Box 49019, MS-D21 | PDP-10:JMS@F74.Tymnet.COM CA license plate:"POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
jms%antares.uucp@cunyvm.cuny.edu (03/01/89)
In article <5442@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ] bo Akademi) writes: >Maybe now is the time to say what I want in 1.4 instead of asking why the >things aren't there when it comes. > ... >- An autoexec-directory: execute all programs and scripts in this > drawer on startup. Then I would only have to drag icons into this > directory to make them part of my startup. If this is implemented, make sure it doesn't have the same problems as the AUTO folder on the Atari ST. Several initialization programs will not work unless they are executed in a particular order. I like the idea of being able to include a new startup by simply moving its icon into the drawer, as long as there is a way to say "execute these files first, it this order, then everything else in this directory". -- Joe Smith (408)922-6220 | jms@antares.Tymnet.COM or jms@opus.Tymnet.COM McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!antares!jms PO Box 49019, MS-D21 | PDP-10:JMS@F74.Tymnet.COM CA license plate:"POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
jms%antares.uucp%cunyvm.cuny.edu@cunyvm.cuny.edu (03/02/89)
In article <5442@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ] bo Akademi) writes: >Maybe now is the time to say what I want in 1.4 instead of asking why the >things aren't there when it comes. > ... >- An autoexec-directory: execute all programs and scripts in this > drawer on startup. Then I would only have to drag icons into this > directory to make them part of my startup. If this is implemented, make sure it doesn't have the same problems as the AUTO folder on the Atari ST. Several initialization programs will not work unless they are executed in a particular order. I like the idea of being able to include a new startup by simply moving its icon into the drawer, as long as there is a way to say "execute these files first, it this order, then everything else in this directory". -- Joe Smith (408)922-6220 | jms@antares.Tymnet.COM or jms@opus.Tymnet.COM McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!antares!jms PO Box 49019, MS-D21 | PDP-10:JMS@F74.Tymnet.COM CA license plate:"POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
armhold@topaz.rutgers.edu (George Armhold) (03/02/89)
>have the resident commands survive a warm-reboot. I don't think that would be a good idea- the reason for warm-booting is usually to clear all ram, no? -George -- -------------------------------------------------------------------------------- armhold@topaz.rutgers.edu| "If I go insane, please don't put you wires | | | | in my brain." - R. Waters (me) | (school) | | | (machine) | (OB quote) (someone else) -------------------------------------------------------------------------------- (NEW and IMPROVED signature, with object identifiers.)
pds@quintus.uucp (Peter Schachte) (03/02/89)
How about a real biggie: a unified way of launching programs from both the CLI and the workbench. This should include a way of passing arguments INCLUDING SWITCHES, not just files. Yeah, I know, dream on.... -Peter Schachte pds@quintus.uucp ..!sun!quintus!pds
deven@pawl.rpi.edu (Deven Corzine) (03/02/89)
In article <Mar.1.17.50.06.1989.9522@topaz.rutgers.edu> armhold@topaz.rutgers.edu (George Armhold) writes: >>have the resident commands survive a warm-reboot. > >I don't think that would be a good idea- the reason for warm-booting is >usually to clear all ram, no? No. More often it is to reset the system to a known state, and a significant percentage of the reboots are accidental, resulting from GURUs and crashes which don't even GURU but just display neat fireworks displays. Having resident programs recoverable would be VERY valuable. Not automatically; do it similarly to RAD: - a "resident recover" command in the startup-sequence or some such. Of course, the resident seglists should be protected by 32 bit CRC's so you don't end up with corrupted versions because of the last crash. In short, I strongly agree: Make resident commands recoverable!! Deven -- ------- shadow@pawl.rpi.edu ------- Deven Thomas Corzine --------------------- Cogito shadow@acm.rpi.edu 2346 15th Street Pi-Rho America ergo userfxb6@rpitsmts.bitnet Troy, NY 12180-2306 (518) 272-5847 sum... In the immortal words of Socrates: "I drank what?" ...I think.
vinsci@abo.fi (Leonard Norrgard) (03/03/89)
In article <413@antares.UUCP>, jms@antares.UUCP (Joe Smith) writes: > In article <5442@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes: >>Maybe now is the time to say what I want in 1.4 instead of asking why the >>things aren't there when it comes. >> ... >>- An autoexec-directory: execute all programs and scripts in this >> drawer on startup. Then I would only have to drag icons into this >> directory to make them part of my startup. > > If this is implemented, make sure it doesn't have the same problems as the > AUTO folder on the Atari ST. Several initialization programs will not work > unless they are executed in a particular order. >... VMS fixed this by adding a command called synchronize. At boot time, the idea is that you submit jobs to the batch queues and of course some of them are dependent of others. Ie. most will need to wait for the job mounting all the disks etc. Since the batches run as separate processes, the task of synchronize is to wait for another batch job to complete. Well, that's VMS. On the Amiga, a different approach must be taken since most of the startup is obviously performed in the context of a single process. Thus, the startup code would have to determine the right order of execution *before* the execution begins. This could probably be achieved in many different ways of which one is outlined below. In a reasonably well equipped Amiga system, the user will have multiple applications, harddisks, extra hardware etc. Each may require its own startup code, and some will need to wait for others to complete before they are run. Some bigger applications may even need multiple scripts to that are to be performed in a special order. Usually, applications needn't know of each other, and thus doesn't need a mutually specific execution order. So how can we specify the order? We already have the #?.info files available from the icons we drag into our autoexec directory. The icon system have provisions for adding text into the tooltypes array of the icon. So by placing directives about the dependancies and execution orders here, the startup code would only have to read the .info files. That's cheap -- it doesn't have to do a contextswitch form one scriptfile to another just to check their possible relations. The output of the .info scan would be an ordered list of files to execute. So what would the directives look like? Well, how about: ANYTIME -- Execute me at any point relative to the other startup scripts in this directory, except for the FIRST script which will always be the first. If no other type is specified, ANYTIME is the default. AFTER name_of_other_script -- Execute me sometime after `name_of_- other_script' has been executed, not necessarily directly after it. AFTER FIRST isn't needed as ANYTIME already specifies this. FIRST -- Obvious meaning. Only one of these in the directory though. ANYTIME scripts will be executed after this. SLAVE master -- This is a slave script of the `master' script. As such, it is the `master' script's job to execute this in a way chosen by the master script. While at it, please enhance the "tool types" gadget of the info program to a couple of lines, it seems more and more programs get configured this way, with more and more parameters to set. Comments? -- Leonard Norrgaard, vinsci@abo.fi, vinsci@finabo.bitnet, +358-21-654474, EET.
panzer@banana.ucsb.edu (Panzer, John Robert) (03/03/89)
In article <Mar.1.17.50.06.1989.9522@topaz.rutgers.edu> armhold@topaz.rutgers.edu (George Armhold) writes: >>have the resident commands survive a warm-reboot. > >I don't think that would be a good idea- the reason for warm-booting is >usually to clear all ram, no? > Yes, it should be an option, like remounting a recoverable RAM disk. It would save a LOT of time when you have an involuntary reboot (a.k.a. Guru) and want to go back and try again. (Most of my reboots are involuntary :^) - John Panzer (panzer@cornu.ucsb.edu) (panzer@apple.UUCP)
rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) (03/03/89)
In article <5899@abo.fi>, vinsci@abo.fi (Leonard Norrgard) writes: > In article <413@antares.UUCP>, jms@antares.UUCP (Joe Smith) writes: >> In article <5442@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes: >>>Maybe now is the time to say what I want in 1.4 instead of asking why the >>>things aren't there when it comes. >>> ... >>>- An autoexec-directory: execute all programs and scripts in this >>> drawer on startup. Then I would only have to drag icons into this >>> directory to make them part of my startup. >> >> If this is implemented, make sure it doesn't have the same problems as the >> AUTO folder on the Atari ST. Several initialization programs will not work >> unless they are executed in a particular order. >>... > So what would the directives look like? Well, how about: > > ANYTIME -- Execute me at any point relative to the other startup > scripts in this directory, except for the FIRST script > which will always be the first. If no other type is > specified, ANYTIME is the default. > AFTER name_of_other_script -- Execute me sometime after `name_of_- > other_script' has been executed, not necessarily directly > after it. AFTER FIRST isn't needed as ANYTIME already > specifies this. > FIRST -- Obvious meaning. Only one of these in the directory though. > ANYTIME scripts will be executed after this. > SLAVE master -- This is a slave script of the `master' script. As > such, it is the `master' script's job to execute this > in a way chosen by the master script. > This is one possibe approach. Another simpler would be that the arrangement of icons would determine the order of execution. Arrange the icons in pretty rows and columns. Then execute first on first row,secons on first row... first on second row... and so on. This scheme obviously has some problems connected to it: how do we determine if an icon is on the same row or the row under it or above. A single pixel could make the difference. Is there a reasonable solution? Another would be a special program to set startup priorities. Continuing this autodrawer story. This would be a very simple solution to the problem of software installation that was discused earlier on News. An application startup icons would represent the program and when executed (in the AutoDrawer) it would do necessary assign. The user should ofcourse set these by the means of entries in the tooltypes array. Or since we have environment variables it might be better to set these than assigning everything. > While at it, please enhance the "tool types" gadget of the info program > to a couple of lines, it seems more and more programs get configured this > way, with more and more parameters to set. Yes. And let me bring up more than one info-window at once and make workbench work in parallel with the info program. And make it tell me how much files/bytes/directories there is in folders and... > Leonard Norrgaard, vinsci@abo.fi, vinsci@finabo.bitnet, +358-21-654474, EET. At least I started a discussion, didn't I? Since 1.4 isn't out we should tell CBM what we want there. They just have to pick the best ideas FOR FREE! ---- Robin Rosenberg, ]bo Akademi, FINLAND Address: Finn|, 22340 Geta, ]LAND - FINLAND or Studentbyn 40A3, 20510 ]BO, FINLAND Translation: ']' is an 'A' with a ring on top, '|' is an 'o' with two dots.
sparks@corpane.UUCP (John Sparks) (03/04/89)
In article <DEVEN.89Mar1203856@daniel.pawl.rpi.edu>, deven@pawl.rpi.edu (Deven Corzine) writes: > In article <Mar.1.17.50.06.1989.9522@topaz.rutgers.edu> armhold@topaz.rutgers.edu (George Armhold) writes: > >>have the resident commands survive a warm-reboot. > > > >I don't think that would be a good idea- the reason for warm-booting is > >usually to clear all ram, no? > > No. More often it is to reset the system to a known state, and a > significant percentage of the reboots are accidental, resulting from > GURUs and crashes which don't even GURU but just display neat > fireworks displays. Having resident programs recoverable would be > VERY valuable. Not automatically; do it similarly to RAD: - a > "resident recover" command in the startup-sequence or some such. Of > course, the resident seglists should be protected by 32 bit CRC's so > you don't end up with corrupted versions because of the last crash. > > In short, I strongly agree: Make resident commands recoverable!! If you are saying allow a bit to be set that will tell the amiga whether or not to keep the resident commands upon a warm re-boot, then I agree. But I don't think that resident commands should always survive a re-boot. There are many times that I reboot from my amigaDos disk to run a paticularly memory hungry program such as Deluxe Photo Lab, and I would not want the resident commands eating up valuable memory. That was why I re-booted in the first place, to get more memory free. I would rather not have to turn the machine off and back on again. wear and tear.. wear and tear.. -- John Sparks // Amiga | {rutgers|uunet}!ukma!corpane!sparks \X/ UUCP | >> call D.I.S.K. @ 502/968-5401 thru 5406 << Beware of quantum ducks: Quark, Quark.
usenet@cps3xx.UUCP (Usenet file owner) (03/04/89)
In article <5899@abo.fi> vinsci@abo.fi (Leonard Norrgard) writes: >In article <413@antares.UUCP>, jms@antares.UUCP (Joe Smith) writes: >> In article <5442@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes: >... >is obviously performed in the context of a single process. Thus, the startup >code would have to determine the right order of execution *before* the >execution begins. This could probably be achieved in many different ways A better idea. Since everything else on the Amiga is prioritized, simple apply the same to the startup-sequence-directory (please use a shorter name :-] ) Each file would have a priority assigned, from -128 to +127. Startups for application programs would be zero. Startups for xtra hardware would have higher numbers. Commodore could dictate a 'standard' range for each type of thing so that the priority could be preset without users needing to worry. example: you should use 100-127 for confinguring extra mem if needed. 50-99 for filesystems 25-49 for networks -20 to 20 for applications -128 to -20 for things you probably don't want anyways Joe Porkka porkka@frith.egr.msu.edu
chas@gtss.gatech.edu (Charles Cleveland) (03/04/89)
Do all the following nested responses confuse you? They sure as hell confuse me. In article <5970@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes: )In article <5899@abo.fi>, vinsci@abo.fi (Leonard Norrgard) writes: )> In article <413@antares.UUCP>, jms@antares.UUCP (Joe Smith) writes: )>> In article <5442@abo.fi> rosenbergr@abo.fi (Robin Rosenberg, Computer Science, ]bo Akademi) writes: )>>>- An autoexec-directory: execute all programs and scripts in this )>>> drawer on startup. Then I would only have to drag icons into this )>>> directory to make them part of my startup. )>> )>> If this is implemented, make sure it doesn't have the same problems as the )>> AUTO folder on the Atari ST. Several initialization programs will not work )>> unless they are executed in a particular order. )>>... )> So what would the directives look like? Well, how about: )> )> ANYTIME -- Execute me at any point relative to the other startup )> scripts in this directory, except for the FIRST script )> which will always be the first. If no other type is )> specified, ANYTIME is the default. Other directives omitted for space. ) )This is one possibe approach. Another simpler would be that the arrangement )of icons would determine the order of execution. Arrange the icons in pretty )rows and columns. Then execute first on first row,secons on first row... )first on second row... and so on. This scheme obviously has some problems )connected to it: how do we determine if an icon is on the same row or the )row under it or above. A single pixel could make the difference. Is there )a reasonable solution? Another would be a special program to set startup )priorities. ^ |-------All we need is this program. It will probably never be written. The rest is not the problem. The problem is that the poor (possibly naive) user is responsible for determining the order of execution because he determines the arrangement of the icons. If he knows enough to do this, he can probably write his own startup-sequence anyway and will probably be much more comfortable doing so. The directive approach might be one that the vendor could use to set up his startup stuff so that it would work in the absence of any enlightenment on the part of the user. But even then, if he thinks his sequence should execute after Mount_HD and the user has a Mount_Supra instead (or a Mount_Rushmore -- he could name it anything), then he's in real trouble. A system using names is hopeless without standardization of those names. In general the names can be arbitrary. Imagine trying to produce a makefile (we are taking about producing a makefile, aren't we?) when you don't know what the names of the units will be. A priority system might be more useful, but priorities are linear and the dependencies between various pieces of hardware and software aren't, but can be quite complex, requiring intelligence to sort out. There may conceivably be configurations where it is necessary to mount two systems *simultaneously* (though I don't expect either to reach market). I suspect that it can be shown that there is no set of priorities which works in all situations. Actually, I like the makefile analogy. I think it might be useful to think about how a makefile describing the dependencies of various system units could be constructed and how it might have to be changed when a new unit is introduced. Instead of $(OBJECTS) one might have $(HARD-DISKS). But I think that the organization must be centralized and that it cannot be in general captured merely by associating attributes with particular files such as Mount_HD, without regard to what other files may be in the picture. -- - It is better for civilization to be going down the drain than to be - - coming up it. -- Henry Allen - Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332-0430 UUCP: ...!gatech!gtss!chas INTERNET: chas@gtss.gatech.edu
sparks@corpane.UUCP (John Sparks) (03/07/89)
> [talk about a startup drawer for workbench and methods of deciding ] > [ which task gets executec first] How about this: each icon info file has a part that tells it where to appear on the screen. Use this to determine which task gets executed first. The novice user just has to open the startup window, arrange his icons left to right, top to bottom like: 1 2 3 4 5 6 then select them all and do a snapshot. Upon startup, the amiga can look at the .info files and find their starting location and use that to decide which one gets executed first. -- John Sparks // Amiga | {rutgers|uunet}!ukma!corpane!sparks \X/ UUCP | >> call D.I.S.K. @ 502/968-5401 thru 5406 << Don't worry if you're a kleptomaniac, you can always take something for it.
paolucci@snll-arpagw.UUCP (Sam Paolucci) (03/09/89)
About file links in 1.4? I would think that it would not be too hard to do.-- -+= SAM =+- "the best things in life are free" ARPA: paolucci@snll-arpagw.llnl.gov
jms@antares.UUCP (Joe Smith) (03/13/89)
In article <416@corpane.UUCP> sparks@corpane.UUCP (John Sparks) writes: >> [talk about a startup drawer for workbench and methods of deciding ] >> [ which task gets executec first] > >How about this: each icon info file has a part that tells it where to appear >on the screen. Use this to determine which task gets executed first. I thought of that, but rejected the idea. What happens when the unsuspecting user changes the size of the window and selects "Clean Up" from the Workbench menu. Or what about the naive user who rearranges the icons to make them more aestheticly pleasing (all the mostly white icons to the left, the mostly black ones on the right, roundish ones above the rectangular ones, etc.) While it is true that positioning icons is simpler than editing a startup script, it may be too easy. The desktop metaphor (Workbench) does not put any significance on the position of an icon other than 1) it was under the pointer when clicked and 2) which window/drawer/disk it was over when dragged. Making one window sensitive to position (while all others are not sensitive) is counter-intuitive (pun indended) and is more likely create rather than eliminate problems in the hands of the uninitiated. I believe that a script file is necessary, but should be painless to update. For example, a program like BindDrivers could be modified to read a file such as s:binddrivers-sequence and compare the list of file names there with what's currently in the Expansion drawer. A name in the list but not in the drawer implies that the user has removed the program; its name should be deleted from the list automatically. When a program is detected that is not in the list, the "drivers" program could put up a requester asking whether the new program should be put at the beginning of the list, at the end of the list, or other. (The "other" choice could be implemented by allowing the user to pick up the box that has the name of the new program with the mouse and dropping it on the current list at the desired place.) Note that the user would have to answer the requester only once per set of additions, and only if the user has not already updated the sequence file. In general, we could use a program that allows the user to edit the startup-sequence using the mouse only (no keyboard). I have some thoughts on this if anyone's interested. -- Joe Smith (408)922-6220 | jms@antares.Tymnet.COM or jms@opus.Tymnet.COM McDonnell Douglas FSCO | UUCP: ...!{ames,pyramid}!oliveb!tymix!antares!jms PO Box 49019, MS-D21 | PDP-10:JMS@F74.Tymnet.COM CA license plate:"POPJ P," San Jose, CA 95161-9019 | narrator.device: "I didn't say that, my Amiga did!"
michael@stb.UUCP (Michael) (03/20/89)
Regarding resident saving over reboots, and someone's reply "But what if I want to clear memory for a big program?" Two ideas: resident clear -- clear all resident programs resident command clear -- clear the specified command resident nosave -- do not recover at the next reboot. Michael : --- : Michael Gersten uunet.uu.net!stb!michael : michael@stb.uu.net <mx mailers> crash!gryphon!denwa!stb!michael : "Robitussin" for computers? This has gone too far. Where's "Penicillian"? : (rob. is Coff-medicine to let COFF people run bsd-dependent GNU stuff).