AWCTTYPA@UIAMVS.BITNET ("David A. Lyons") (02/10/89)
>Date: Wed, 8 Feb 89 02:27:49 GMT >From: Sean Kamath >Interresting, David. Yes, the resource fork was designed for the Desktop >interface, simply because of the immense complexity of it. Without a >resource fork, making menus, dialog boxes, etc., is a complete pain in the >butt. I dunno about a _complete_ pain in the butt; anybody who has written a GS desktop-based application has done it. I'm definitely looking forward to being able to design them interactively and visually. Dave: >>Many kinds of resources can be edited interactively in an >>application Sean: >all of which can lead to frighteningly strange desktops, where the whole >idea of the "common" interface is chucked out the window. . . Or it can lead to not-strange desktops: so what? A resource editor doesn't have a concept of "strangeness"--it's just a tool you can use however you want. (Geez, you can take a magic marker and edit your walls with it interactively, and you can come up with frightenly strange walls if you want. :-) >Keep in mind that you have to hard code resource numbers into the >program. Not necessarily: you can hard-code resource _names_ into the program if you prefer. (I'm talking about actual string names, not just CONSTs that stand for numbers or something.) >Granted, a lot of the problem is with ResEdit, but sometimes it just >the whole concept. If I'm building an application with menu's, and I >decide to add a menu item, say, to the beginning of a menu, then all >the one's "down" it change their number, and I have to recompile >after finding all occurences of the id number. [...] Not on the GS: menu items have their own ID numbers, so they don't change when you rearrange your menus. >>Since it's possible (on the Mac anyway) to have executable code in >>resources, there are some really keen things you can do: You can >>let the user customize your program by adding code to it! > >I.e. add the virus *very* easy . . . :-( That's true, unfortunately. There are utilities for the Mac that will warn you whenever a program attempts to modify certain kinds of resources that most legitimate programs have no business fiddling with. >Let's not forget that the rest of the world doesn't have resources, >and that such things as "mactar" only back up the data fork [...] Sounds like a good reason not to use "mactar". >[...] Ever read inside mac? init that before you init this, but only >after initing this, which will then allow that to . . ." Yuk. Yup, reads lots of that, & also lots of GS manuals that are similar. GS tool startup order is dealt with pretty well in a Tech Note (which is modified whenever releases more toolsets). >Sean >UUCP: {decvax allegra ucbcad ucbvax hplabs}!tektronix!reed!kamath >CSNET: reed!kamath@Tektronix.CSNET || BITNET: kamath@reed.BITNET >ARPA: kamath%reed.bitnet@cunyvm.cuny.edu >US Snail: 3934 SE Boise, Portland, OR 97202-3126 (I hate 4 line .sigs!) --David A. Lyons bitnet: awcttypa@uiamvs DAL Systems CompuServe: 72177,3233 P.O. Box 287 GEnie mail: D.LYONS2 North Liberty, IA 52317 AppleLinkPE: Dave Lyons
blochowi@cat28.CS.WISC.EDU (Jason Blochowiak) (02/10/89)
> Not on the GS: menu items have their own ID numbers, so they don't > change when you rearrange your menus. I believe he was talking about menu ITEMS, not the menus themselves, in which case he's correct - to have the menu layout conceptually map to the application, you have to "move down" all the item ID #'s when you insert a item. Fortunately (sp?) we have "enum" and "x equ y+1" Jason Blochowiak (blochowi@wherever_i_am - garfield.cs.wisc.edu?) "Not your average iconoclast..." Dave Whitney: Where are you? Write to me; either here or @lakesys will do.