APDL Public Domain 1/APDL_PD1A.iso/textutil/jgpsuite/Docs/JGPDiscuss

Text File | 1993-04-20 | 11.1 KB | 244 lines

.// Source for Doc_JGPDispute  Tue,17 Mar 1992
.gute 5
.ht 2 10 12
.// This sets tabs for the indented layouts below.
.sp 0                   Comment out if Pages wanted; default 66 lines (.sp 66)
.ft
/

.col
|Page \p

/

.hd
:

.if \o
.col
|JGPDiscuss|Tue,21 Apr 1992
.else
.col
Tue,21 Apr 1991|JGPDiscuss
.fi

:
The JGP (Jolly Good Programs) suite does not fully accord with the desktop
conventions adumbrated in the programmer's reference manual. Apart from the fact
that parts were developed before I fully understood how to cause various
effects, and I still can't seem to work out how to handle text in a window, I
disagree with some principles set out there.

I believe in particular that, when a task, for instance an editor, supposes that
the user's channel of attention is totally claimed, it should be the case that
there should be nothing whatsoever elsewhere on the screen to make
that channel noisy, neither another window, nor framing paraphenalia for the
editing window. Like all good rules of practice, there may, rarely, be
circumstances where this does not hold.

However, this does not imply that other tasks should not be able to continue in
the background; indeed editors are usually waiting on user input, and, until a
key is pressed, there is plenty of CPU time not to be wasted. Similarly, if a
program is running a printer, the printer buffer will be full, and there is
plenty of CPU time to spare.

Again, the editing window should not pre\-empt urgent messages from other tasks,
such as Alarm, or indeed JGPCopy's own requests that are issued for single sheet
and/or verso printing. But, once the pre\-emptive request has been satisfied,
the editing window should be able to be verified and cover the now irrelevant
intruder. (Since it has no frame, the standard desktop click on the title\-bar
is not available.)

But, equally, one may wish to lay aside what one is doing to look around
for what is elsewhere on the desktop, before continuing one's main work. The
programs of the JGP suite can close their working window and diminish to simply
assert their continued presence by a small 'latent' window in the desktop.
Clicking menu in the latent window opens a menu which includes the choice of
'Continue' in the full editing window.

The two handlers, for the !jgp suite and the !jgpcopy subset do not, apart from
menu leaves, open windows, but JGEd, JGPrint, JGPCopy and JGConfig each do.
Their individual  charecteristics are discussed below.

The programs are written in BCPL, since I regard C's ontology as damagingly
limited and misconceived. Not that C lacks some merit or BCPL some weaknesses. I
do not discuss my choice further here other than to remark that, since I have
written the operating system interface, it lacks parts I am too lazy to include,
such as support for modules, and parts I do not yet understand such as interrupt
and event handling, but at least, what I use, I understand.

As at 4/92, I have not split the sprites I use into those to go into the
!sprites and the sprites files. I entirely agree with Acorn that this should be
done, but it always seems low priority. However, I put the sprites into windows,
via a template file, and do not see how to do this except from !Sprites.

I use text dialogue rather than menus to drive the programs. My view is that
where the decision tree is deep and narrow rather than wide and flat this is
preferable, and this applies throughout the JGP suite with one exception: in
JGConfig, there is a multi\-way switch to choose what kind of printer
configuration to do, and this would be better as a menu. I have left it as
dialogue, from laziness, unimportance, and to demonstrate where dialogue falls
down.

Of course, just as menus require careful ergonomic design, so does dialogue, and
I am fairly well satisfied with what I have provided. In particular the use of
the mouse buttons as aliases - in principle, select for first prompted choice,
adjust for second choice/denial - works well, as does the choice of prompts so
that the regular route through all programs is a succession of selects.

The JGPrint driver dialogue (cf. JGPrintInfo) with its unusual use of the Menu
click to modify the following Select or Adjust click, seems at first sight
absurd, but, actually, I find it works quite well.

It seems that the use of text windows confuses the Wimp and leaves garbage on
the desktop; if you encounter this an f12 <ret> repaints it cleanly.

I list here the facilities I have found lacking: a request to the Wimp to
repaint the desktop; the capability in FormEd or Paint to copy an icon in one
window to another, or to a sprite file; the ability to alter the size of a text
or sprite icon. No doubt I have missed something.

.col
|Text Windows

Even if I had worked out how to use vdu5 text, I would still use vdu4 for JGEd
and JGPCopy. In both cases it is important to be able to have different sized
text in the editing window; in JGEd, I need the fx 4 0 copy facilities (see
SHIFT-COPY), which is not available in vdu5.

.col
|Drivers

I use a driver program to instantiate instances of JGEd/Print/PCopy/Config,
rather than a single program which can provide multiple replications defined by
which set of data it is operating on. I think this saves store when nothing much
is going on,

.col
Icons and File Numbers

At the moment, !jgp.!boot contains:-
.nofj
set File$type_203 JGEd
set File$type_200 JGPrint
set File$type_205 JGPCopy
.usel base

