scot@amigash.UUCP (Scot L. Harris) (05/01/89)
I have not seen the Introcad requesters but the best I have seen are in
Deluxe Photo Lab. Very easy to use and the response is very good.
--
_
/// /_\ Scot L. Harris !hoptoad!peora!rtmvax!amigash!scot
\XX/ / \ M I G A
[At warp factor 9, all the stop lights look green to me!]golden@cps3xx.UUCP (golden james) (05/03/89)
In article <0914.AA0914@amigash> scot@amigash.UUCP (Scot L. Harris) writes: >I have not seen the Introcad requesters but the best I have seen are in >Deluxe Photo Lab. Very easy to use and the response is very good. > I *must* disagree. If I'm looking for a file that's deep in a directory tree somewhere (on a hard disk for example,) it can take considerable time using PhotoLab's *novel* requestors. To look on a different drive I have to go to the bottom of a long list to the Volumes section. Or I can use the keyboard(!) and press 'V' (On a mouse based requestor? - come on!) If the dirctory is really full it can take considerable time to search thru since they only provided 5 lines for displaying files. At least it buffers the filenames (unlike PhotonPaintI) so that you don't have have to wait for a directory load each time you use it. I teach beginning Amiga classes at the dealer I work for, and honestly, the majority of students find DPaintII's requestors to be the easiest to use (not to say that it couldn't use a little upgrading) and Pixmate's to be the most confusing. PhotoLab's requestors are very painfull for me to use, since I'm quick with the mouse and don't want to scroll through large directories. (For PhotoLab, >10-files is large.) I wouldn't have jumped on you except that I specifically hate PhotoLab's requestors- I think they're a blister on an otherwise excptional program. Mike Golden Physiology Undergraduate
hrlaser@sactoh0.UUCP (Harv R. Laser) (05/04/89)
In article <0914.AA0914@amigash>, scot@amigash.UUCP (Scot L. Harris) writes: > I have not seen the Introcad requesters but the best I have seen are in > Deluxe Photo Lab. Very easy to use and the response is very good. > > > -- > _ > /// /_\ Scot L. Harris !hoptoad!peora!rtmvax!amigash!scot > \XX/ / \ M I G A > [At warp factor 9, all the stop lights look green to me!] The file requester used in IntroCAD is called "PathMaster" and is the creation of Mr. Justin V. McCormick, currently V.P. of R&D, Progressive Peripherals & Software, Denver. PathMaster is also used in PP&S' PIXmate and FrameGrabber software, both of which Justin also wrote. (Tim Mooney wrote IntroCAD). But it's not necessary to own any of these commercial titles to see/play with PathMaster since Justin wrote and released to the public domain a little ditty he called "FileInjector" which uses the PathMaster requester to search for filenames and then some tricky mouse manipulation to "inject" the selected filename into the a "lame" (or less capable) requester in some other program you're running simultaneously. FileInjector is at least a year old now - if interested, check around, it should be available for downloading everywhere. PathMaster is my absolute favorite file requester. I could name a dozen (or 5 dozen) programs I use frequently whose file requesters I'd like to rip out by their roots and replace with PathMaster.... I found the requester in PhotoLab fairly awful. -- +-----------------------------------------------------------+ | Harv Laser | SAC-UNIX, Sacramento, Ca. | | Plink: CBM*HARV | UUCP=...pacbell!sactoh0 | +-----------------------------------------------------------+
perry@madnix.UUCP (Perry Kivolowitz) (05/04/89)
In article <0914.AA0914@amigash> scot@amigash.UUCP (Scot L. Harris) writes: >I have not seen the Introcad requesters but the best I have seen are in >Deluxe Photo Lab. Very easy to use and the response is very good. The next release of CygnusEd Professional will contain an entirely new file requester written as a shared reentrant library. It supports such features as real time scrollable file AND device lists, wild cards, invisible files, and more. Best of all, a short time after the next release ships (sometime this summer) we will be entering the file requester library into the freely redistributable collections such as FNF. Give us some time to get the new release out, then look for the best file requester yet on a bbs near you. (Damn well better not find CedPro sitting next to it!!). -- Perry Kivolowitz, ASDG Inc. ARPA: madnix!perry@cs.wisc.edu {uunet|ncoast}!marque! UUCP: {harvard|rutgers|ucbvax}!uwvax!astroatc!nicmad!madnix!perry CIS: 76004,1765 (what was that about ``giggling teenagers''?)
shf@well.UUCP (Stuart H. Ferguson) (05/09/89)
+-- hrlaser@sactoh0.UUCP (Harv R. Laser) writes: [ something I consider very telling ... ] | PathMaster is my absolute favorite file requester. I could name | a dozen (or 5 dozen) programs I use frequently whose file | requesters I'd like to rip out by their roots and replace with | PathMaster.... Yeah, and why not? File requesters seem to be a religious issue almost like editors (maybe not that bad :-). They are also very difficult to write well, which leaves developers with few alternatives. The end result is that almost everyone has almost no programs with file requesters they like. There are some PD file requesters -- but what if you don't like them? ARP provides a file requester in its shared library, which is nice for developers who don't want to write there own, and can be replaced. But replacing it requires SetFunction()ing the library, and hoping for no unexpected interactions. How about a "filerequester.library?" It could be spec'ed as having a known interface that anyone could write towards -- from both sides. Developers would have access to a generic file requester from within their programs, users would see a consistent interface, AND users could choose the requester they want from as many possible filerequester.library's as could be written. You could use the Dillon fr.library, or the Schwab fr.library, or the RJ ... There's been some talk on .tech about a requester interface already.... P.S. Personally, I'd still like to see a file requester that opened up like a Workbench drawer with the full functionality. Double-click other drawers to browse the directory and double-click your data file to select it. Or, shift-click to select multiple files. Why, when there's a graphic system interface, are there no graphical file requesters? P.Wishful.Thinking.S. Why, oh, why is there no workbench.library? Put some hooks in that black box, boys. I've got libraries one the brain tonight I gues .... -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
golden@cps3xx.UUCP (golden james) (05/10/89)
In article <11583@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >to write well, which leaves developers with few alternatives. The end >result is that almost everyone has almost no programs with file requesters >they like. > >There are some PD file requesters -- but what if you don't like them? ... >How about a "filerequester.library?" It could be spec'ed as having a >known interface that anyone could write towards -- from both sides. >Developers would have access to a generic file requester from within >their programs, users would see a consistent interface, AND users could >choose the requester they want from as many possible ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >filerequester.library's as could be written. You could use the Dillon >fr.library, or the Schwab fr.library, or the RJ ... Or even a FileReq.device - who knows? Just drop your favorite in the right drawer, and you'll have an instant common user interface to all your favorite (participating) programs. Great Idea!! Mike Golden Physiology Undergraduate Michigan State University
cmcmanis%pepper@Sun.COM (Chuck McManis) (05/11/89)
In article <11583@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >How about a "filerequester.library?" It could be spec'ed as having a In article <2915@cps3xx.UUCP> golden@cps3xx.UUCP (golden james) writes: >Or even a FileReq.device - who knows? Just drop your favorite in the >right drawer, and you'll have an instant common user interface to all >your favorite (participating) programs. Great Idea!! How about ARP? You may not like the file requester in the ARP library but it is a) a shared library, b) a defined file requester interface. So every thing you need is in place. Just SetFunction() the requester code with your own requester if you want to change it. When I installed ARP 1.3 it didn't sink in, but when I brought up VlT and went to upload a file, the new requester was there and it was really neat. --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. "A most excellent barbarian ... Genghis Kahn!"
shf@well.UUCP (Stuart H. Ferguson) (05/12/89)
+-- cmcmanis@sun.UUCP (Chuck McManis) writes: | In article <11583@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: | >How about a "filerequester.library?" It could be spec'ed as having a | In article <2915@cps3xx.UUCP> golden@cps3xx.UUCP (golden james) writes: | >Or even a FileReq.device - who knows? Just drop your favorite in the | | How about ARP? You may not like the file requester in the ARP library | but it is a) a shared library, b) a defined file requester interface. | So every thing you need is in place. Just SetFunction() the requester | code with your own requester if you want to change it. Objection! SetFunction(), I my opinion, is a hack. And a pretty poor one at that. It locks the library in memory, even when it's not in use, and it requires the USER to correctly nest the setfunctioning and un-setfuntioning of nis tools. The first is a bad limitation, but the second is unacceptable from a user's point of view. If they get the nesting wrong - Boom! | When I installed | ARP 1.3 it didn't sink in, but when I brought up VlT and went to | upload a file, the new requester was there and it was really neat. | --Chuck McManis Yeah, there are great advantages to this shared code thing -- we're just so used to the "monolithic" program approach that it's hard to see. -- Stuart Ferguson (shf@well.UUCP) Action by HAVOC
cmcmanis%pepper@Sun.COM (Chuck McManis) (05/13/89)
In article <11635@well.UUCP> shf@well.UUCP (Stuart H. Ferguson) writes: >Objection! SetFunction(), I my opinion, is a hack. And a pretty poor >one at that. So, are you agree that something like ARP library is the way to go? I agree that SetFunction() is a hack, and like Bart's system Wedges much better. As for leaving the Library open, that is true, but as long as the routine is setfunctioned, one must assume that the application needing it is still around. Maybe we could use wedges, and put a "wedge identifier" in the handle (xxxBase) so that on a CloseLibrary() call any wedges that this application had in force would be removed. --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. "A most excellent barbarian ... Genghis Kahn!"
scot@amigash.UUCP (Scot L. Harris) (05/16/89)
>Path: rtmvax!peora!ge-dab!crdgw1!uunet!seismo!sundc!pitstop!male!sun-barr!ames!indri!dogie.macc.wisc.edu!csd4.milw.wisc.edu!uxc!tank!eecae!cps3xx!golden >From: golden@cps3xx.UUCP (golden james) >Summary: I hate PhotoLab's Requestor >Date: 3 May 89 08:44:49 GMT >Reply-To: golden@cps3xx.UUCP (golden james) >Distribution: na >Organization: Engineering, Michigan State Univ., E. Lansing >Lines: 34 > > >I *must* disagree. If I'm looking for a file that's deep in a directory >tree somewhere (on a hard disk for example,) it can take considerable >time using PhotoLab's *novel* requestors. To look on a different drive I >have to go to the bottom of a long list to the Volumes section. Or I can >use the keyboard(!) and press 'V' (On a mouse based requestor? - come >on!) Everybody is entitled to an opinion. Actually one of the features of the DPL requesters that I liked was the way they listed the volumes available. That scheme appears to me to be more flexable than others which have a limited number of gadgets. Besides I have two hands and can peck out a V or D very easily without taking my right hand off the mouse. Besides DPL is very nice and sorts the files so that if you are looking for a paticular file you can scroll to it very quickly. >I teach beginning Amiga classes at the dealer I work for, and honestly, >the majority of students find DPaintII's requestors to be the >easiest to use (not to say that it couldn't use a little upgrading) and >Pixmate's to be the most confusing. PhotoLab's requestors are very >painfull for me to use, since I'm quick with the mouse and don't want >to scroll through large directories. (For PhotoLab, >10-files is large.) You will still have to scroll thru large directories using DPII. > >I wouldn't have jumped on you except that I specifically hate PhotoLab's >requestors- I think they're a blister on an otherwise excptional >program. > That's what makes life interesting! > Mike Golden > > Physiology Undergraduate -- _ /// /_\ Scot L. Harris !hoptoad!peora!rtmvax!amigash!scot \XX/ / \ M I G A [If you can keep your head when all about you are losing theirs, perhaps you have misunderstood the situation.]
MROBINSON@wash-vax.bbn.com (06/05/89)
[Martin J Brown-Jr notes that the scroll arrows are too far apart] I agree that scrollbars have poor design in general. I have been fairly impressed with the OpenLook standard for windowing appearance, and was wondering if Commodore has looked at the option of supporting OpenLook in 1.4 or after. In particular, the scrollbars and the resize gadgets are some of the nicest I have ever seen. Also, I have had some difficulty finding some of the user interface tools I would expect in a windowing system on the Amiga. For example, is there a routine that you can give some text and receive a standard-shaped button? If there isn't, I request that Commodore add such a routine! This kind of routine is essential to developing a standard (but optional) user interface, I would think. --Max Robinson mrobinson@wash-vax.bbn.com