The Fred Fish Collection 1.5/ffcollection-1-5-1992-11.iso/ff_disks/200-299/ff224.lzh/CLImax/CLImax.readme

Text File | 1989-06-20 | 10KB | 188 lines

                                  CLIMAX

Have you ever wished your CLI window had 25 lines of 80 characters, just like
a good old fashioned non-windowing computer?  The answer is here: CLImax by
Paul Kienitz.  It creates a custom screen with a borderless backdrop CLI
window.  The CLI will be a Shell if you have the Shell-Seg resident.  I find
it very useful, but it has some idiosyncrasies that you should be aware of:

In order to use CLImax, YOU MUST BE USING CONMAN.  (As of now (3/89) the
newest ConMan is on Fish disk 165.)  Furthermore, the Run program, and
preferably the Execute program, must be available in your C: directory.
(Execute may be in your resident list instead, but the goddamn DOS Execute()
function, which I'm still using in this version (though I despise it) doesn't
have the sense to look for Run on the resident list.)

To end CLImax and erase the screen, just use EndCLI as usual.  Unfortunately,
IT DOES NOT WAIT FOR OTHER OUTPUT TO THE WINDOW TO STOP.  This is apparently
a ConMan shortcoming.  So don't EndCLI while other output is going to the
window from some Run'ed program, or you'll seek enlightenment from the Guru.
(Speaking of the Guru, I've noticed that GOMF 1.0 likes to nuke the CLImax
screen for no good reason.  I don't know about newer commercial versions of
GOMF.)

UNFORTUNATELY, you can't just say "climax" in CLI like you would say
"newcli".  This version is primarily intended for running from Workbench or
your startup sequence, and it needs to be RunBack'ed.  AmigaDOS 1.3 users can
use "run > nil: climax".  ARP users can ARun it.  (I suppose you could WBRun
it.)  In the future, I'll probably come up with a version that doesn't have
to wait for the CLI to end.  That would also use about 10K less memory.

Command-line/ToolType options:  So far there are three.  Each consists of
just a single letter.  From CLI, put the letter(s) after the word CLImax;
from Workbench, you can use the Info menu option to modify the ToolType
OPTION= which is followed by any or all of these three letters.  The letters
can be either case with anything in between.  The word OPTION must be
uppercase with no space before the equal sign.

If you say "OPTION= I" or "Run > nil: CLImax I" you get an interlaced screen
with fifty lines.  You might want to go "setfont topaz 11 window" in the
interlaced CLImax, to give you 36 lines with better readability.  Of course,
European users get 32 lines without interlace anyway, or 46 in interlace with
topaz 11.

The second option, "OPTION= G", causes the colors to change to black text on
a greenish background, a good combination for interlaced text.  Ordinarily it
uses the same colors as the Workbench screen.  Maybe someday I'll add RGB
options, but for now if you want different colors you'll have to either use a
Palette type program or recompile CLImax with new values.

The other option is "V" (for Vanilla; I want to save "C" to mean "color").
The V option makes it ignore the Shell-Startup script and use CLI-Startup.
By default, it attempts to start up by executing s:Shell-Startup whether
it's a Shell or not.  (If you don't use the Shell, this can be a special
script that makes your CLI non-vanilla some other way; it will affect
NewShell and the Workbench Shell icon too.  If you're a 1.2 user, Shell-
Startup will be for CLImax only.)  If it can't find Shell-Startup, or if you
use the V option, it tries s:CLI-Startup.  If it actually is a Shell, it
will still look like a vanilla CLI in most ways.  In this it is like the
Workbench CLI program, which it does indeed resemble closely in its internal
workings.  In fact, even NewCLI will actually produce a shell if the Shell-
Seg is resident.

CLImax will give a usage summary instead of running if a question mark or
letter H appears in the CLI command argument line.

In the upper right corner of the screen you'll see parts of the two screen
depth gadgets.  The screen is actually four lines overscanned vertically, and
so (though you can't see it) there is a piece of screen title bar above the
top of the window, which you can use to slide the screen vertically, or to
click the depth gadgets which are partially uncovered.  I know it sounds
unaesthetic, but it's not really so bad.

Many of the programs you run will create windows and stuff on the Workbench
screen, and will seem to be doing nothing if you just look at the CLImax
screen.  One program that is very useful with CLImax for switching screens is
wKeys by Davide Cervone, available on Fish disk 128.  Or you might prefer
Matt Dillon's DMouse.  Personally, I use a modified DMouse with wKeys-like
screen flipping features, and a couple of other improvements.  If anybody
wants a copy of this DMouse I can give you one, but I'm not mass-
distributing it because Matt Dillon doesn't like it.  Anyway, it's out of
date relative to Matt's latest version, which I haven't got yet.

It's possible that if you have CLImax and LoadWB both in your startup-
sequence that you might end up facing an inactive CLImax window which
ignores your typing because the workbench backdrop activated the moment the
initial CLI window vanished.  Try readjusting positions of these things in
startup-sequence; especially try putting CLImax at the very end.

One command you might want to put in your Shell-Startup if you use either the
Shell icon or CLImax from the Workbench is CD "" (that is, change directory
to the empty string in quotes).  What this does is correctly set the string
that tells what your current directory is, for the prompt (if you use %s in
the prompt string).  If you don't do this it will show SYS: instead of a real
name.  This will cost a bit of extra disk access.  CLImax when run from
Workbench CD's to wherever SYS: is currently assigned.

Future plans/hopes:  1) Eliminate need for Run(back) command from CLI.  This
shouldn't be too far away.  Eliminate dependency on ConMan, I hope, which
should also make it wait properly for other window output when ending.
Options for RGB colors, startup command, etc, and tooltype for startup CD.
Someday, no need for Run program, or Execute (present version) or NewShell
(near future version).  This would make it dependent on the Global Vector,
probably.  Maybe option to use Execute() if the GV changes on me.

