Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!purdue!decwrl!labrea!Portia!Jessica!duggie From: duggie@Jessica.stanford.edu (Doug Felt) Newsgroups: comp.sys.mac.programmer Subject: Re: XFCN/XCMD string in LSC C v3.0 Message-ID: <1744@Portia.Stanford.EDU> Date: 21 Apr 89 18:21:45 GMT References: <1567@Portia.Stanford.EDU> <2810@pegasus.ATT.COM> Sender: USENET News System Reply-To: duggie@Jessica.stanford.edu (Doug Felt) Organization: Stanford University Lines: 57 In article <2810@pegasus.ATT.COM> ech@pegasus.ATT.COM (Edward C Horvath) writes >The problem is more generic: it is not just strings, but other resources >as well (PICT, MENU, DLOG, ICN#, etc) that one might want to tie to an >XCMD. I'm not necessarily advocating all that stuff, nor would I be likely >to use it all in a single XCMD or group thereof. In the absence of an >"owned resource" definition, I have to find some way to embed EVERYTHING in >the XCMD resource itself. Yes. Or make up your own definition of owned resources for this purpose, and write an installer that recognizes it. (quote of my heretical statement omitted) >... XCMDs provide a way to EXTEND a powerful user- >interface engine. The present mechanism is inadequate; it needs better >engineering, it is not an excuse for user-interface anarchy. Oh, a little anarchy helps grease the wheels a bit... :-) I would not call Hypercard a powerful user-interface engine. Rather, it is a bit of "interesting anarchy" that happens to be distributed to hundreds of thousands of people for free by a large computer company. Like the 128K Mac, its uses are limited. Like the 128K Mac, it is essentially an enormous beta test (Will users learn Hypertalk? What will they do with cards and buttons? Let's find out!). And, like the 128K Mac, we will be struggling to get out from under its quirks for many years to come. That said, it is undeniably a "seminal" product, (we like to use that word in the educational community) and I hope people take a look at the various ideas and run in different directions with them. I have long been an advocate of "applicationless environments" where instead of applications there are just chunks of code that perform different functions. The granularity would be smaller than an application but larger than a routine (XCMD). These chunks, plus other resources, would be managed by a database in the operating system. With a number of object-oriented systems starting to stabilize on user interface classes, it starts to look possible to partition out the user interface from the code. And perhaps when we get rid of applications we can get rid of files (as user-visible entities with fixed data formats) too. Ditto for directories. (Users do need to organize their work, but hierarchical directories are not the best way to do it). In short, we need more anarchy, as long as it's interesting. These string (resource) problems have to be solved, for the moment, but they're not interesting, and "anarchy" here is just randomness, neither useful nor, in my opinion, terribly harmful. I say develop a nested resource format and a replacement for the resource manager. Now that would be anarchy! >=Ned Horvath= Doug ("overthrow toolbox tyranny") Felt Courseware Authoring Tools Project duggie@jessica.stanford.edu