I hope Acorn will assign me other file types. I believe that all that is needed
is to use !paint to rename the icons in !boot and !FormEd to rename the names of
the sprite icons in Templates and TemplatesH, and all no actual code will need
to be changed.

.col
|JGPSuite details

.col
|OwnWindow and latentWindow

When the JGPSuite programs are using the screen to interface with the user, they
run in their 'own' window which occupies the whole screen, covering the desktop.

They may retreat under user control to a small 'latent' window. Except for
JGPrint, which, unless JGPrinting to 'screen' etc, can happily run "in
desktop", nothing can happen in them until they return to their own window, via
a menu opened by clicking in the latent window, and selecting 'continue'.

While in their own window, the JG Programs return control to the Wimp manager,
so that any other concurrent task can use idle resources.

Any other task, eg the alarm, may open a window above a JGP own window; when it
goes, the JGP window may need to be reminded to recover the area it occupied.

Except in JGEd, clicking mouse-menu moves from own window to latent window.
Except in JGPrint, selecting Continue moves from latent window to own window.
In JGEd, in the editing window, holding shift key while clicking menu gets you
to the latent window; on the macroline, clicking adjust ar executing the macro
'dk' will also take you to the latent window. In JGPrint, Continue leads to a
sub-menu allowing continuation in either window as appropriate. Writing to the
Jot file always requires the own window. See the individual JGEd and JGPrint
documentation for more details.

When JGEd is in the latent window, the file being edited, or a marked block
thereof, can be saved in a filer window or in some other task, notably, of
course, another JGEd task, and a file can be loaded (inserted) from a filer
window, or from another task.

.col
|Backup in JGEd

The automatic backup facilities of JGEd are discussed in detail in JGEdDoc. If
you haven't yet managed to get round to reading this, you may be puzzled by a
report window  offering to backup your file, and proposing where this should be
done. YOUR EDITED TEXT HAS ALREADY BEEN SAVED. This window is offering to back
up a second copy for you on a chosen floppy, in a chosen directory. If you have
not setup such a directory, using Elsewhere previously, there will be a shaded
window saying b/u unset. To ignore this backup structure, click on Quit, to
backup where suggested, click on Backup. Clicking on Elsewhere will give you a
save window in which you can insert the leafname you want for backup, and then
drag the icon to a filer or application window. 'Elsewhere' may alter whither
future backup proposals are made. See JGEdDoc for details.

.col
|'Anonymous Tasks'

If an icon is dragged from an application to the JGEd Latent window, JGEd will
insert the text provided by the application in the text it is currently editing,
which could well have been empty, and continue without affecting the name of the
file that it understands itself to be editing.

However, if such an icon is dragged to the icon bar, the JGPSuite has a very
profound problem: whence is the file to be JGEdited, JGPrinted or JGPCopyed to
be deemed to come? Of course, the file will be that named <wimp$scrap> at the
time of the interchange, but the JGP tasks may require their source files to
remain available throughout the task's lifetime; but other tasks may need to use
<wimp$scrap> before then.

The JGPSuite tackles this problem by copying <wimp$scrap> to <wimp$scrapdir>.fn,
where fn is the leafname of the file that the other task supplied as part of the
interchange protocol (usually by the name used in the save window). The JGPSuite
task is then given this filename to work with, and told that it is its
responsiblity to delete this file when its task terminates.

In JGPrint, merge, index and user variable files should be included via the
desktop, rather than the short names in the ownwindow dialogue; however, if you
want to initialise user strings, you must do so via the prompt in the ownwindow
dialogue.

In JGEd, on exit, in place of the backup window, a window offers you the choice
of Preserve or Lose the file you have been using. The other tools just lose the
temporary scrap file the handler has given them to use.

In JGPCopy, the "+ delete" chice in the option menu is ticked on entry, and
cannot be cleared by menu selection.

The handler !JGPCopy, unlike !jgp cannot deal with anonymous tasks.

.col
|JGPCopy's Interaction with !Printers

In ...!jgp.!boot, Alias$@PrintType_205 is set to
....SCSI::SCSIDisc4.$.John.!jgp.!runimage 4 %0 and this causes JGPCopy to copy
any JGPCopy file directly through to the Printer on a !printer request, without,
as far as I can see, any diversion from the active printer driver. Moreover,
JGPCopy will respond "Device in use" to a "Device Claim" from the printer port
in use. My !Printers (versin 0.33 ) does not appear to send a PrintError 1
message, so that if there is no selected printer, it fails to print. In
!jgpcopy, these facilities are not available.

.col
|Printer configuration files

For a discussion of JGPrinter configuration files, see the beginning of
PrParmDoc.

.col
|A Bug that Maddens me, Sat,07 Nov, 1992 - April 1993

I have had some problems in clearing the text window associated with JGPrint's
Own window both on changing modes and if colours have been changed. There is a
visibly elaborate deleting and creating of new own-windows on re\-entering the
own window from JGEd's latent window that now (4/93) seems to get round it.