231b3678@fergvax.unl.edu (Phil Dietz) (02/09/91)
Even more features besides the ones I thought of a couple of mesages
back:
1) MOST wanted feature: a buffered File requester! Whenever I open
the requester to upload some more, I have to wait 4 odd seconds
everytime to click on a file (and that's WITH a harddrive). I would
simply die if I had to upload from floppy (having it grind each and
every time I want to upload.)
Maybe have a GET DIR button like req.library or maybe a GENERAL
button to toggle if the user wants BUFFERED dirs of not.
That's it, but it's a GOOD one!
later
Phil Dietz
<<<=================--------- Cheap Ad ---------===================<<<
Phil Dietz SWL Lincoln 665 MEGS! 2 lines
231b3678@fergvax.unl.edu (402)421-1963 AMIGA, IBM, MAC, GIFS
"What a deal! I bought an ENIAC for 5 bux, but can it play Tetris?"lindblad@cc.helsinki.fi (02/11/91)
> The 1.1 release will remove the internal file requester in favor of using > req.library and any other external file requester. A font requester will > be added as well. > > Comments anyone? Yep. How about using KS2.0's requesters (and if the system doesn't use KS2.0, then using req.library). > -jack- Jarkko Lindblad lindblad@cc.helsinki.fi
maxc1553@ucselx.sdsu.edu (Generic Account 1553) (02/12/91)
Well. Using Addbuffers or FACCII could help this a bit. I would like to report a Jr.Comm bug... Settings - Option/Gereral : UPLOAD dir = DF0: Action - Transfer/Upload (No disk in DF0:) Response - System Requester: No disk in DF0: Action - Change the String-gadget in the Jr.Comm file requester. Hit RETURN Response - The File requester title bar changed to some garbage. Cursor re-appeared in the screen. Can't get rid of the file-requester window. Action - Severe Depression.... :-( snifff!! It's all over...
lordbah@bisco.kodak.COM (Lord Bah) (02/12/91)
> The 1.1 release will remove the internal file requester in favor of using > req.library and any other external file requester. A font requester will > be added as well. > > Unfortunately, this will eliminate the unique ability of the JR-Comm > file requester being able to multi-select files from across different > directories and volumes, but the gain in using a common requester across > different applications should outweigh this. > > Comments anyone? Will it still allow multiple selections within one directory? I use this sometimes when sending files via Zmodem to a UNIX box, and I wouldn't like to see it disappear just because of "standards". I've never selected files from more than one directory at a time, though. -------------------------------------------------------------------- Jeff Van Epps amusing!lordbah@bisco.kodak.com lordbah@cup.portal.com sun!portal!cup.portal.com!lordbah
jprad@faatcrl.UUCP (Jack Radigan) (02/12/91)
lindblad@cc.helsinki.fi writes: >> The 1.1 release will remove the internal file requester in favor of using >> req.library and any other external file requester. A font requester will >> be added as well. >> >> Comments anyone? >Yep. How about using KS2.0's requesters (and if the system doesn't use KS2.0, >then using req.library). Of course, this much was assumed. Sorry for not being so clear on that point. Thanks for the clarification. -jack-
231b3678@fergvax.unl.edu (Phil Dietz) (02/13/91)
In article <9102130227.AA20204@bisco.kodak.COM> amusing!lordbah@bisco.kodak.COM writes: >> The 1.1 release will remove the internal file requester in favor of using >> req.library and any other external file requester. A font requester will >> be added as well. >> >> Unfortunately, this will eliminate the unique ability of the JR-Comm >> file requester being able to multi-select files from across different >> directories and volumes, but the gain in using a common requester across >> different applications should outweigh this. >> >> Comments anyone? > >Will it still allow multiple selections within one directory? I use >this sometimes when sending files via Zmodem to a UNIX box, and I >wouldn't like to see it disappear just because of "standards". I've >never selected files from more than one directory at a time, though. > >-------------------------------------------------------------------- > Jeff Van Epps amusing!lordbah@bisco.kodak.com > lordbah@cup.portal.com > sun!portal!cup.portal.com!lordbah Jack said that the new requester will handle multiple files, but it will NOT allow the files to be on multiple drives/directories. Meaning-- you can't upload a file from df0: and a file from ram: during the same batch upload. Oh well. Phil Dietz ps. I kinda like the requester JRCOMM has. It has that neat and quick button that allows you to QUICKLY switch to an assigned drive, a drawer, or a mounted device easily. If Jack would incorporate a BUFFERED option, the requester would be perfect. True, the argument takes precedence about how JRCOMM EATS memory, but when XPR is added, and all the pud protocals taken out, the added buffer option should still make the executable smaller then before XPR and buffered stuff was added. --- FACT: the Nebraska Cornhuskers Phil Dietz signed a contract to lose the 231b3678@fergvax.unl.edu big games! Yes, it's true! Univ. of Nebraska
gt0655b@prism.gatech.EDU (gt0655b gt0655b gt0655b HAARBAUER,ERIC STOWE) (02/13/91)
I'd like JR-Comm to be able to dial a number without it having to be
entered in the directory, but still produce a dialer window. This would be
ideal for trying out new boards that I don't know that I want in the dir-
ectory.
Also, JR-Comm would benefit from supporting multiple dialin numbers
for the same board. This would save the trouble of tagging all the nodes
in the directory and and then having to untag the remaining nodes before
redialing the other tagged numbers--I have six dialins for one system, and
this is a pain!
-eh
--
HAARBAUER,ERIC STOWE "Consciousness is an accident."
Georgia Institute of Technology, Box 30655, Atlanta, GA 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0655b
Internet: gt0655b@prism.gatech.edujprad@faatcrl.UUCP (Jack Radigan) (02/14/91)
amusing!lordbah@bisco.kodak.COM (Lord Bah) writes: >Will it still allow multiple selections within one directory? I use >this sometimes when sending files via Zmodem to a UNIX box, and I >wouldn't like to see it disappear just because of "standards". I've >never selected files from more than one directory at a time, though. Multiple selections from the same (current) directory are supported, all you lose is multiple selection across devices/directories. -jack-
jprad@faatcrl.UUCP (Jack Radigan) (02/14/91)
231b3678@fergvax.unl.edu (Phil Dietz) writes: >ps. I kinda like the requester JRCOMM has. It has that neat and quick > button that allows you to QUICKLY switch to an assigned drive, > a drawer, or a mounted device easily. If Jack would incorporate > a BUFFERED option, the requester would be perfect. True, the argument > takes precedence about how JRCOMM EATS memory, but when XPR is added, > and all the pud protocals taken out, the added buffer option should > still make the executable smaller then before XPR and buffered stuff > was added. Well, there is only one protocal that's going to be moved out, CIS B+. It does take a good chunk of code with it, about 10-15k. But, the XMODEM series of protocols all use a good portion of the same code, each one does not use it's own code, only ZMODEM does. And that will *not* be relocated to an XPR module, I'd lose too much performance if I did. I do like my file requester (IMHO) and may make it a req.library type of thing, but that would depend on the demand it receives. -jack-