wbnsnsr@nmtsun.nmt.edu (William Norris) (10/21/88)
In article <10744@ulysses.homer.nj.att.com> eric@hector.UUCP writes: >I see no point to have the names of other programs to run in a standard >application menu. This is what the WorkBench/CLI is for. OK, I agree. I just wanted to see what the responses I would get about including this ``feature''. No one seems to want it. Should we add a color palette requester? On this menu? Somewhere else? File Menu >Delete doesn't belong here - use the WorkBench/CLI. OK, but then applications shouldn't close WorkBench. Edit Menu >Looks fine to me except you have two menu selections now with Amiga-P >as the key shortcut. Perhaps Amiga-I (for "Insert") would be more >appropriate for paste? Oops, my mistake. Paste should have been Amiga-V. The reason for X (Cut) C (Copy) V (Paste) is because these three keys are in a line together. You can quickly do these three operations without removing your hand from the Amiga key while at the same time move your mouse around easily. Font Menu >There should not be a seperate font menu - there will always be systems >with more font names than can fit nicely into one menu, unless one >implements scrollable menus/submenus (like on my 630MTG or the Mac/Too). Does anybody know how to implement scrollable menus? If not, then I think it should be moved. For those people who have asked where these key combinations come from, the Macintrash. For those people who expressed concerns about the file requesters, more information will be prepared this weekend. However, I plan on implementing some ``hooks'' for applications to customize/enhance the requester for their specific application. The main purpose of providing these requesters is for those applications which simply present a string gadget and say, ``Type in the filename: '' William B. Norris IV wbnsnsr@nmtsun.nmt.edu (William Norris) | /// Seulement ``It'll be out RSN.'' |\\ /// l'Amiga peut -- ANY hardware manufacturer/software publisher. | \\// vous l'offrir.
coco@sfsup.UUCP (+Lugo F.) (10/21/88)
How about designing a standard set of functions which every file
requester should have (i.e. a minimum set.) For example:
o multitask while scanning for files,
o access to available devices and volumes, not pre-defined
gadgets with device names
o scroll bar, arrow gadgets, double click selection,
o keyboard shortcuts (i.e. use arrow keys to scroll file list,
ALT+arrows to go to the top/bottom files, SHIFT+arrows to
scroll by pages, Ok/CANCEL shortcuts, etc.
o pattern specifications (*, ?, ranges, etc.)
o PARENT directory gadget (with keyboard shortcut).
o RESTART gadget for restarting file scanning
o single file name string gadget
o any other I may be missing
Let's face it, some people have better things to do than spend their
time developing/testing simple file requesters.
Others can just create their own designs as long as they start with
this minimum set.
Other standards: CUT/PASTE, how about pop-up menus (don't you get
tired of going to the top for menu operations.), window iconizing
(with true image icons, not window fakes), Virtual screens, color
requesters which adjust to screen's type/resolution, more, morE, moRE,
mORE, MORE, MORE, MORE, ... 8*)
//
--Coco \X/
__________________________________________________________
E-Mail: coco@attunix.att.com
Real:
AT&T Bell Laboratories
c/o Felix A. Lugo
190 River Road
Rm. 1-139
Summit, NJ 07901
Tel. (201) 522-5098jms@antares.UUCP (joe smith) (10/24/88)
In article <2287@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >One problem I have been struggling with somewhat with file requesters is >that I would like to keep the file list around, but if you have multiple >file requesters for different file operations, how many lists of files >should you actually maintain? Keeping a list of what's in a directory is great, as long as you can guarentee that nothing has changed the directory behind your back. Think of how frustrating it would be if a program refused to acknowlege the existance of a file that you had just created from another window. This is a worth-while idea; caching a list of file names. To make it workable though requires a change to AmigaDOS. If programs kept a lock on the directory that the list came from, then all we need is a new function to tell AmigaDOS to send us a message whenever the directory changes. The messsage is a signal to the program to flush its file name cache. -- +----------------------------------------------------------------------------+ | TYMNET:JMS@F29 CA:"POPJ P," UUCP:{ames|pyramid}oliveb!tymix!antares!jms | | INTERNET: (Office-1.ARPA is no more) PHONE:Joe Smith @ (408)922-6220 | +----------------------------------------------------------------------------+
kevin@amdahl.uts.amdahl.com (Kevin Clague) (10/24/88)
In article <221@antares.UUCP> jms@antares.UUCP (joe smith) writes: >In article <2287@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: >>One problem I have been struggling with somewhat with file requesters is >>that I would like to keep the file list around, but if you have multiple >>file requesters for different file operations, how many lists of files >>should you actually maintain? > >Keeping a list of what's in a directory is great, as long as you can >guarentee that nothing has changed the directory behind your back. Think >of how frustrating it would be if a program refused to acknowlege the >existance of a file that you had just created from another window. Keeping a list of the files around is pretty much a requirement, unless you plan on re-scanning the disk everytime the user scrolls the area you use to display the available files. I don't think Keith is keeping the files in a list to enhance performance, but to provide functionality. > >This is a worth-while idea; caching a list of file names. To make it >workable though requires a change to AmigaDOS. If programs kept a lock >on the directory that the list came from, then all we need is a new >function to tell AmigaDOS to send us a message whenever the directory >changes. The messsage is a signal to the program to flush its file name >cache. This would be a nice feature. I like the idea. >-- >+----------------------------------------------------------------------------+ >| TYMNET:JMS@F29 CA:"POPJ P," UUCP:{ames|pyramid}oliveb!tymix!antares!jms | >| INTERNET: (Office-1.ARPA is no more) PHONE:Joe Smith @ (408)922-6220 | >+----------------------------------------------------------------------------+ Kevin -- UUCP: kevin@amdahl.uts.amdahl.com or: {sun,decwrl,hplabs,pyramid,seismo,oliveb}!amdahl!kevin DDD: 408-737-5481 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 [ Any thoughts or opinions which may or may not have been expressed ] [ herein are my own. They are not necessarily those of my employer. ]
jesup@cbmvax.UUCP (Randell Jesup) (10/25/88)
In article <221@antares.UUCP> jms@antares.UUCP (joe smith) writes: >Keeping a list of what's in a directory is great, as long as you can >guarentee that nothing has changed the directory behind your back. Think >of how frustrating it would be if a program refused to acknowlege the >existance of a file that you had just created from another window. Just do an Examine, and compare the change data for the directory with the old change date: if they're different, something may have changed. If not, not problem. -- You've heard of CATS? Well, I'm a member of DOGS: Developers Of Great Software. Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
jones@ingr.UUCP (Mark Jones) (10/25/88)
> Keeping a list of the files around is pretty much a requirement, unless > you plan on re-scanning the disk everytime the user scrolls the area > you use to display the available files. I don't think Keith is keeping > the files in a list to enhance performance, but to provide functionality. > > > > >This is a worth-while idea; caching a list of file names. To make it > >workable though requires a change to AmigaDOS. If programs kept a lock > >on the directory that the list came from, then all we need is a new > >function to tell AmigaDOS to send us a message whenever the directory > >changes. The messsage is a signal to the program to flush its file name > >cache. It would be even nicer, if AmigaDOS would just cache the filenames of all the directories on all the disks that are physically in the drives, up to a limited number of files(Hard disks could provide a problem here). Then, the application could rescan the directory every time, and never have to hit the disk again. When the disk is ejected, wipe that portion of the cache, don't refill it until the directory is scanned again. Anytime files were added to the directory, both the disk and the cache could be updated, or the cache could be thrown away. This would mean that the disk would only be searched once, and that only one copy of the directory would be kept, regardless of the number of applications running. This already happens to a limited extent, when the directory portions get cached in the track buffers, and it is very nice. It doesn't even seem that hard to do. Mark Jones
pds@quintus.uucp (Peter Schachte) (10/26/88)
In article <5092@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <221@antares.UUCP> jms@antares.UUCP (joe smith) writes: that there should be a way for a program to signal that a directory has changed so a program that display the dir notices the change. (correct me if I misunderstood). > Just do an Examine, and compare the change data for the >directory with the old change date: if they're different, something may >have changed. If not, not problem. This would work fine, except WHEN do you check? You certainly check when you go to display the directory. But suppose you're displaying the directory when a file is added, and you want the display to be updated right away. Does your program check the change date for the directory every few seconds just to see if something has changed? Wouldn't this create a lot of useless disk accesses? The problem with allowing programs to signal when a directory has changed is that lots of (most) programs wouldn't do it, so the directory displays would still be wrong. This needs to be something the file system does. Unless.... Couldn't this be accomplished by putting a process in the "food chain" before the disk (and RAM:, RAD:, etc.) devices that watch for file creation and deletion packets, and send the appropriate messages to any programs that are displaying info about that directory. Can this be done? This is something someone outside of DOGS could do (unlike changing the file system). If done right, C= might "bless" it, and use it to keep Workbench windows up-to-date. Or is something like this planned for the 1.4 Workbench upgrade? If so, I hope it will be done in such a way that file requesters etc. will be able to use it too. -Peter Schachte "Clean water? I'm for clean water." pds@quintus.uucp -George Bush ..!sun!quintus!pds
limonce@pilot.njin.net (Tom Limoncelli) (10/26/88)
Many file requesters multitask so that you can select from the files
read-in-so-far while the remaining files are being read in. Why not
do the same kind of thing but instead, start out with the old list of
files and multitask to update the list. This, in effect, would be
like cacheing the file names yet a little more functional.
-Tom
--
Tom Limoncelli -- Student Network Supervisor
Drew University, Box 1060, Madison NJ 07940 -- 201-408-5389
new->> tlimonce@drunivac.Bitnet -- limonce@pilot.njin.net
"The opinions expressed are mine... just mine."
"Network Theory? Just say node!"dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/26/88)
:In article <2287@cadovax.UUCP> keithd@cadovax.UUCP (Keith Doyle) writes: :>One problem I have been struggling with somewhat with file requesters is UUCP:{ames|pyramid}oliveb!tymix!antares!jms (Joe Smith) Writes: :Keeping a list of what's in a directory is great, as long as you can :guarentee that nothing has changed the directory behind your back. Think :... :This is a worth-while idea; caching a list of file names. To make it :workable though requires a change to AmigaDOS. If programs kept a lock :on the directory that the list came from, then all we need is a new :function to tell AmigaDOS to send us a message whenever the directory :changes. The messsage is a signal to the program to flush its file name :cache. Easy! Note these facts: Whenever a file in a directory is created or deleted the timestamp for the directory is updated. Not when a file is modified, but files are usually overwritten completely (1006) when updated so this isn't normally a problem. Now, whenever you access your cached file list, simply do an Examine() on the directory lock and see if the timestamp changed. The filesystem will have cached the information anyway and thus no disk accesses normally occur. Rescan the directory if the timestamp is different. This doesn't work for more than one level down ... if you create a/b/c, the timestamp for 'a' will not change, just 'b' (and the file 'c' of course). -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (10/26/88)
:> Just do an Examine, and compare the change data for the :>directory with the old change date: if they're different, something may :This would work fine, except WHEN do you check? You certainly check :pds@quintus.uucp Writes: :... :right away. Does your program check the change date for the directory :every few seconds just to see if something has changed? Wouldn't this :create a lot of useless disk accesses? Checking every couple of seconds while the requester is up would work out just fine! No disk accesses would occur under 'idle' operation (nobody else doing major accesses to the disk) because the directory block would be cached. >Couldn't this be accomplished by putting a process in the "food chain" >before the disk (and RAM:, RAD:, etc.) devices that watch for file :creation and deletion packets, and send the appropriate messages to any :programs that are displaying info about that directory. Can this be :done? This is something someone outside of DOGS could do (unlike :changing the file system). If done right, C= might "bless" it, and use :it to keep Workbench windows up-to-date. Not really... it would be an incredible hack and take too much overhead to be worth it for anybody but C-A to do it. Reason: Each and every DOS device you see out there is its own process. Sure you could re-vector the DOS library call for Open() etc... but then what? It can be done, but would mean implementation of a new packet type associated with locks. A "signal me if sub entries of this lock are touched" Call. If that *were* done, you might as well also implement file-level exclusive/shared locks (ala UNIX flock() call)... We're talking very major addition here. -Matt
ewhac@well.UUCP (Leo 'Bols Ewhac' Schwab) (10/26/88)
In article <5092@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: >In article <221@antares.UUCP> jms@antares.UUCP (joe smith) writes: >>Keeping a list of what's in a directory is great, as long as you can >>guarentee that nothing has changed the directory behind your back. [ ... ] > > Just do an Examine, and compare the change data for the >directory with the old change date: if they're different, something may >have changed. If not, not problem. > OOOOOooo!! I *LIKE* it! Thank you. I'll use that. _-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_ Leo L. Schwab -- The Guy in The Cape INET: well!ewhac@ucbvax.Berkeley.EDU \_ -_ Recumbent Bikes: UUCP: pacbell > !{well,unicom}!ewhac O----^o The Only Way To Fly. hplabs / (pronounced "AE-wack") "Work FOR? I don't work FOR anybody! I'm just having fun." -- The Doctor ubh tug guvf jnf yvar abvfr. Vg'f npghn yyl varjf sbqqre.
peter@sugar.uu.net (Peter da Silva) (10/26/88)
All these techniques of keeping file requestors up to date have one flaw... what happens when the user pops the disk with the directory the file requestor is looking at, next time the scan comes? I do know the solution in terms of preventing a system request to reinsert the disk... make sure you handle pr_WindowPtr when you implement this, folks! -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today? Disclaimer: I accept full responsibility for my own typos.