🚀 go-pugleaf

In article <21100039@orstcs.UUCP> nathan@orstcs.UUCP writes:
>Ten Challenges:
>
>     What is short now is not coding, but design.  "What can we do to
>multiply the effects of all our efforts?"  In this spirit I offer ten
>Challenges to the Macintosh software community.
>
>Myers Challenge #1:
>     A serious weakness found in every Mac editor I know of is the
>search/replace function.
>
>Myers Challenge #2:
>     On Unix, we get tremendous mileage out of the "pipeline" concept.
>Every little program is part of a (more-or-less) integrated system.
>     What we need is support for a building-block approach that
>allows dozens of little filters, on various volumes, to interact.
>
>Myers Challenge #3:
>     Every RAMdisk I've seen on a Mac has been terribly primitive.
>     The person who builds a smart Ramdisk will own the business.

RAMdisks, memory resident programs, and other "tricks" seem like
a poor substitute for real multitasking.  It might be nice to have
a little Cache for the disks, but rather than try to "band-aid" around
the "one task" limitations, multitasking should be considered #1 on
Apple's priority list.  Demand paging, virtual memory, and Cached
read-ahead would be nice, but the current Macs don't have the
hardware to support these.  It is possible to get some degree of
multitasking even with the limitations of the Mac.  It might not
be "full blown UNIX with Graphics", but at least you wouldn't be
waiting 20 minutes for "MacDraw" to "print" to your Imagewriter.

>Myers Challenge #4:
>     Not to leave the bit-bangers among us unchallenged, I propose
>that a two-button mouse is possible and desirable.

I would suggest that the second button have the "double click"
functionality, since this seems to be the most frustrating part
of the mouse.  Every tried to click-drag a selected application
only to find yourself going into McDraw instead?  This can be
real bad when people "take turns" at the Mac and set preferences
to very slow.

>Myers Challenge #5:
>     The only Finder function I haven't seen duplicated in a desk
>accessory is this: copying files.

I would like to see both a true "copy" and a true "move" to move
and copy files in and out of folders and across drives.

>Myers Challenge #6:
>     Anyone who's used an Atari knows that GEM's menu-bar approach, in
>which you don't have to hold the mouse button down while you make a
>menu selection, is less fatiguing than Apple's.

Actually, this is a mixed blessing, unfortunately if you accidentally
"bump" the menu bar, you need to to some heavy maneuvering to get
that menu to go away.  If you really want it, great, try it first.

>Myers Challenge #7:
>     Apple's resource editor is huge, cumbersome, non-expandable,
>and unreliable.  The only thing to say in its favor is that it's
>indispensable.
>     I propose a core program which itself is little more than a
>resource mover.  It would load an edit module for each resource
>type, as needed, from a separate file identified by the resource
>name.

I'm not sure if this would be better than having separate editors,
rather than one core program with different edit modules.
Unfortunately, Mac has a lot of "Magic cookies" that are difficult
to comprehend, let alone edit.

>Myers Challenge #8:
>     Another thing that makes Unix powerful is that almost everything
>is accessible through the file system.
>     With this scheme we could eliminate the proliferation of trap
>calls, and make our programs more flexible too.  This is one place
>where I expect we'll need cooperation from Apple.

You're sounding more and more like an OS-9 for Mac supporter :-).
You are right, "transparent drivers" would be a useful way of
improving the "modularity" of Mac software.  I don't know how
much co-operation we can expect from Apple, but it should be
possible to get OS-9 with VDI before the end of 1986.

>Myers Challenge #9:
>The corporate market is starting to demand compatibility among word
>processors.  Unfortunately, what they're specifying is IBM's
>DisplayWriter format: an abomination.
>It need not be terribly compact; but it must be
>capable of representing all constructs found in Microsoft Word, Troff,
>TeX, Word Perfect, and Interleaf files.  To do this, it must of course
>be an extensible, hierarchical language.  Get an ANSI or NBS
>committee to rubber-stamp it, and make a fortune.

Actually, there are several usefull alternative standards including
the PostScript used by the AppleTalk/Laserwriter.  The main obsticle
here is that the Mac can go from "Pict&Text" to "PostScript" but not
the other direction.  Actually, if Mac could accept any of the
available "document description formats" as INPUT, the issue would
be settled quite easily.  Anybody got a PostScript to ScrapBook
interpreter?  Also, definitions of "objects" should be sufficiently
complete to allow transfer in/out of ANY editor, including say,
McProject, McDraw, and McDraft.

>Myers Challenge #10:
>Come up with a better set of challenges, and put your own name on
>them.

Ballard Challeng #1:
Data Transfer Capability.  Come up with the necessesary interpreter
so that one can create a file on ANY computer (UNIX, PC, or other),
bring it into Mac, edit on ANY editor, transfer back to UNIX,
run through filters, then print on ANY graphics capable printer.
I should also be able to edit on any OTHER graphics capable computer.
Just as you are capable to manipulate UNIX "text" files with several
different "tools", you should be able to manipulate Mac "picture"
files in the same way.  Ideally, it should also be possible to
use a "text only" editor to intelligently manipulate the files as well.

Macro, Search, and "Define" capabilities.
It should be possible to write "Macros" which can extend the
capabilities of existing tools, much the same way as Aliases,
Shell scripts, and user defined functions extend the capabilities
of otherwise "trivial" UNIX commands.  Ideally, such a process
should be as interactive and intuitive as the current desktop
and Mac editors.

It should also be possible to Search for object such as "a rectangle
containing the text 'rex ballard'" if such a box exists.

Considering the Object Oriented organization of the Mac, it should
be possible to view N dimentional matrices of commands or available
functions.  For example, you might touch an Item on the menu bar
which gives two columns.  Click one from each column, and it will
resolve into a single command.

Have a way of determining which fonts, accessories,... must be
loaded to view a document.  I have a couple of documents I can't
read because MacWrite can't find all the right fonts.  I should
be able to put the Mac in a "status mode" where selecting an
item will tell me which application should be run, what fonts
and resources are needed, and what can be done with it.

There should be a "more" or "preview" format in which the document
can be examined, but not modified.  It shouldn't be necessary
to load an entire application just to "peek" at a one or two page
"picture", especially considering the 2 minute waiting period
for going in and out of some of those applications.