jnh@ece-csc.UUCP (Joseph Nathan Hall) (03/21/89)
Hi, again. Following is an edited set of comments received pertinent to the USENET Mac Programming Guide project. I have deleted comments like "this is a really swell idea!" since we ALL seem to think it is. The response has been overwhelmingly positive. Not that I would expect any, but I've received no negative comments on the project as a whole (to date). I've also deleted comments that didn't really pertain to the structure of the project (i.e., "I've got x module in C that does y, would you like to have it?"). Most of these are replies received via e-mail; I've also included some postings in summarized form since they are also relevant. I have a bad tendency not to save mail headers (I'm trying to get over this, but it may well be a basic genetic deficiency of mine), and I tend to lose addresses if e-mail sent to me doesn't have a name and address in the text or in a .sig. Also, I may have mis-attributed some comments; no harm intended if I did. I've added some comments of my own in angle brackets. By the way: total "membership" (people on the submitter mailing list + people on the reviewer mailing list) so far is 20-25, about equally divided between submitters and reviewers. This is already a workable size -- but more are welcome! If you're interested and haven't written me yet, please do so ... ----- From David Maymudes (maymudes%husc4.harvard.edu): > In particular, we should produce a document describing, in detail, a good, > workable event loop... As a starting point, have you seen the example code MACDTS sent out with the latest package of Tech Notes? It has a basic TEdit example that is almost obscenely well-written. From Matt Mora: Don't forget about the dirty word "scrolling". [...] From John Heckendorn (bmug@garnet.berkeley.EDU): Well, speaking on behalf of the guys who put the PD-ROM together for BMUG, I'm sure we'd be happy to include it on the next version (which is due out sometime this summer). Also, if people are serious about a definitive book of the tangible variety, BMUG may be able to help with the editing and printing; our developers SIG is considering putting together such a beast [...] People who'd like to discuss or contribute to this effort are encouraged to get in touch with Greg Dow of the developers SIG. He can be reached on this account or at apple!bmug!greg.dow@sun.com. From Mark Interrante (mfi@beach.cis.ufl.edu): >...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. From Nicholas Jackiw (jackiw@cs.swarthmore.edu): This "topic-by-topic" approach seems like it might actually work (for great examples of failed USENET-collaborative-integrated-systems, read rec.games.programmer, etc.). Someone needs to be in charge. S/he, with the help of comp.mac.programmer, compiles a list of topics, many of them gathered into a tutorial about a novice's-approach (i. e. development systems -> event loop programming -> resources -> etc.); some of them those topics which are more advanced but are spread out over 1,200 pages of Inside Mac+tech notes (e. g. MDEFs, the complete guide to offscreen bitmaps, etc.). These are put up for grabs; people who want to write the appropriate chapters grab them. Put maybe 5 or 6 people per chapter. Among themselves, they break it into subtasks, discuss its form and contents, co-author and/or co-edit it, write (review and debug) some source-examples, etc. This gets sent back to the Director, who with his/her chosen community of editors decide whether they like it, can do with it, or hate it. In the first case, they revise it and put it into a format similar to the rest of the contributions (maybe they need to work up some guidelines before we write chapters); in the second, they send it back with their objections; in the third, they trash it and put the topic back on the net as up for grabs. < ... As I said in my last posting, this may be more organization than can be successfully imposed on a USENET project. I'll be tempted to try just taking submissions, editing them, submitting them to the reviewers, re-editing them, and posting the result. At least for the first draft. -jnh > Does the original poster of this chain have the expertise and time to consider this? If not, does anyone out there want to? We need programmers AND PEOPLE WHO CAN WRITE. < ... I agree. -jnh > I'm in for exactly-as-long-as-this-remains-a-nonprofit-venture. From David D "Zoo" Zuhn (zuhn@umn-cs.cs.umn.edu): The common denominator among all programmers is TEXT files. [...] From (lost your name, sorry): 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). From (another lost name): 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? < ... A Hypercard UMPG, developed in parallel with the "text" version, would be a tremendous benefit to the people who 1) have enough memory and 2) enjoy Hypercard help. I qualify for 1) and not for 2), but there ARE people who like Hypercard more than manuals. -jnh > From Robert J Woodhead (uunet!biar!trebor): 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. < ... This is becoming controversial enough that this issue ought to be put to a vote. Personally, I don't like old MacWrite. 100% of my use of MacWrite is for reading/printing/ editing online documentation distributed in MacWrite format (Word doesn't convert everything properly). I'd rather see us take a step forward here, but ... Anyway, I'll post a ballot. Please DON'T vote yet. -jnh > 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. < ... More opinions on this subject are welcomed. --jnh > From Larry Rosenstein (lsr@apple.com): > * a basic event loop structure (Pascal and "C" source is a must!) Tech Support distributes sample programs that demonstrate this, as well as how to do a simple TextEdit window. The code is distributed with the same restrictions as Tech Notes -- ie, unlimited redistribution provided you don't charge. You may be able to arrange to use these programs as a guide. > * source code for a WDEF (does anyone have that circular window > WDEF around still? is it public domain?) I did one of these in Pascal. I has a couple of problems with the latest MultiFinder, but I can contribute this. From Tim Dierks (dierks@darwin.cc.nd.edu): [...] I know that I learn best from small examples than from large programs that have what I want to know buried somewhere deep inside them. Therefore I suggest that we have a number of articles, each on some particular aspect of the Mac interface, each done relatively in-depth, rather than several large examples of many different facets, none of which implements the particular feature I'm looking to do. For example, we could have one on menus which would include a short program that does nothing but put up some menus, both through resources and building them, and handle choices, both by indexing off of the menu/item number and by GetItem. It should be sure to use every call in Inside Mac dealing with menus at that level. Perhaps one article for each manager would be a good base, with larger programs that integrate that information also available. < ... More support for the topic-by-topic approach. -jnh > From Juri Munkki (jmunkki@hut.fi): >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. [...] Is there any way to make sure that the programmers are credited even if someone just borrows the guide and publishes. I don't think PD is a good idea in this case. Something like the FSF copyright would be more appropriate. Then the users would be free to use the guide and the code for anything, but they couldn't publish the changed source without publishing the originals or at least making them available. [...] Handling modeless dialogs is a must... With just a few lines of code you can get working modeless dialogs. The dialog manager will do all the worrying about events. > * "C" vs. Pascal [...] I think this part should also inform about differences between MPW C and Think C. [...] This one should come with a sample file containing sample icons. The easiest way is to copy these resources and edit them. That's the way I create icons. > * how to methodically handle menu highlighting/dimming/item > replacement when windows are activated/deactivated--a general- > purpose approach is greatly needed here I have a general purpose method. It uses the RefCon field of a window to read a resource (I have a template for ResEdit) that contains a list of enable/disable changes to make in the menus. Another subroutine changes the names of menu items (using a MEN-delta resource) according to the window and some additional code. > * source code for popup menus Try to contact the person who wrote the September 1988 MacTutor article about a Popupmenu-CDEF. [...] > * source code for hierarchical menus (this one isn't too hard) Also include some warnings not to use h-menus. They can really blow a good user interface. Also warn programmers not use very long popupmenus. (I don't like FONT-menus as popupmenus. A scrolling list box is better.) > * source code (including an INIT) for tearoff menus, if anyone > has this It would be better without the INIT. It should also be written according to Apple User Interface Guidelines... (The book says you have to hold down the command key to tear off a menu...strange... Hypercard & AFX do not need the command key) < ... Personally I'd rather skip the Command key myself. -jnh > > [text-editing module that isn't TextEdit] I don't think this is needed. It takes a surprising amount of code. TextEdit is pretty good after all. Maybe a good TextEdit example (with styles) would be better. < ... I know this is hard. I think it's also badly needed. Has ANYONE got a text editor of moderate size (compiles to under 1 segment) that could be adapted for this kind of use? -jnh > > * 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. Maybe we should let people write the way they want... < ... Don't think so. Everything in the Guide should follow a specific set of standards. Right now I've got my own standards document (for my work here at State), one written by a friend at CMU, the Plum C Standard, and some other references. I'm sure we can come up with both C and Pascal standards that won't be too odious. Readers will certainly appreciate them. -jnh> >...and I'm sure there's more that would be useful. * Sound. I think an example on how to use the old sound driver to produce clickless continuous sampled sound & an example on how to play 'snd ' resources would be nice. I could also give you code for a VBL task that changes the old sound driver into something better suited for arcade games & FX. The VBL makes it very easy to have two channels of clickfree 11 Khz sampled sound. It doesn't allow you to change the pitch, but that should be ok for Dark Castle-type effects. Maybe the guide could also be made into a book. A lot of people will much rather read the book than a CRT. You could try to get the book published after the electronic version is ready. Please do not make it public domain. There are too many ways people can abuse it if it is pd... From Tony Jacobs (t-jacobs@ced.utah.edu): I would also like to see some source code for playing sound of the various flavors, snd1, snd2 etc. --- that's all, folks ... -- 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 . . . . . . . . . . .