AAron@sun.soe.clarkson.edu (06/22/91)
hvaalde@cs.vu.nl (Aalderen van Harold): > > And how should we treat GEM programs that take parameters? > Only way to get the desktop to ask for parameters is to change the extension > to TTP > > Harold van Aalderen (hvaalde@cs.vu.nl) Either use a CLI after desktop, a cooler desktop (ie: Gemini!!!), or write a .PRG that asks for parameters then runs your program and passes the parameters you just entered (sounds like it might be short, quick, weekly for Double Click eh?)... AAron
hvaalde@cs.vu.nl (Aalderen van Harold) (06/23/91)
AAron@sun.soe.clarkson.edu writes: >> >> And how should we treat GEM programs that take parameters? >Either use a CLI after desktop, a cooler desktop (ie: Gemini!!!), or write >a .PRG that asks for parameters then runs your program and passes the >parameters you just entered (sounds like it might be short, quick, weekly >for Double Click eh?)... This does not solve the problem, if I buy a commercial program like 1st word, adimens (exec.prg and init.prg) that accepts parameters I would like to be able to give them even from the standard desktop So the desktop should provide the oppurtunity to do so. I understand that renaming it to .TTP is not the right way. But can't I fool around in the desktop.inf file to make the desktop ask for parameters for a GEM program and still startup that program as a GEM application? May be use the extension GTP or so? Actually I believe I once did this but I forgot how I did it and I like to know if I did it rigth. hvaalde@cs.vu.nl (Aalderen van Harold)
steve@thelake.mn.org (Steve Yelvington) (06/23/91)
[In article <10283@star.cs.vu.nl>,
hvaalde@cs.vu.nl (Aalderen van Harold) writes ... ]
> AAron@sun.soe.clarkson.edu writes:
>>>
>>> And how should we treat GEM programs that take parameters?
>
>>Either use a CLI after desktop, a cooler desktop (ie: Gemini!!!), or write
>>a .PRG that asks for parameters then runs your program and passes the
>>parameters you just entered (sounds like it might be short, quick, weekly
>>for Double Click eh?)...
>
> This does not solve the problem, if I buy a commercial program like
> 1st word, adimens (exec.prg and init.prg) that accepts parameters
> I would like to be able to give them even from the standard desktop
> So the desktop should provide the oppurtunity to do so.
If you install a GEM program keyed to a particular file or file type,
clicking on such a file will pass its name to the .PRG as an
argument. For example, if you install 1st_WORD.PRG and specify .DOC
files, if you double-click on MYFILE.DOC the result will be the same
as a command line of:
1ST_WORD MYFILE.DOC
If you want to pass a more complex argument -- with switches, for
instance -- you'll just have to get a better Desktop. I second
Aaron's recommendation of Gemini.
With Gemini, you can write a little shell script that shuffles
arguments around and passes them to a program. The shell script then
can be dragged out onto the desktop, renamed something more
informative (8+3 filenames are not needed for aliases of shell
scripts). Drag a file (or multiple files) to the script's icon and
let go. The script then launches the .PRG appropriately.
I don't know of any GEM applications that process command-line
switches, but I intend to put them into the next version of UUCODER.
----
Steve Yelvington
steve@thelake.mn.orgwarwick@cs.uq.oz.au (Warwick Allison) (06/24/91)
>>> And how should we treat GEM programs that take parameters? >>... or write >>a .PRG that asks for parameters then runs your program and passes the >>parameters you just entered. >This does not solve the problem, if I buy a commercial program like >1st word, adimens (exec.prg and init.prg) that accepts parameters >I would like to be able to give them even from the standard desktop >So the desktop should provide the oppurtunity to do so. >I understand that renaming it to .TTP is not the right way. >But can't I >fool around in the desktop.inf file to make the desktop ask for parameters >for a GEM program and still startup that program as a GEM application? >May be use the extension GTP or so? >Actually I believe I once did this but I forgot how I did it and I like to >know if I did it right. The first thing would be to attempt to get the Desktop to handle the problem (ie. GEM Take Parameters). If this is not possible, then simply write a program (called, say, "GTP.PRG"), that takes a program as a parameter, pops up a "parameters" box, then runs the program with those arguments. Then, simply use Install Application to make "GTP.PRG" the processor for all "*.GTP" programs. Warwick. -- _-_|\ warwick@cs.uq.oz.au / * <-- Computer Science Department, \_.-._/ University of Queensland, v Brisbane, AUSTRALIA.
harryk@bucsf.bu.edu (Harry Karayiannis) (06/24/91)
In article <2088@uqcspe.cs.uq.oz.au> warwick@cs.uq.oz.au writes: >The first thing would be to attempt to get the Desktop to handle the problem >(ie. GEM Take Parameters). > >If this is not possible, then simply write a program (called, say, "GTP.PRG"), >that takes a program as a parameter, pops up a "parameters" box, then runs >the program with those arguments. Then, simply use Install Application to >make "GTP.PRG" the processor for all "*.GTP" programs. > Or if you use a desktop alternative program, like Gemini (I triple the recomendation), and you want to pass more than one files to a GEM application (with its icon already on the desktop), just select the icons of the files (with Shift+Click) and drag them to the icon of the application (on the desktop). BTW, I think there is no need for changing the standard desktop just because it is "difficult" to pass parameters in GEM programs.The "Install Application" entry is more than enough, and it works very well. Now, if one wants to pass more than 1 parameters to programs frequently, he should use a command line anyway. In addition, I don't like the idea of the built-in(in GEM programs) parameter box either. It would work well if the parameters (talking about files only, no switches) lied in the same directory with the program; otherwise the user should type the full path of the files (and even if there are only 2 of them it would be tedious to type the whole path name for each). Now, if there is a GEM program that expects (unix like) switches it should be recoded using curses instead of GEM. If my message sounds abnoxious I apologise...I didn't mean it. PS. BTW, has anyone tried the demo of my phone-address catalog program called ATZENTA2 ? I'm interested in suggestions and comments (of any kind 8*) I'm just trying to figure out if it's worth it to keep improving it or just port it to another machine... > >Warwick. >-- > _-_|\ warwick@cs.uq.oz.au > / * <-- Computer Science Department, > \_.-._/ University of Queensland, > v Brisbane, AUSTRALIA. =============================================================================== Harry Karayiannis Post: || |# || 15 N.Beacon, #316 |#| ||#| |#| Boston University Allston, MA 02134 |#| ||#| |#| Computer Science Dpt. U.S.A. |##| ||#| |##| _______________________ ||#| ||#| ||#| |INTERnet: //// |||| \\\\ % fortune -o | harryk@bucsf.bu.edu ///// |||| \\\\\ "Hackers do it with |BITnet: ///// ATARI ST \\\\\ fewer instructions" | cscrzcc@buacca.bu.edu =======================================================|_______________________
ant@mks.com (Anthony Howe) (06/24/91)
While everyone toots Gemini's horn, don't forget that Neodesk 3 has the ability similar to the .GTP suggestion, I believ its .NTP. Anyway I found Neodesk 3 to be a wonderful desktop alternative. Gemini I could never get to work securely. Really neat ideas but I didn't have confidence in it. -ant -- ant@mks.com Anthony C Howe Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2J 6W9 "Fate favors fools, small children, and ships named Enterprise" - Riker
hvaalde@cs.vu.nl (Aalderen van Harold) (06/24/91)
ant@mks.com (Anthony Howe) writes: >While everyone toots Gemini's horn, don't forget that Neodesk 3 has the >ability similar to the .GTP suggestion, I believ its .NTP. Anyway I found >Neodesk 3 to be a wonderful desktop alternative. Gemini I could never get >to work securely. Really neat ideas but I didn't have confidence in it. .NTP stands for Neodeskt takes parameters an is used for programs that hook in to Neodesk for some routines. But your right there is a possibility to install something like .GTP Harold van Aalderen (hvaalde@cs.vu.nl)_
ignac@electro.com (Ignac Kolenko) (06/25/91)
In article <10283@star.cs.vu.nl> hvaalde@cs.vu.nl (Aalderen van Harold) writes: +AAron@sun.soe.clarkson.edu writes: +++ And how should we treat GEM programs that take parameters? + ++Either use a CLI after desktop, a cooler desktop (ie: Gemini!!!), or write ++a .PRG that asks for parameters then runs your program and passes the ++parameters you just entered (sounds like it might be short, quick, weekly ++for Double Click eh?)... + +This does not solve the problem, if I buy a commercial program like +1st word, adimens (exec.prg and init.prg) that accepts parameters +I would like to be able to give them even from the standard desktop +So the desktop should provide the oppurtunity to do so. +I understand that renaming it to .TTP is not the right way. But can't I +fool around in the desktop.inf file to make the desktop ask for parameters +for a GEM program and still startup that program as a GEM application? +May be use the extension GTP or so? + you can install a program like first word as an application accepting files with *.DOC extenders. Thus, whenever you double click on such a file, the commandline that is sent to 1st word by the desktop already has the filename in the commandline. this may not be the most elegant way of passing a commandline to a gem program, but it is accesable from the standard desktop. note as well that this method of passing a commandline only works for passing the name of only a single file, nothing more, nothing less. DC, where are you????!!!!! :=) :=) -- ========Ignac A. Kolenko (The Ig)=======watmath!watcgl!electro!ignac========= "Blowed up REAL good!" - Big Jim McBob (Celebrity Blowup - SCTV) =============================================================================
apratt@atari.UUCP (Allan Pratt) (06/25/91)
>AAron@sun.soe.clarkson.edu writes: > > And how should we treat GEM programs that take parameters? Get a Mega STe or a TT :-) The new Desktop in these machines allows GEM programs to take parameters. You can either drop a file onto a PRG icon (to start that program with that file name as its paramenter) or install the application as "GEM Takes Parameters" and double-click it, at which time you'll be solicited for parameters just like a TTP. ============================================ Opinions expressed above do not necessarily -- Allan Pratt, Atari Corp. reflect those of Atari Corp. or anyone else. ...ames!atari!apratt
gt1448b@prism.gatech.EDU (David P. Forrai) (06/25/91)
If one wants to create a new program type like GTP (GEM Takes
Parameters) it seems to me that all you'd have to do is rename
the appropriate programs with the GTP extent and then write a
little program to pop up a dialog requesting the command line and then
executing the program. It would be an "Installed Application". If
anyone is interested, I'll write such a beast as it wouldn't take that long.
--
David P. Forrai
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt1448b
Internet: gt1448b@prism.gatech.educmedley@wam.umd.edu (Charles Henry Medley) (06/25/91)
I don't know if everyone is familiar with it, but DC Desktop does the same thing everyone is asking about. You can use DC Install to make it prompt for parameters for any application, not just .TTP, and I use it regularly like this for DevPac ST, 1st Word and all of my archivers. DC Desktop is selling around here for as low as $22, so it might be worth it just to pay the ducats if the feature is that important... (I have to admit, I'm still using v1.0 of DCD, so there may even be some improvements to the system since I've been introduced to it)
harryk@bucsf.bu.edu (Harry Karayiannis) (06/25/91)
In article <1991Jun24.122551.24592@mks.com> ant@mks.com (Anthony Howe) writes: > >While everyone toots Gemini's horn, don't forget that Neodesk 3 has the >ability similar to the .GTP suggestion, I believ its .NTP. Anyway I found >Neodesk 3 to be a wonderful desktop alternative. Gemini I could never get >to work securely. Really neat ideas but I didn't have confidence in it. > I have to admit that NeoDesk 3 is really good...but ironically I have exactly the oposite feelings. I never had confindence in NeoDesk (here I have to say that I have never used NeoDesk extensively, since I don't own a copy of it. I've worked on it periodically being in a friend's house). But I think that everyone will agree that Neodesk became stable enough only after version 2.00. On the other hand, Gemini was very stable from the very first version (for me at least), and the current (2nd) version (1.21) is simly fantastic. NeoDesk 3 defenitly has more features than Gemini 1.21, but costs a lot more. IMHO the ratio performance/price of Gemini is way larger than Neodesk's. Don't get me wrong, I don't want to start a flame war. It's just my oppinion. I think both programs are in the top ten of ST's software, and both worth every penny of their price. I just happen to like Gemini better. PS. BTW, everyone should get a copy of XCONTROL.ACC (Atari's new control panel) I think this time Atari did a remarkable job. Defenitly the best control panel around!!!!!! >-ant >-- >ant@mks.com Anthony C Howe >Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2J 6W9 >"Fate favors fools, small children, and ships named Enterprise" - Riker =============================================================================== Harry Karayiannis Post: || |# || 15 N.Beacon, #316 |#| ||#| |#| Boston University Allston, MA 02134 |#| ||#| |#| Computer Science Dpt. U.S.A. |##| ||#| |##| _______________________ ||#| ||#| ||#| |INTERnet: //// |||| \\\\ % fortune -o | harryk@bucsf.bu.edu ///// |||| \\\\\ "Hackers do it with |BITnet: ///// ATARI ST \\\\\ fewer instructions" | cscrzcc@buacca.bu.edu =======================================================|_______________________
rosenkra@convex.com (William Rosencranz) (06/26/91)
i started this discussion by asking about using VDI calls in an otherwise
ordinary .ttp program. i have gotten lots of (good) feedback. but perhaps
i should specify exactly what i want to do...
these days i write exclusively .ttp programs, i.e. those which would normally
be executed from a CLI (currently i still use gulam). i want a few of these
programs (like the recently posted mgif - it did appear, did it not; i have
been away for a few days and things expire quickly here) to do a certain
amount of graphics, like lines, dots, and polygon fills. i have been using
line A for lines/points since it is so simple to do so. however, now i need
to do fills of irregular polygonal areas. this is possible with line A, but
the hassle of writing a front end to $A006 or whatever (one scan line at
a time fill) leads me to see if i can use the much simpler v_fillarea
(or whatever it is called). this is the ONLY vdi routine i want to call
at present.
it sounds like i can do basically
graf_handle (or whatever)
v_opvwrk (or whatever it is)
v_fillarea
which is still nice and simple. i realize that it may cause problems if GDOS
is installed. since i do not have it, that doesn't bother me :-). i also want
to minimize the amount of overhead, though i suspect linking in vdibind
will add more than a little overhead.
i still want the program to feel like a curses-like application (no mouse)
and want command line args. i also realize that i can hand blit directly
to Physbase or my screen memory whatever the heck i want, but i don't need
the expense (in time) of writing routines to flip bits (which, admittedly,
aren't THAT hard).
is there a better solution? what will break if i do the above (so far it
looks like GDOS)? what are the restrictions? i have no interest in making
this a GEM program at this time. as it is now, it should port fairly easily
to X (maybe not so easily), Sunview (just draw a rasterfile in memory), etc.
making it GEM will ruin this attribute (which, religiously, i consider far
more important than having a mouse just to point+click rather than key a
1-2 char command code which, for me, is faster anyway). in fact, to further
fuel the ensuing amiga/atari flame war or skirmish, one of the things i
most like about the ST is it is SO easy to port unix software. and there
are many good csh/sh/etc clones available. i don't care about number of
colors since the SM124 is about the nicest monitor i have ever seen (often
overlooked in flame wars). my eyes thank atari for this one!
this brings up another question: are "flicker" screens possible on things
like monochrome Suns? how fast can u change full-screen raster images from
memory to the frame buffer (/dev/fb, i presume, for mono)? the equivalent
of:
do {
Setscreen (scrn1, scrn1, -1); Vsync ();
Setscreen (scrn2, scrn2, -1); Vsync ();
Setscreen (scrn3, scrn3, -1); Vsync ();
} while (!char_pressed_or_equivalent_interrupt);
which runs at at least 10-20 Hz on the ST (guess). since i no longer have
a sun, this may be more academic than practical. when i had a sun 3/50
i 1) operated it like a big vt100 (no squinting to make out those 6x8 fonts
or whatever when u have chars 1/4" high and u'd be suprised just how
productive ^Z and ~^Z and fg can be :-), 2) prefered mono to color (save my
poor eyes!). in fact since the 3/50 under SunOS 4.0 was such a dog when
trying to run sunview with only 4 MB (and slow page/swap SCSI disk), i had
little choice anyway. only the brief excursion to the land of windows for
a few thousand games of backgammon (gammontool) :-).
-bill
rosenkra@convex.com
--
Bill Rosenkranz |UUCP: {uunet,texsun}!convex!c1yankee!rosenkra
Convex Computer Corp. |ARPA: rosenkra%c1yankee@convex.comRod.Fulk@f24.n228.z1.FidoNet.Org (Rod Fulk) (06/26/91)
So when is tos 2.x gonna be available for the older machines? ;-) * Origin: The R.I.P. (616)235-2313 [HST] (1:228/24)
ONM07@DMSWWU1A.BITNET (06/26/91)
In article <1991Jun24.122551.24592@mks.com>, ant@mks.com (Anthony Howe) says: > >While everyone toots Gemini's horn, don't forget that Neodesk 3 has the >ability similar to the .GTP suggestion, I believ its .NTP. Anyway I found >Neodesk 3 to be a wonderful desktop alternative. Gemini I could never get >to work securely. Really neat ideas but I didn't have confidence in it. > Might be that you had installations problems. Fact is, that Gemini did work on all graphics cards and on the TT since day one. You can't say that about Neodesk (does it still use Line-A? Does it still acces the disk with BIOS calls? Does it still use the border areas of windows????) >-ant >-- >ant@mks.com Anthony C Howe >Mortice Kern Systems Inc. 35 King St. N., Waterloo, Ontario, Canada, N2J 6W9 >"Fate favors fools, small children, and ships named Enterprise" - Riker ___________________________ cut here _____________________________________ Julian F. Reschke, Hensenstr. 142, D-4400 Muenster, Phone: ++49 251 861241 fast eMail: ONM07@DMSWWU1A.BITNET, slow: jr@ms.maus.de (++49 251 77216) ____________________ correct me if I'm wrong _____________________________
ue@nathan.ruhr.de (Udo Erdelhoff) (06/27/91)
In <2970@atari.UUCP>, Allan Pratt writes: >> And how should we treat GEM programs that take parameters? > >Get a Mega STe or a TT :-) The new Desktop in these machines allows GEM >programs to take parameters. What about Atari selling a TOS 2.X version for the old STs? Until then, I'll use Gemini instead, it's a lot cheaper /s/ -- Udo Erdelhoff ue@nathan.ruhr.de Fido: Udo Erdelhoff on 2:245/52.1
hvaalde@cs.vu.nl (Aalderen van Harold) (06/27/91)
rosenkra@convex.com (William Rosencranz) writes: >it sounds like i can do basically > graf_handle (or whatever) > v_opvwrk (or whatever it is) > v_fillarea I say put an appl_init() upfront and an appl_exit() before exiting >which is still nice and simple. i realize that it may cause problems if GDOS >is installed. since i do not have it, that doesn't bother me :-). i also want Shouldn't interfer with GDOS at all, GDOS is only needed if you use other ouput devices than the screen itself, or want to use different fonts >to minimize the amount of overhead, though i suspect linking in vdibind >will add more than a little overhead. Depends on your compiler since only thing you have to do is a trap for the functions you use the only overhead is filling some internal VDI arrays, it is not that much VDI is not difficult to handle once you learned what the functions do AES use windows is a lot more difficult, because you can't do it partial Harold van Aalderen (hvaalde@cs.vu.nl)