CLImax is in the public domain.  Feedback is appreciated.  If you want to,
you can consider this to be $hareware, especially if you want to see an
improved version any time soon.  (My personal policy is (when I can) to treat
all software, from PD to copy-protected, as if it were shareware.)

                    Paul Kienitz
                    6430 San Pablo ave.
                    Oakland, CA, 94608
                    USA

                E-mail: none


REVISION HISTORY:

First version thrown together 11/27/88.  It has I option.  It works, but it
sucks.  Like, "please insert" requesters appear back on the workbench screen,
starting from workbench leaves it with no command path and a null current
directory, and you have to RunBack it.

Next day: made the new screen a WBENCHSCREEN.  This makes NewCLI and request-
ers etc. appear on the screen they were provoked from.  I have no idea if
this is kosher or not, so I'll just try it for a while and see if anything
breaks.

1/16/89: Made it a custom screen again; made error requesters appear on new
screen with pr_WindowPtr.  Much less trouble with programs that use
CloseWorkBench() to have only one wbenchscreen.  Now I want a way to NewCLI
onto this screen.  (Hey, ConMan 1.3 solves this; use CON:S*/n/n/...)  And
some programs still put up requesters specifically on the workbench screen.
Made it use different default colors for interlace (no choice).

2/13/89: Workaround for ConMan 1.3 change, which I thought at the time was a
bug, (no CloseWindow before CloseScreen) and support for Eurousers by
checking IntuitionBase->MaxDisplayHeight.  New code for using NewShell and
letting the CLI clean up the screen itself somehow is partly written but
#if'd out.
******* Woops, the workaround is not good with the old ConMan.

2/24/89:  I found out how the CLI (aka Shell) program manages to set current
dir etc. from workbench.  It appends a phony struct CommandLineInterface
onto its own struct Process!  Then it just goes
    Execute("execute s:CLI-startup", con, 0);       (or Shell-startup)
same as I've been doing.  It does not set pr_TaskNum.  I was amazed to find
how it sets the path; the Workbench has a struct CommandLineInterface too!
(The path is in cli_CommandDir.)  It tests whether the startup script exists
before trying to execute it (I hadn't), and if not, goes Execute("", con, 0).
New version incorporates the features mentioned above, which considerably
increases the complexity of the program.

Next day, handled CloseWindow in a way compatible with either kind of ConMan;
scan screen's window list first.  (Bill Hawes says you're supposed to let
ConMan close the window, and if anything the older ConMan was the one with
the bug.)  Gaaah!  Some days, it loses 56 bytes every time it's run from
Workbench!  Or does it?

3/12/89:  Added V option and usage summary.  Wrote doc file not long ago.

3/16/89:  Added G option.  Changing spew() from a macro to a function saved
650 bytes!  Preparing for imminent public release...

3/26/89:  Still not released.  Added OPTION=V/I/G tooltype.

~ 5/20/89 ?!  why did I take this long to get it out the door?

I've been trying to disassemble NewShell and EndCLI in order to see how to do
CLImax better...  This involved disassembling chunks of kickstart in order to
understand Global Vector calls...  I can tell you this much so far:  The BCPL
compiler produces TRULY BAD CODE.  The only reason BCPL programs come out
smaller than equivalent C programs is that they have all kinds of library
stuff available in the Kickstart that the rest of us never get to use.  HEY
YOUSE GUYS AT COMMODE-AMIGA -- put something in the Dos library so we can use
some of those useful GV entries like #121 (call a loaded program as a
subroutine in a CLI environment) and #78 (parse CLI argument line according
to a template string, I think) and #33 (the core of NewCLI) and whatever else
is useful in there that I haven't found yet!  And by the way, the whole idea
of the GV is way dumb...  an Exec library could do the same job better.  At
least half the lameness of the BCPL shit is not the language but the compiler
implementation.

(°¿°) <- Official Seal of Dorkiness certifies that CLImax was written
without the use of ROM Kernel Manuals.