jnh@ece-csc.UUCP (Joseph Nathan Hall) (03/18/89)
OK, judging from the responses thus far, I am confident that this thing CAN fly ... I've heard from several people who are willing to contribute and a larger number who are willing (eager?) to "test" the material. I would like to solicit draft submissions. Here are the proposed terms: The UMPG will be PUBLIC DOMAIN. There will be no copyrights and any and all material may be reprinted or reused for any purpose whatsoever. Authors agree to relinquish all rights to the material submitted upon the final distribution of the UMPG to the net. (Until that time, they will retain all rights to their text and source code.) All authors will be credited as accurately as possible. We will do this project as a public service to Macintosh programmers, whether they be amateurs or professionals. If anyone disagrees with these proposed terms, or would care to comment on them, PLEASE E-MAIL your remarks to me. I will dutifully summarize and post them. For now, though, please include any appropriate copyright notice in your submissions. I will respect them and include them in any distribution of the material for review. Particular areas of interest are: * a basic event loop structure (Pascal and "C" source is a must!) * "C" vs. Pascal, particularly declarations of callback routines (scroll tracking, etc.) and code resources (?DEF functions and others) * how to do Mac file I/O, including startup files, file save/load, examples of how to set file creator, type, etc. * how to set up application and document icons * how to print something * how to methodically handle menu highlighting/dimming/item replacement when windows are activated/deactivated--a general- purpose approach is greatly needed here * source code for popup menus * source code for hierarchical menus (this one isn't too hard) * source code (including an INIT) for tearoff menus, if anyone has this * source code for a WDEF (does anyone have that circular window WDEF around still? is it public domain?) * source code for a modular text editor that is more powerful than TextEdit--including tab support, multiple styles, etc. Wouldn't have to be as complex as even old MacWrite but should be enough to support, say, an editor for program text. Maybe we could rewrite and/or extend the LightSpeed MiniEdit example. * event loop programming in general as it relates to both the Mac environment and other environments (X, for example) * any resource editing/building tools that are really effective * a set of meaningful programming standards--NOT just a set of rules for indenting and capitalizing programs. Ideally everything will be written/re-written to comply with this. * comparisons between the different "C" environments (mainly MPW and LSC) and the different Pascal environments (ditto). * notes for BASIC programmers (yes, there are a bunch of these!) * a set of useful MIDI drivers/low-level code and documentation ...and I'm sure there's more that would be useful. I would envision distributing the Guide (whenever it's in a more-or-less final draft form) in binhexed MS Word format. MacWrite is a possiblity, too, but it seems to me that Word has probably become an acceptable lowest common denominator. Again, email your comments to me. Perhaps a plain text version could be distributed as well. E-MAIL submissions and comments to me. I will summarize and post comments, and will note submissions. I will be preparing two mailing lists, one for submitters and one for reviewers. Please indicate which you would like to be on. Submitters will get everything sent to reviewers, so it will make no sense to be on both. I would anticipate a delay of about one-two weeks before I start mailing out stuff. This was posted to comp.sys.mac so that everyone could see it. Please send followups (if you can't e-mail instead) to comp.sys.mac.programmer, so we can spare the users and hardware guys. I look forward to working on and submitting to this project, and I appreciate the support I have gotten so far. -- v v sssss|| joseph hall || 201-1D Hampton Lee Court v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 v sss || the opinions expressed herein are not necessarily those of my -----------|| employer, north carolina state university . . . . . . . . . . .
mfi@beach.cis.ufl.edu (Mark Interrante) (03/18/89)
In article <3966@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: >Particular areas of interest are: > > * a basic event loop structure (Pascal and "C" source is a must!) [...] > * a set of useful MIDI drivers/low-level code and documentation > >...and I'm sure there's more that would be useful. I think we should begin talking about other interesting pieces of code that would belong in such a system. In addition to a simple text editor, I would like to see a simple drawing program. Nothing special just draw, drag, select,modify rectangles and a simple pallete. Also some information on writing serial drivers. The proper use of regions. These are just a few ideas. ----------------------------------------------------------------------------- Mark Interrante Software Engineering Research Center mfi@beach.cis.ufl.edu CIS Department, University of Florida 32611 ----------------------------------------------------------------------------- "X is just raster-op on wheels" - Bill Joy, January 1987
zuhn@umn-cs.CS.UMN.EDU (David D "Zoo" Zuhn) (03/18/89)
In article <3966@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: > >I would envision distributing the Guide (whenever it's in a more-or-less >final draft form) in binhexed MS Word format. MacWrite is a possiblity, >too, but it seems to me that Word has probably become an acceptable lowest >common denominator. Again, email your comments to me. Perhaps a plain >text version could be distributed as well. > >-- >v v sssss|| joseph hall || 201-1D Hampton Lee Court > v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 > v sss || the opinions expressed herein are not necessarily those of my >-----------|| employer, north carolina state university . . . . . . . . . . . The common denominator among all programmers is TEXT files. Many people do NOT like to use MS word for many reasons. Let plain ascii text files be the major medium here. That way it is accessible in any of the popular packages (just open up McSink or a edit window in MPW/LS[PC] etc). David D "Zoo" Zuhn // University of Minnesota \\ Twin Cities Computer Science Systems Consultant, EE/CS 4-204 zuhn@umn-cs.cs.umn.edu, zuhn@umn-cs.UUCP, ..rutgers!umn-cs!zuhn
-Cheshire-@cup.portal.com (Gary Edward Learned) (03/19/89)
As long as we are throwing things out here, what has been really lacking
are examples of data entry methods, including both modeless dialogs,
and scrolling windows, which have entry points scattered throughout (i.e.
the filling in of a form).
-- And remember the old adage...Everything you know is wrong
Gary-Cheshire-@cup.portal.com (Gary Edward Learned) (03/19/89)
If there is interest, I would be willing to develop alongside a Hypercard version of the guide. There would be several advantages to having this format as well, especially if it is done right. Anyone have thoughts?
arwall@athena.mit.edu (Chumley Wood) (03/19/89)
I would add to the list of useful topics: Example code for VBL tasks. ------------------------------------------------------------------------- | Anders Wallgren Back by popular demand: | | arwall@athena.mit.edu Bush-Noriega '88 - A Crack Team! |
arwall@athena.mit.edu (Chumley Wood) (03/19/89)
In article <11647@umn-cs.CS.UMN.EDU>, zuhn@umn-cs (David D "Zoo" Zuhn) writes: > >The common denominator among all programmers is TEXT files. Many people do >NOT like to use MS word for many reasons. Let plain ascii text files be >the major medium here. That way it is accessible in any of the popular >packages (just open up McSink or a edit window in MPW/LS[PC] etc). > I agree that the most used medium is text files, but in the interest of readability and presentation some more aesthetic format is desirable. For those not fortunate enough to have MS-Word or access to laser printers, it would be nice to maintain a plain version, as stipulated in earlier postings. It might be a good idea to have the code segments available for ftp on the major archives. anders ------------------------------------------------------------------------- | Anders Wallgren Back by popular demand: | | arwall@athena.mit.edu Bush-Noriega '88 - A Crack Team! |
trebor@biar.UUCP (Robert J Woodhead) (03/19/89)
In article <9937@bloom-beacon.MIT.EDU> arwall@athena.mit.edu (Chumley Wood) writes: >In article <11647@umn-cs.CS.UMN.EDU>, zuhn@umn-cs (David D "Zoo" Zuhn) writes: >>The common denominator among all programmers is TEXT files. The lowest common denominator, yes. >I agree that the most used medium is text files, but in the interest >of readability and presentation some more aesthetic format is >desirable. Also true. Why not Macwrite? I've yet to run across a Mac that didn't have a copy of Macwrite. But I'd estimate only 15-20% of Mac users have Word. _I_ certainly don't. -- * Robert J Woodhead * The true meaning of life is cunningly encrypted and * * uunet!biar!trebor * hidden somewhere in this signature... * * Biar Games, Inc. * ...no, go back and look again *
trebor@biar.UUCP (Robert J Woodhead) (03/20/89)
In article <3969@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: >1) Copyright. Several of you have suggested copyrighting the Guide in one >form or another, ostensibly to prevent commercial exploitation. I'll admit >I haven't given this issue exhaustive thought, but I would rather NOT see >it copyrighted. In particular, programming examples and/or modules >distributed with the Guide should be available for ANY use whatsoever. Copyright gives _you_ _control_ of what is done with the work. You just clearly specify "You can do this, this and this; you cannot do this; and if you want to do something we haven't listed, you must get written permission from us." Of course, see a lawyer to get the words right. -- * Robert J Woodhead * The true meaning of life is cunningly encrypted and * * uunet!biar!trebor * hidden somewhere in this signature... * * Biar Games, Inc. * ...no, go back and look again *
ted@hpwrce.HP.COM ( Ted Johnson) (03/20/89)
I vote for MacWrite as the common denominator. Other neat-o topics to cover: -how to talk to the serial port (e.g., a simple modem-dialing program) -an AppleTalk demo -Ted
ech@pegasus.ATT.COM (Edward C Horvath) (03/20/89)
In article <3969@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: >1) Copyright. Several of you have suggested copyrighting the Guide in one >form or another, ostensibly to prevent commercial exploitation. I'll admit >I haven't given this issue exhaustive thought, but I would rather NOT see >it copyrighted. In particular, programming examples and/or modules >distributed with the Guide should be available for ANY use whatsoever. From article <396@biar.UUCP>, by trebor@biar.UUCP (Robert J Woodhead): > Copyright gives _you_ _control_ of what is done with the work. You just > clearly specify "You can do this, this and this; you cannot do this; and > if you want to do something we haven't listed, you must get written > permission from us." Of course, see a lawyer to get the words right. And to be brutally specific, Copyright precludes ANYONE ELSE from slapping a copyright on the work. Without one, I can copyright the work and demand that YOU pay ME royalties for use. Again, ask a lawyer for specifics. =Ned Horvath=
jnh@ece-csc.UUCP (Joseph Nathan Hall) (03/21/89)
In article <2708@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: > >And to be brutally specific, Copyright precludes ANYONE ELSE from slapping >a copyright on the work. Without one, I can copyright the work and demand >that YOU pay ME royalties for use. Again, ask a lawyer for specifics. True, you can publish PD material and cover it with an anthology copyright, but so far as I understand it you can't keep someone else from doing exactly the same thing (in a different anthology). Right? -- v v sssss|| joseph hall || 201-1D Hampton Lee Court v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 v sss || the opinions expressed herein are not necessarily those of my -----------|| employer, north carolina state university . . . . . . . . . . .
bayes@hpfcdc.HP.COM (Scott Bayes) (03/21/89)
>I vote for MacWrite as the common denominator. > I agree. Everything ever made (it seems) imports MacWrite. I've received MS-Word files I've just had to trash, 'cause they're in a version I don't speak. I've never had that happen with MacWrite. Also, I think plain text as the only option sux wind through a straw. So many explanations require graphics for good understanding (that last sentence could probably have used a hearty dose ;-) Make text-only available as an alternative for the poor-of-spirit, or other underprivileged, but have MacWrite as the main format. >Other neat-o topics to cover: > >-how to talk to the serial port (e.g., a simple modem-dialing program) >-an AppleTalk demo > >-Ted Minimalist display updating. How do I do a fast update when I see an InvalRect? Scott Bayes
mcdonald@fornax.UUCP (Ken Mcdonald) (03/21/89)
[various referenes and other stuff deleted] > >>The common denominator among all programmers is TEXT files. > > The lowest common denominator, yes. > > >I agree that the most used medium is text files, but in the interest > >of readability and presentation some more aesthetic format is > >desirable. > > Also true. Why not Macwrite? I've yet to run across a Mac that didn't > have a copy of Macwrite. But I'd estimate only 15-20% of Mac users have > Word. _I_ certainly don't. > Forgive me if I'm not entirely up to date on wht the UMPG is to be, I missed the first messages about it...but I think I've got the gist. Given the resources available to the UseNet in general, why not write a little application (a DA, perhaps?) to display the manual in styled TextEdit--for sure the author of that wouldn't mind if his code was adapted to this use. One could also put in an organizational hierarchy, simply through the use of HFS folders, which would then allow a user to customize it to their preferences (so the info they use the most is easiest to get to) just by moving files. Later, an index generator could be added, or other things. Given the breadth of programming talent available on the UseNet (a category into which I, sadly, do not yet fall), it would seem reasonable to make use of some of this talent, it is willing. Ken McDonald
mcdonald@fornax.UUCP (Ken Mcdonald) (03/21/89)
In article <2708@pegasus.ATT.COM>, ech@pegasus.ATT.COM (Edward C Horvath) writes: > In article <3969@ece-csc.UUCP> jnh@ece-csc.UUCP (Joseph Nathan Hall) writes: > >1) Copyright. Several of you have suggested copyrighting the Guide in one > >form or another, ostensibly to prevent commercial exploitation. I'll admit > >I haven't given this issue exhaustive thought, but I would rather NOT see > >it copyrighted. In particular, programming examples and/or modules > >distributed with the Guide should be available for ANY use whatsoever. > > From article <396@biar.UUCP>, by trebor@biar.UUCP (Robert J Woodhead): > > Copyright gives _you_ _control_ of what is done with the work. You just > > clearly specify "You can do this, this and this; you cannot do this; and > > if you want to do something we haven't listed, you must get written > > permission from us." Of course, see a lawyer to get the words right. > > And to be brutally specific, Copyright precludes ANYONE ELSE from slapping > a copyright on the work. Without one, I can copyright the work and demand > that YOU pay ME royalties for use. Again, ask a lawyer for specifics. > > =Ned Horvath= Not quite true, I think. (Correct me if I'm wrong.) Work placed in the public domain can never after be copyrighted by ANYONE--including the original author. A work does not have to be EXPLICITLY placed in the public domain for this to apply; a company which does not take action to protect its copyrighted materials may later find that a court declares them to be in the public domain (one of the reasons companies MUST prosecute people who flagrantly violate copyright, even if they would prefer not to), and in the case of a work such as the UMPG, I strongly suspect that just releasing it, with no restrictions or declarations at all, would effectively place it in the public domain. Ken McDonald PS A big advantage of copyrighting something like this is it means no one can come up with a "renegade" version of the guide. A disadvantage is that people who might come up with a good variation now have to go through you, increasing the workload all way round. A possible solution might be to copyright it, state that the guide and any modified versions may be freely distributed, but that any version which is not an "approved" version must state so clearly and obviously.
mcdonald@fornax.UUCP (Ken Mcdonald) (03/21/89)
In article <929@fornax.UUCP>, mcdonald@fornax.UUCP (Ken Mcdonald) writes: > > application (a DA, perhaps?) to display the manual in styled TextEdit--for > sure the author of that wouldn't mind if his code was adapted to this use. One On one of my more recent postings, in addition to the usual typos and left-out words, a line seems to have gone astray. Between the two above lines was a line noting the existence of a nice LSP source file for topical help on sumex, and a statement to the effect that I thought the author of the could would not mind if his code were adapted for use in the UseNet Mac manual. My apologies for this transmission error. Ken McDonald
julian@riacs.edu (Julian E Gomez) (03/22/89)
In article <11550006@hpfcdc.HP.COM> bayes@hpfcdc.HP.COM (Scott Bayes) writes:
" >I vote for MacWrite as the common denominator.
" I agree. Everything ever made (it seems) imports MacWrite. I've received
" MS-Word files I've just had to trash, 'cause they're in a version I don't
" speak. I've never had that happen with MacWrite.
"
" Also, I think plain text as the only option sux wind through a straw. So
" many explanations require graphics for good understanding (that last sentence
" could probably have used a hearty dose ;-) Make text-only available as an
" alternative for the poor-of-spirit, or other underprivileged, but have
" MacWrite as the main format.
Instead of coming up with yet another file format, why not just use
TeachText? It's not well known, but TeachText files can have PICTs
in them. The mechanism is somewhat silly, but at least everybody
has [access to] TeachText, definitely more so than MacWrite. The
way Claris is taking MacWrite means that it won't be universal in
the near future.
--
"Have you ever wondered if taxation without representation was cheaper?"
Julian "a tribble took it" Gomez
julian@riacs.edupratt@boulder.Colorado.EDU (Jonathan Pratt) (03/22/89)
In article <931@fornax.UUCP> mcdonald@fornax.UUCP (Ken Mcdonald) writes: >words, a line seems to have gone astray. Between the two above lines was a >line noting the existence of a nice LSP source file for topical help on sumex, ^^^^ ^^^ ^^^^^^ ^^^^ It's ironic that this particular piece of code should be mentioned. In the recent survey on the proposed programming guide I opined that it's a good idea provided code like that could be avoided! I ended up spending more time tracking down the bugs in that than if I had written an equivalent from scratch. Among other things, the topical help code: doesn't dispose of the TEHandle when it's through, doesn't keep ModalDialog from pro- cessing mouseDowns after topical help has already used them, doesn't update properly, declares unused globals, etc. I have another list of philisophical disagreements, but these are opinion related things, such as checking for insufficient memory, supporting pre-Styled Text edit, and only using one global to reduce demands on the host. Don't get me wrong - I think more souce code should be posted, but I believe it should a little better tested than that apparently was. BTW, if the original author would give permission, I would be happy to post the version I rewrote. Another thing that annoyed me about topical help was the authors reference to "my other program," uWrite. This program would be useful for creating styled text, but no mention was made of how to obtain it (Free? PD? Shareware? Commercial? where?) Anyway, I ended up writing a DA that grabs styled text from the clipboard so I could use Draw II or Works II. If anyone else needs a TEXT/styl scrap to Resource file DA, let me know and I will upload. Jonathan /* Jonathan Pratt Internet: pratt@boulder.colorado.edu * * Campus Box 525 uucp: ..!{ncar|nbires}!boulder!pratt * * University of Colorado * * Boulder, CO 80309 Phone: (303) 492-4293 */
bradn@tekig4.LEN.TEK.COM (Bradford Needham) (03/22/89)
In article <2708@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes: >Without [a copyright], I can copyright the work and demand >that YOU pay ME royalties for use. A non-copyrighted published work cannot be copyrighted. But someone can do this to a public-domain work: They can create a derivative work, copyright that, and charge royalties for it. The original work is still public-domain -- they can't charge anyone royalties for possessing a copy of the original work. Interestingly enough, a similar thing happened to the GNU version of Yacc: There was once a public domain parser-generator, called Bison. The GNU folks modified it, then slapped their own copyright on the modified work. Bison (the original work) is still public domain, free of the Free Software Foundation restrictions. For more information, please read "The Copyright Book" published by MIT press. Brad Needham bradn@tekig4.TEK.COM
stone@hydra.unm.edu (Andrew Stone CS.DEPT) (03/22/89)
Remember the effort spearheaded a year or so ago to do a team project? I believe some folks from the Well or 'Lectronic Link were involved. How did this project fare? That is, maybe we should bake the cake before we argue over who gets what! andrew
CXT105@PSUVM.BITNET (Christopher Tate) (03/23/89)
Another issue that needs clarification: will submissions only be taken from people on the submissions list, or can Joe Programmer send in his ideas for some nifty way of handling things, too? (I may not be slick, but sometimes things work....) ------- Christopher Tate | I hate writing, and I hate statistics, cxt105@psuvm.psu.edu | but most of all I hate writing about ...!psuvax1!psuvm.bitnet!cxt105 | statistics. I'd rather go to the cxt105@psuvm.bitnet | dentist; at least there you get to spit.
bayes@hpfcdc.HP.COM (Scott Bayes) (03/23/89)
>Instead of coming up with yet another file format, why not just use >TeachText? It's not well known, but TeachText files can have PICTs >in them. The mechanism is somewhat silly, but at least everybody >has [access to] TeachText, definitely more so than MacWrite. The >way Claris is taking MacWrite means that it won't be universal in >the near future. BUT! The existing MacWrite format is immutable. And a bazoollion programs already read that existing format. As will no doubt MacWrite version 129.3, when it comes out. Don't you have to do something perverted to get PICTs into TeachText?!? > >-- >"Have you ever wondered if taxation without representation was cheaper?" > > Julian "a tribble took it" Gomez > julian@riacs.edu Scott Bayes "The tribble left it at my desk. Drop by some day."
jnh@ece-csc.UUCP (Joseph Nathan Hall) (03/23/89)
In article <77312CXT105@PSUVM> CXT105@PSUVM.BITNET (Christopher Tate) writes: >Another issue that needs clarification: will submissions only be taken from >people on the submissions list, or can Joe Programmer send in his ideas for >some nifty way of handling things, too? > I'll take submissions from anyone and everyone. But you'd be better off on the submitter's list, since that's where the latest list of 1) what's available, 2) what's being written, and 3) what needs to be written will be. Also that's where the latest submission guidelines/standards will be send. >(I may not be slick, but sometimes things work....) > I've found that there are MANY aspects of Mac programming that aren't inherently slick. Not even slick with some effort. -- v v sssss|| joseph hall || 201-1D Hampton Lee Court v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 v sss || the opinions expressed herein are not necessarily those of my -----------|| employer, north carolina state university . . . . . . . . . . .
jamesm@sco.COM (James M. Moore) (03/25/89)
In article <9937@bloom-beacon.MIT.EDU> arwall@athena.mit.edu (Chumley Wood) writes: >I agree that the most used medium is text files, but in the interest >of readability and presentation some more aesthetic format is >desirable. For those not fortunate enough to have MS-Word or access >to laser printers, it would be nice to maintain a plain version, as >stipulated in earlier postings. Please make sure all examples are available in TEXT. Downloading something at 2400 baud from xenix to my mac is frustrating - I'd rather just print it on the lasers here at work. I would suspect that many people are in the same situation (Mac not actually on the net, and downloads go over some slow modem connection). -- ** James Moore ** ** Internet: jamesm@sco.com ** ** uucp: {decvax!microsoft | uunet | ucbvax!ucscc | amd}!sco!jamesm ** ** Nil clu no suim ar bith ag SCO ceard a bhfuil me ag scriobh anois. **
julian@riacs.edu (Julian E Gomez) (03/27/89)
In article <11550007@hpfcdc.HP.COM> bayes@hpfcdc.HP.COM (Scott Bayes) writes:
" >Instead of coming up with yet another file format, why not just use
" >TeachText? It's not well known, but TeachText files can have PICTs
" >in them. The mechanism is somewhat silly, but at least everybody
" >has [access to] TeachText, definitely more so than MacWrite. The
" >way Claris is taking MacWrite means that it won't be universal in
" >the near future.
" BUT! The existing MacWrite format is immutable. And a bazoollion programs
" already read that existing format. As will no doubt MacWrite version 129.3,
" when it comes out.
I realize that any reasonable word processor will import MacWrite
files. The difference between all of them and TeachText is that
TeachText is free and comes with the system software as well as much
commercial software.
" Don't you have to do something perverted to get PICTs into TeachText?!?
Not perverted, just silly :-)
--
"Have you ever wondered if taxation without representation was cheaper?"
Julian "a tribble took it" Gomez
julian@riacs.edujnh@ece-csc.UUCP (Joseph Nathan Hall) (04/03/89)
(Whew ... wish I got this much mail at home!) I'm going to comment on a couple of issues that have cropped up frequently in replies to my earlier postings about the UMPG. I'm not posting summaries yet, but will do so as soon as I figure I've gotten the first "wave" of replies (three or four more days?). 1) Copyright. Several of you have suggested copyrighting the Guide in one form or another, ostensibly to prevent commercial exploitation. I'll admit I haven't given this issue exhaustive thought, but I would rather NOT see it copyrighted. In particular, programming examples and/or modules distributed with the Guide should be available for ANY use whatsoever. If someone wants to pop them into his/her commercial application, so be it. I also doubt that a publisher is likely to put a lot of effort into reprinting a PD work that is also available for free (or for copying costs), thus I'm not really worried that the Guide might be reprinted by an unscrupulous author/publisher. The example I DON'T want to follow is that of the FSF. Use of GNU products is severely restricted in industry and commercial-academic applications because of the FSF licensing agreement. Although I don't disagree with the ideals espoused by Richard Stallman and the FSF (...or at least, I admire them), the restriction to not-for-profit use has unpleasant side effects that any of us who are working on projects that are even potentially marketable find difficult to appreciate. I would rather follow the example of Paul Dobois and TransSkel, and just let the chips fall where they may. Please continue to mail me comments on this issue. If you have any specific suggestions about copyrighting, and in particular what you think the consequences of either copyrighting or not copyrighting might be, please illuminate me with them. 2) Distribution. I suggest MS Word and plain text. LaTeX would be nice, too, but don't look to me for the conversion. Again, I think MacWrite is too underpowered, and no other WP software is as commonly used as these two packages. 3) Editing/Organization. The topic-by-topic approach is by far your favorite. I can and will put together an amended list of topics, and will post it in a few days. I will happily take on the chores of organizing, proofreading and copyediting so far as my schedule permits. I was almost an English major once (before fiscal reality set in), and I enjoy writing (even attended the Clarion Science Fiction Writing Workshop at MSU in 1985), so I feel that I can do a good job of this. (My copyediting corrections will be limited to Strunk & White-type things, and I will NOT bicker over an author's style, even if I really don't like it.) In addition, everyone on the reviewer's list will be invited to contribute comments, corrections, and revisions. The list is shaping up nicely, and includes everyone from beginning Mac programmers to professional Mac applications programmers. As far as the delegation of tasks goes, well, let's keep this informal, in the ad hoc USENET spirit of things. (At least for now.) For now, just tell me who you are and what you want to do; if you have any code and/or articles already written, please send them now! I'll organize whatever I get in the way of submissions and mail it to reviewers in a few days if I have enough. We'll introduce greater structure later if it's required. 4) Industry/Organization Contacts. At the least, I'd like to find liasons at BCS, BMUG and Apple. (Add Think, Claris and Microsoft, too.) I need people who can assemble technical information and/or programming examples and clear it for reprinting (with or without copyright). That's all for now, folks. Next update in a day or two ... -- v v sssss|| joseph hall || 201-1D Hampton Lee Court v v s s || jnh@ece-csc.ncsu.edu (Internet) || Cary, NC 27511 v sss || the opinions expressed herein are not necessarily those of my -----------|| employer, north carolina state university . . . . . . . . . . .