nathan@orstcs.UUCP (05/05/86)
Ten Challenges:
The Macintosh has been out long enough now that there is a large
community of people sufficiently skilled, and equipped, to program it.
There is no lack of coding talent, but it's often applied in obsolete
ways. Each of us, after climbing the learning curve and wanting to
display our skill, writes a little utility. (Remember all the
screensavers, minifinders, and clocks?) While these have added to our
capabilities, we still don't have the "shower-of-sparks" effect that
occurs when our creations resonate together, as occurred under Unix,
and Smalltalk, and certain Lisps. If we are to uphold the revolution,
we must automate our automation.
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. Some may seem wildly
impractical (or just too hard); others too pedestrian. Choose wisely.
Myers Challenge #1:
A serious weakness found in every Mac editor I know of is the
search/replace function. Search patterns on obsolete systems have
always been restricted by the typographical problem: each additional
meta-symbol made it that much harder to use and to understand. On the
Mac we have a couple of new problems -- fonts & styles, and a distaste
for complexity -- but we have a huge advantage: we don't have to use
ASCII characters as meta-symbols! If you think of the "search window"
as being set up like a construction kit, you're on the right track.
But this is just the beginning: Why restrict ourselves to regular
expressions, when context-free expressions could be at our fingertips?
(Picture the day when every editor has a "railroad diagram" window)
The person who designs such an interface will have the adulation
of thousands.
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.
Without it, Unix would feel a lot like CP/M. On the Mac, each
program stands alone, except for a few DA's which have to be on the
boot disk.
What we need is support for a building-block approach that
allows dozens of little filters, on various volumes, to interact. In
place of Unix's pipe we have the Desk Scrap. I picture a DA, which I
call "Plumber", that (quickly) loads and runs miniprograms: they read
the Scrap, munch it, and write the result.
These miniprograms wouldn't have to handle events or
initialization, so they'd be much simpler than a Mac application.
Plumber would remain resident, so they'd be quick. The most common
library code would be in Plumber itself, so they'd be small. Plumber
would contain code to operate a dialog box that supplies option flags
& parameters to the miniprogram, if needed. It would also "redirect"
data to and from files. Allowing old pipelines (with their options
intact) to be left scattered about would subsitute for the "history"
mechanism found on obsolete systems.
The person who designs and publishes a "Bus Interface" to
miniprograms will be worshipped (and $upported?) by millions.
Myers Challenge #3:
Every RAMdisk I've seen on a Mac has been terribly primitive.
Why do they use up space not occupied by files, instead of claiming
the storage when it is needed? Further, when a program is run off
of a RAMdisk, why is it in memory twice? Free up the blocks it
occupied and use the core image from then on. Allow files to be
copied into RAM when they're first opened instead of at startup.
The person who builds a smart Ramdisk will own the business.
Myers Challenge #4:
Not to leave the bit-bangers among us unchallenged, I propose
that a two-button mouse is possible and desirable. The Mac has the
only one-button mouse on the market, and portability suffers. The x/y
data would have to come in serially to free up a wire for the second
button, but many mouses on the market are programmable, so that's not
so bad. The extra button would be be useful in existing programs,
emulating a Shift or Option key, but new programs could use it as
intended -- and it would be easier to make things run the same way on
Mac's, Atari's, and Amiga's. If you believe in portability, you may
have found your calling.
Myers Challenge #5:
The only Finder function I haven't seen duplicated in a desk
accessory is this: copying files. Why has this been neglected?
Having a fast multi-file copy function as a DA would mean never having
to use the Finder at all! The author of a successful Copy DA would be
admired by everybody but Steve Capps, and maybe him too.
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. What we need is a
replacement for the desktop code that tracks the mouse. It would pop
up the menu without prodding from the button. Probably most
applications wouldn't even notice the difference. (Them that do could
have a resource pasted on which disables the feature.)
This one sounds like a weekend's work in the right hands. I'm
sure everyone would send scads of money to the person who pulls this
one off.
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. (This is not to criticize the authors: it had to be
written before its problems could be understood.) But it's not
irreplaceable.
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. The interface for such modules could be very similar to
that for DA's, so existing compilers could be used to create
the edit modules. Supporting a new resource type would require
*no* changes to the core program. Bugs would be easily localized.
The core program would be small enough to be a DA.
If the interface for the edit modules were published, Apple
would be rid of a big maintenance headache, and "the rest of us"
programmers wouldn't have to be so paranoid about our resource
editor wiping out our new programs. Further, anyone could write
an editor for "his" resource type, and not have to wait for Apple
to get around to it. Even Andy Herzfeld will thank you for
tackling this one, and Gassee will invite you to lunch.
Myers Challenge #8:
Another thing that makes Unix powerful is that almost everything
is accessible through the file system. On the Mac, there are all kinds
of different incompatible channels for data: serial ports, floppy
drivers, the sound driver, Quickdraw, the SCSI port, Appletalk, the
keyboard -- none of which are accessible through a common interface.
We need an equivalent of "/dev" to integrate all these channels. In
place of driver or manager calls, I propose that we use Resources.
The file "Serial 1", for example, might have "Baud", "Flow", and
"Fram" resources to control the port. An Appletalk virtual circuit
could be established by writing to certain resources; then data could
be sent (perhaps by another program which knows nothing of Appletalk)
just as if to a file.
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.
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. Only a strong, flexible
standard can overcome IBM backing, but it is needed NOW! So: Design a
document-description interchange standard powerful enough to
represent all document-processing needs for both present and future
document systems. 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.
Myers Challenge #10:
Come up with a better set of challenges, and put your own name on
them. Offer prizes, record contracts, talk-show circuits, dates with
starlets, marketing agreements, Knighthood, fame, anything you can afford.
******
I encourage collaboration on these goals, and ask for help in
cross-posting them to other networks and BBS's. The more people who
know about them, the sooner we may hope for results. Also, I am
willing to co-ordinate collaboration on projects and offer any
assistance I can. I hope someone will volunteer to forward mail from
other nets to me. I will keep all posted on any progress I hear
about.
Nathan C. Myers uucp: {hplabs!hp-pcd|tektronix}!orstcs!nathan
780 NW 11th St. arpa: nathan@oregon-state
Corvallis, OR 97330 belltel: (503) 753-5110
Quote: "Laugh-a while you can-a, Monkey-boy!" -- John Whorfinlamy@utai.UUCP (Francois Lamy) (05/13/86)
In article <21100039@orstcs.UUCP> nathan@orstcs.UUCP writes: >Myers Challenge #1: > A serious weakness found in every Mac editor I know of is the >search/replace function. Before thinking of meta-characters and font searches, how'bout making Write and Word searching BACKWARD? -- Jean-Francois Lamy Department of Computer Science CSNet: lamy@toronto University of Toronto EAN: lamy@ai.toronto.cdn Toronto, Ontario UUCP:{ihnp4,decvax,decwrl,uw-beaver}!utcsri!lamy M5S 1A4 ARPA: lamy%toronto@csnet-relay
mkg@lzaz.UUCP (Marsh Gosnell) (05/13/86)
In addition to copying files, there are two HFS related functions that haven't been duplicated in desk accessories until recently. They are creating new HFS folders and launching documents. There's a new DA called HFS Locater Plus from PBI Software that does all of these and a lot more. Locater is a DA that searches your HFS volumes for files files by name (with wild cards) and/or by modification/creation date. If you run it with an application, Locater defaults to finding documents for that application (e.g., find me MacPaint docs if I'm in MacPaint.). The default can be changed to any file or a different application. Once you've found a file, you can do almost anything to it--copy it to another folder or to a different volume for quick backups, you can move it to another folder, rename it, delete it, show the Finder info, or launch it. When you launch a document, Locater finds the application and sets things up so that when you quit the current application, the new application will be launched and the selected document opened--exactly the same as double-clicking on the desktop. The launch is immediate if you use Locater from the Desktop. Locater also lets you: - make new folders at any time during a search, - save the full pathnames of matches in a text file (a mini-catalog), - restrict the search to a particular sub-tree or a particular folder, - and lots more. One other nice thing Locater does for you is set up the Standard file routines so that the next open will display the folder that contains the file that you found. This makes Locater nifty for finding a misplaced document and then opening it in the application. Marsh Gosnell
rb@ccird1.UUCP (Rex Ballard) (05/13/86)
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.
jmm@pavepaws.berkeley.edu (James M. Moore) (05/16/86)
In response to the multitasking issue, Bill Atkinson is supposed to be hard at work at this very moment (and many pastmoments) on something called Servent. Multitasking in windows on the same screen. Rumor had it serveral months ago that it was due to be released this summer, approximately in June. I have no idea if this is still the case. James
ephraim@wang.UUCP (pri=8 Ephraim Vishniac x76659 ms1459) (05/19/86)
> Ten Challenges: > ... > Myers Challenge #3: > Every RAMdisk I've seen on a Mac has been terribly primitive. > Why do they use up space not occupied by files, instead of claiming > the storage when it is needed? There are two general ways to allocate storage: permanently, from high memory; or temporarily, from one of the heaps. The first can't be done while most programs are running, since it involves moving the stack. The second isn't very useful for a RamDisk. The system heap is too small and the application heap is re-initialized at every program launch. > Further, when a program is run off of a RAMdisk, why is it in memory twice? > Free up the blocks it occupied and use the core image from then on. The copy of a file (resource, data segment, ...) in system memory is *modifiable*. Even code segments can contain modifiable local data areas. (No flames about coding styles, folks, it's just an ugly fact of life.) They also move around at the whim of the memory manager or application. > Allow files to be copied into RAM when they're first opened instead of > at startup. That's a disk cache (exists already) or a memory manager/segment loader (exists already). > The person who builds a smart Ramdisk will own the business. Let's see here... Apple built a disk cache, and they built the memory manager. And - they own the business! A RAMdisk is an attempt to improve memory management based on the idea that the user knows better than the system what should be where in the storage hierarchy. Mr. Myers isn't asking for a "smart ramdisk", he's asking for a better memory manager.
borton@sdcc3.UUCP (05/22/86)
In article <355@cad.UUCP> jmm@pavepaws.UUCP (James M. Moore) writes: >In response to the multitasking issue, Bill Atkinson is supposed to be hard >at work at this very moment (and many pastmoments) on something called Servent. >Multitasking in windows on the same screen. Rumor had it serveral months ago >that it was due to be released this summer, approximately in June. I have no >idea if this is still the case. > It is Andy Hertzfield, author of Switcher, who is working on Servant. `Multi-tasking' is a tough term to define, but a more correct description of Servant would be allowing applications to co-reside, as they do now in Switcher, with `context-switches' happening on mouse-clicks (in which window). The primary reason people want `multi-tasking' is to be able to do `menial' tasks such as printing and file transfer `in the background' while they don something else. Switcher currently has the hooks necessary to achieve this `background' work such as printing; I am disappointed that only ThunderScan is the only application I have seen take advantage of it. Andy said last January he hoped to start beta-testing in ~June, with release perhaps in Fall. For a more complete description of what he said at the San Diego Mac Users Group meeting in January see Best of BIX, Mac section, BYTE April issue (it might be May) --Chris -- Chris Borton, UC San Diego Undergraduate CS; Micro Consultant, UCSD borton@sdcsvax.UCSD.EDU || ...!{ucbvax,decvax,noscvax,ihnp4,bang}!sdcsvax!borton "Ist alles klar, Herr Kommissar?" "Ganz! Sie sind der Dieb!"
ngg@bridge2.UUCP (05/23/86)
> In response to the multitasking issue, Bill Atkinson is supposed to be hard > at work at this very moment (and many pastmoments) on something called Servent. > Multitasking in windows on the same screen. Rumor had it serveral months ago > that it was due to be released this summer, approximately in June. I have no > idea if this is still the case. > > James Servant is being created by Andy Hertzfeld. It will not be multi- tasking, but will be a switcher/finder replacement. It has the ability to load several programs at once, and you can move from application to application by locating the window of the application that you wish to use. or use the window locator on the menu bar. this is only a few of the MANY features that Servant has. It should appear towards the end of Summer and Andy said that it may only work work on Macs that have the 128k roms as Servant will be able to so more if Andy doesn't have to worry about trying to make it run on 64k roms. Norm Goodger at Bridge Comm.....!bridge2!ngg
baron@runx.OZ (Jason Haines) (05/23/86)
I thought Servant was (your Guru and mine) Andy Hertzfeld's pet project? D