From: pottier@clipper.ens.fr (Francois Pottier) Subject: csmp-digest-v3-061 Date: Thu, 29 Sep 1994 18:36:24 +0100 (MET) C.S.M.P. Digest Thu, 29 Sep 94 Volume 3 : Issue 61 Today's Topics: Alpha Wordcompletion Script Appending data to WindowRecord Dialogs and (de)activate events Lets talk OpenDoc Linking with QuickTime.xcoff for the power pc Multiple monitors The 'aete' resource and the Script Editor can extensions send appleevents? The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier (pottier@clipper.ens.fr). The digest is a collection of article threads from the internet newsgroup comp.sys.mac.programmer. It is designed for people who read c.s.m.p. semi- regularly and want an archive of the discussions. If you don't know what a newsgroup is, you probably don't have access to it. Ask your systems administrator(s) for details. If you don't have access to news, you may still be able to post messages to the group by using a mail server like anon.penet.fi (mail help@anon.penet.fi for more information). Each issue of the digest contains one or more sets of articles (called threads), with each set corresponding to a 'discussion' of a particular subject. The articles are not edited; all articles included in this digest are in their original posted form (as received by our news server at nef.ens.fr). Article threads are not added to the digest until the last article added to the thread is at least two weeks old (this is to ensure that the thread is dead before adding it to the digest). Article threads that consist of only one message are generally not included in the digest. The digest is officially distributed by two means, by email and ftp. If you want to receive the digest by mail, send email to listserv@ens.fr with no subject and one of the following commands as body: help Sends you a summary of commands subscribe csmp-digest Your Name Adds you to the mailing list signoff csmp-digest Removes you from the list Once you have subscribed, you will automatically receive each new issue as it is created. The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest. Questions related to the ftp site should be directed to scott.silver@dartmouth.edu. Currently no previous volumes of the CSMP digest are available there. Also, the digests are available to WAIS users. To search back issues with WAIS, use comp.sys.mac.programmer.src. With Mosaic, use http://www.wais.com/wais-dbs/comp.sys.mac.programmer.html. ------------------------------------------------------- >From tnleeuw@cs.vu.nl (Leeuw van der TN) Subject: Alpha Wordcompletion Script Date: Thu, 15 Sep 1994 12:09:12 GMT Organization: Fac. Wiskunde & Informatica, VU, Amsterdam #This is a Tcl 'script'/procedure for use with Pete Keleher's Alpha. #It completes any word you have typed previously if you bind it to a key. #(I have it bound to opt-/ to simulate emacs' alt-/) #See the comments below for some more info. I've tested it as good as I #can, but cannot guarantee it is bug free. It had some bugs that appeared #to crash Alpha because it came into an endless loop; press cmd-. if #that happens. I don't think it will. #If you use Alpha, then Have luck with it! #--Tim van der Leeuw # tnleeuw@cs.vu.nl #=========================================================================== # 'Word Completion', in the spirit of Paul van Mulbregt's BBXT. # # Composed by Mark Nagata (nagata@kurims.kyoto-u.ac.jp) # for Alpha 5.76, 4/22/94. # # Modified by Tim van der Leeuw (tnleeuw@cs.vu.nl), 9/14/94, # In the spirit of emacs. # I have modified this routine extensively to add the ability to complete # a word in multiple ways if called repeatedly. # For this purpose, I have introduced all the global variables (starting with # __wc__) and added the first if-statement -- everything between # 'set pos [getPos]' and 'backwardWord'. In the original routine, I've changed # some existing variables to globals, prefixing their name with '__wc__'. # # This code is probably not the most efficient tcl-code, nor the most elegant # tcl-code for this problem, but hey, it is the first function I've ever # written in tcl! # If anyone has some suggestions for improvement, or # knows of a better algorithm, I would like to know it. #================================================================================ set __wc__insPos -1 proc wordCompletion {} { global __wc__len __wc__prevPos __wc__insPos __wc__prevFound __wc__pat __wc__nextStart __wc__fwd set pos [getPos] if $pos==$__wc__insPos { # Cursor changed place? set skipStr $__wc__prevFound while 1 { if $__wc__fwd { set fndMsg "found below." } else { set fndMsg "found above." } if {![catch {search -f $__wc__fwd -r 1 -i 0 -m 1 -- $__wc__pat $__wc__nextStart} data]} { set d00 [lindex $data 0] set beg [expr $d00+$__wc__len] set end [lindex $data 1] set __wc__prevFound [getText $d00 $end] if [string compare $skipStr $__wc__prevFound] { # Have we got the same word twice? set txt [getText $beg $end] deleteText $__wc__prevPos $__wc__insPos goto $__wc__prevPos insertText $txt message $fndMsg # Set a number of globals for possible next go-around set __wc__insPos [getPos] if $__wc__fwd { # Search Forwards set __wc__nextStart $end # End of found word } else { # Search Backwards set __wc__nextStart [expr $d00 - $__wc__len] # Before start of found word if $__wc__nextStart<=0 { set __wc__fwd 1 set __wc__nextStart $__wc__insPos } } return } else { # Move start of search after finding string again if $__wc__fwd { # Searching Forwards set __wc__nextStart $end # End of found word } else { # Still Searching Backwards set __wc__nextStart [expr $d00 - $__wc__len] # Before start of found word if $__wc__nextStart<=0 { set __wc__fwd 1 set __wc__nextStart $__wc__insPos } } } # End if string compare } else { # Search string not found if $__wc__fwd { # We were already looking forward, so the word is not in the file message "Not found." set __wc__insPos -1 goto $pos backwardWordSelect return } else { # start looking forward set __wc__fwd 1 set __wc__nextStart $__wc__insPos } } } } backwardWord # Start new search for WordCompletion set start [getPos] set one [getText $start $pos] set __wc__len [expr $pos-$start] set __wc__pat [append one {[a-zA-Z0-9_]+}] set start [expr $start-1] if {![catch {search -f 0 -r 1 -i 0 -m 1 -- $__wc__pat $start} data]} { set d00 [lindex $data 0] set beg [expr $d00+$__wc__len] set end [lindex $data 1] set __wc__prevFound [getText $d00 $end ] set txt [getText $beg $end] goto $pos insertText $txt message "found above." # Set a number of globals for possible next go-around set __wc__insPos [getPos] set __wc__prevPos $pos set __wc__nextStart [expr $d00-$__wc__len] set __wc__fwd 0 return } if {![catch {search -f 1 -r 1 -i 0 -m 1 -- $__wc__pat $pos} data]} { set __wc__prevFound [getText [lindex $data 0] [lindex $data 1] ] set beg [expr [lindex $data 0]+$__wc__len] set end [lindex $data 1] set txt [getText $beg $end] goto $pos insertText $txt message "found below." # Set a number of globals for possible next go-around set __wc__insPos [getPos] set __wc__prevPos $pos set __wc__nextStart $end set __wc__fwd 1 return } goto $pos backwardWordSelect } # This is all due to the idea of Paul van Mulbregt. In his documentation # of his BBEdit BBExtension (info-mac/text/bbedit-fl-package-11.hqx), # he explains: # # -- From the documentation written by -- # -- Paul van Mulbregt (paulvm@dragonsys.com) -- # # Word Completion # # This extension saves typing, as well as making sure variable names are # correct. While typing the following C code, there is no need to type all # of the second occurrence of verySpecialInt. One could copy and paste, but # another way is to type a few letters, and select the Word Completion # Extension. # # int verySpecialInt = 10; # while(verySp # # # becomes # # int verySpecialInt = 10; # while(verySpecialInt # # # # Word Completion will look back in the code to find the first match and then # extend the current occurrence to match the previous occurrence. If a match # is not found looking backwards, then it looks forwards. If not found # forwards, the word is selected. This is a quick way to save on typing, # good for helping prevent RSI, but perhaps more importantly, to make sure # that variable names are spelt correctly. # # There is no user interface for Word Completion. # # The usefulness of this extension is greatly enhanced if the extension is # bound to a key! # # -- end of Paul van Mulbregt's explanation. -- --------------------------- >From rollin@newton.apple.com (Keith Rollin) Subject: Appending data to WindowRecord Date: Tue, 30 Aug 1994 09:42:08 -0800 Organization: Apple ][ -> Mac -> Taligent -> Newton -> Windows? In article <33do4d$abh@newsy.ifm.liu.se>, jonasw@lysator.liu.se (Jonas Wallden) wrote: > >A great way to extend WindowRecords is to declare your own data type with >a WindowRecord as the first item. > >E.g., > >struct tMyWinData { > // This must come first! > WindowRecord winRec; > > // Additional window-specific data here... > Handle aHandle; > Ptr aPtr; >}; >typedef struct tMyWinData tMyWinData; >typedef tMyWinData *tMyWinPtr; > >The trick now is that you can typecast any window pointer to tMyWinPtr (and >back) and access your window-specific data fields. You might want to place >your application's unique creator code in the WindowRecord refCon field and >check it first to be sure you have a window that belongs to your program. > >I use this all the time and it is useful in many other places where the >system gives you a pointer to an object (VBL tasks, ParamBlocks, ...) and >you need to store extra data. No need to use any globals for this stuff! You know, this is an often-used trick, but I've got a sneaking suspicion that it might not be a good idea in the long run. The reason for this feeling is because of something I read in "develop" a while back. In the article that Dean Yu (I think) wrote on floating windows, there was mention of converting the Windows.h interfaces over to using WindowRefs instead of WindowPtrs. (Indeed, users of ETO #15 will see that this change has already occured.) This change was being done to prepare developers for the day when windows would change from being accessed directly via pointers, to the day when they would be accessed via abstract references that could be mapped by the Window Manager internally to the data structures representing a window. It seems to me that in such a world, you could not be able to either a) append your custom data to the standard window definition, or b) retrieve it given a simple WindowRef. I recommend using the refCon field. - -------------------------------------------------------------------------- Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton +++++++++++++++++++++++++++ >From jonasw@lysator.liu.se (Jonas Wallden) Date: 31 Aug 1994 15:19:10 GMT Organization: (none) rollin@newton.apple.com (Keith Rollin) writes: > I (Jonas) wrote: >> >>A great way to extend WindowRecords is to declare your own data type with >>a WindowRecord as the first item. >> >> [code example removed] >> >>The trick now is that you can typecast any window pointer to tMyWinPtr (and >>back) and access your window-specific data fields. You might want to place >>your application's unique creator code in the WindowRecord refCon field and >>check it first to be sure you have a window that belongs to your program. >> >>I use this all the time and it is useful in many other places where the >>system gives you a pointer to an object (VBL tasks, ParamBlocks, ...) and >>you need to store extra data. No need to use any globals for this stuff! > >You know, this is an often-used trick, but I've got a sneaking suspicion >that it might not be a good idea in the long run. The reason for this >feeling is because of something I read in "develop" a while back. In the >article that Dean Yu (I think) wrote on floating windows, there was >mention of converting the Windows.h interfaces over to using WindowRefs >instead of WindowPtrs. Yes, now that you mention it I remember that article. Your point is very valid, and should be taken into consideration for code that one expects to use for a long time. However, like you said yourself, this trick is widely used and a lot of applications would break if things changed tomorrow. > Indeed, users of ETO #15 will see that this change has already occured. I haven't seen it in the Universal Interfaces included on CW4. Are the ones on ETO #15 different? I agree that hiding the internal structure of things is a good thing as it will make it easier for Apple to change the system without breaking applications. >I recommend using the refCon field. Which leads us back to the original problem where the poster was afraid to treat this field as a pointer in case some other window appeared in his application's window list (CommsToolbox (did I spell it right? :-) windows were mentioned as an example). One can of course first check the windowKind field, which doesn't have any accessor function... >Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton -- `.`. Jonas Wallden `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`. `.`.`. Internet: jonasw@lysator.liu.se `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`. `.`.`.`. AppleLink: sw1369 `.`.`.`.`.`.`.`.`.`.`.`.`.`.`. +++++++++++++++++++++++++++ >From bb@lightside.com (Bob Bradley) Date: Tue, 30 Aug 1994 01:50:06 -0800 Organization: SS Software Inc. In article <34271e$i33@newsy.ifm.liu.se>, jonasw@lysator.liu.se (Jonas Wallden) wrote: > One can of course first check the windowKind field, which doesn't have any > accessor function... The only problem I've found with this is when using Dialogs which don't work properly with IsDialogEvent and DialogSelect if you change the windowKind field to something other than dialogKind. The only solution I've found in that case is to append data to the WindowRecord. +++++++++++++++++++++++++++ >From mhl@icf.hrb.com (MARK H. LINTON) Date: 31 Aug 94 15:39:42 EST Organization: HRB Systems, Inc. In article <34271e$i33@newsy.ifm.liu.se>, jonasw@lysator.liu.se (Jonas Wallden) writes: > rollin@newton.apple.com (Keith Rollin) writes: >> I (Jonas) wrote: >>> >>>A great way to extend WindowRecords is to declare your own data type with >>>a WindowRecord as the first item. >>> >> >>You know, this is an often-used trick, but I've got a sneaking suspicion >>that it might not be a good idea in the long run. The reason for this >>feeling is because of something I read in "develop" a while back. > > Yes, now that you mention it I remember that article. Your point is very > valid, and should be taken into consideration for code that one expects > to use for a long time. [snip] > > >>I recommend using the refCon field. > > Which leads us back to the original problem where the poster was afraid to > treat this field as a pointer in case some other window appeared in his > application's window list (CommsToolbox (did I spell it right? :-) windows > were mentioned as an example). > > One can of course first check the windowKind field, which doesn't have any > accessor function... > >>Keith Rollin --- Phantom Programmer --- Apple Computer, Inc. --- Team Newton > When my applications create their own windows, they allocate a relocatable block (via NewHandle) to a structure describing the window. The structure of this information varies based on the particular application, but always includes, at minimum, as its first field an identifier. Please consider the following pseudo-code, as I am not at my Macintosh at the moment. typedef struct MinWinInfo { OSType identifier; } MinWinInfoRecord, *MinWinInfoPtr, **MinWinInfoHandle; Boolean OwnWindow(WindowPtr aWindow) { Boolean ownWindow = false; MinWinInfoHandle theInfoHandle; if (aWindow != nil) { /* can only own existent windows */ theInfoHandle = (MinWinInfoHandle)GetWRefCon(aWindow); if (theInfoHandle != nil) { /* and we always add a refCon */ if ((**theInfoHandle).identifier == kThisAppSignature) { ownWindow = true; /* and the first four bytes match our sig */ } } } return ownWindow; } So whenever I need to see whether a window is mine I just call OwnWindow. Does this help? Or did I miss the question entirely? Mark - -------- I don't know whether my employer has opinions. +++++++++++++++++++++++++++ >From jonasw@lysator.liu.se (Jonas Wallden) Date: 31 Aug 1994 21:35:02 GMT Organization: (none) mhl@icf.hrb.com (MARK H. LINTON) writes: > >When my applications create their own windows, they allocate a relocatable >block (via NewHandle) to a structure describing the window. The structure of >this information varies based on the particular application, but always >includes, at minimum, as its first field an identifier. > >Please consider the following pseudo-code, as I am not at my Macintosh at the >moment. > >typedef struct MinWinInfo { > OSType identifier; >} MinWinInfoRecord, *MinWinInfoPtr, **MinWinInfoHandle; > >Boolean OwnWindow(WindowPtr aWindow) { > Boolean ownWindow = false; > MinWinInfoHandle theInfoHandle; > > if (aWindow != nil) { /* can only own existent windows */ > theInfoHandle = (MinWinInfoHandle)GetWRefCon(aWindow); > if (theInfoHandle != nil) { /* and we always add a refCon */ > if ((**theInfoHandle).identifier == kThisAppSignature) { The problem is that we can't be 100% sure the RefCon field holds a pointer or handle for *all* windows as some windows not created by our application can appear in our WindowList. These external windows may use the RefCon field in any way (e.g. hold flags or whatever), making it impossible to dereference the value to check for the magic cookie. > ownWindow = true; /* and the first four bytes match our sig */ > } > } > } > return ownWindow; >} > >So whenever I need to see whether a window is mine I just call OwnWindow. > >Does this help? Or did I miss the question entirely? See above. Hopefully the Apple guys come up with a nice improved Window Manager which supposedly is in the works. From what I've heard it will support floating windows directly (yes!), and that alone will make a lot of ugly code unneeded. Anyone else mad at not getting modeless dialogs to work correctly together with floating windows? Yeah, I thought so... -- `.`. Jonas Wallden `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`. `.`.`. Internet: jonasw@lysator.liu.se `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`. `.`.`.`. AppleLink: sw1369 `.`.`.`.`.`.`.`.`.`.`.`.`.`.`. +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Thu, 01 Sep 1994 14:55:07 +0200 Organization: Royal Institute of Something or other In article <342t26$1ia@newsy.ifm.liu.se>, jonasw@lysator.liu.se (Jonas Wallden) wrote: >The problem is that we can't be 100% sure the RefCon field holds a pointer >or handle for *all* windows as some windows not created by our application >can appear in our WindowList. These external windows may use the RefCon All windows in our window list that are not our own have negative windowKinds, or at least windowKinds < 8. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Reality exists only in your imagination. +++++++++++++++++++++++++++ >From mhl@icf.hrb.com (MARK H. LINTON) Date: 1 Sep 94 08:50:27 EST Organization: HRB Systems, Inc. In article <342t26$1ia@newsy.ifm.liu.se>, jonasw@lysator.liu.se (Jonas Wallden) writes: > mhl@icf.hrb.com (MARK H. LINTON) writes: >> >> if (aWindow != nil) { /* can only own existent windows */ >> theInfoHandle = (MinWinInfoHandle)GetWRefCon(aWindow); >> if (theInfoHandle != nil) { /* and we always add a refCon */ >> if ((**theInfoHandle).identifier == kThisAppSignature) { > > The problem is that we can't be 100% sure the RefCon field holds a pointer > or handle for *all* windows as some windows not created by our application > can appear in our WindowList. These external windows may use the RefCon > field in any way (e.g. hold flags or whatever), making it impossible to > dereference the value to check for the magic cookie. > Jonas, Correct me if I'm wrong here. I did not say that the refCon WAS a handle. The cast on the GetWRefCon tells the compiler to ASSUME that the refCon is a handle. If it is flags or maybe a handle to another type of structure used by another type of window. HOWEVER, it is highly unlikely that the first four bytes of the memory arrived at by double de-referencing (**) the refCon will contain my applications signature, whether the assumption was true or not, UNLESS this is one of my windows. BTW my applications require System 7 and at least a 68030 to run, so I do not care if in my (**) I come across an odd address ;^) Mark +++++++++++++++++++++++++++ >From dazuma@cco.caltech.edu (Daniel Azuma) Date: Thu, 01 Sep 1994 08:06:29 -0700 Organization: California Institute of Technology mhl@icf.hrb.com (MARK H. LINTON) wrote: > Correct me if I'm wrong here. I did not say that the refCon WAS a handle. > The cast on the GetWRefCon tells the compiler to ASSUME that the refCon is > a handle. If it is flags or maybe a handle to another type of structure used > by another type of window. HOWEVER, it is highly unlikely that the first four > bytes of the memory arrived at by double de-referencing (**) the refCon will > contain my applications signature, whether the assumption was true or not, > UNLESS this is one of my windows. > > BTW my applications require System 7 and at least a 68030 to run, so I do not > care if in my (**) I come across an odd address ;^) You still have to worry, even if you require an '020/'030. Trying to dereference addresses in a certain range-- I don't know the range, but the famous constant 0x50FFC001 is within it-- will cause a bus error. What I've ended up doing is keeping my own data structure listing all the windows I "know about", including modeless dialogs. My array keeps the WindowPtr, a constant describing the kind of window, and some other fields containing various other info. Then, when I need to know something about a particular window (say, from FrontWindow()), I look the WindowPtr up in the table and snatch whatever info I need. If the WindowPtr isn't there, I know it's a window someone else rudely :) stuck into my window list. Not the most efficient way of doing things, I'm sure, but I think it's relatively un-breakable. And, of course, later I can replace the WindowPtr field with a WindowRef and have it work the same way. Dan - ---------------------------------------------------------------- Daniel Azuma | "Rejoice in the Lord always; again I Caltech | will say, Rejoice..." dazuma@cco.caltech.edu | --Philippians 4:4 - ---------------------------------------------------------------- +++++++++++++++++++++++++++ >From jonasw@lysator.liu.se (Jonas Wallden) Date: 1 Sep 1994 15:54:15 GMT Organization: (none) mhl@icf.hrb.com (MARK H. LINTON) writes: >In article <342t26$1ia@newsy.ifm.liu.se>, jonasw@lysator.liu.se (Jonas Wallden) writes: >> mhl@icf.hrb.com (MARK H. LINTON) writes: >>> >>> if (aWindow != nil) { /* can only own existent windows */ >>> theInfoHandle = (MinWinInfoHandle)GetWRefCon(aWindow); >>> if (theInfoHandle != nil) { /* and we always add a refCon */ >>> if ((**theInfoHandle).identifier == kThisAppSignature) { >> >> The problem is that we can't be 100% sure the RefCon field holds a pointer >> or handle for *all* windows as some windows not created by our application >> can appear in our WindowList. These external windows may use the RefCon >> field in any way (e.g. hold flags or whatever), making it impossible to >> dereference the value to check for the magic cookie. >> > >Jonas, > Correct me if I'm wrong here. I did not say that the refCon WAS a handle. >The cast on the GetWRefCon tells the compiler to ASSUME that the refCon is >a handle. If it is flags or maybe a handle to another type of structure used >by another type of window. HOWEVER, it is highly unlikely that the first four >bytes of the memory arrived at by double de-referencing (**) the refCon will >contain my applications signature, whether the assumption was true or not, >UNLESS this is one of my windows. > >BTW my applications require System 7 and at least a 68030 to run, so I do not >care if in my (**) I come across an odd address ;^) But you can get address errors on these machines as well! How do you think EvenBetterBusError works? And like I, Jon and others have said earlier, one can check the windowKind field first to avoid these cases. But that is just as bad as appending data to the WindowRecord as long as there isn't any high-level (i.e. future-compatible) way to do this. -- `.`. Jonas Wallden `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`. `.`.`. Internet: jonasw@lysator.liu.se `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`. `.`.`.`. AppleLink: sw1369 `.`.`.`.`.`.`.`.`.`.`.`.`.`.`. +++++++++++++++++++++++++++ >From ivanski@world.std.com (Ivan M CaveroBelaunde) Date: Thu, 1 Sep 1994 16:15:59 GMT Organization: The World Public Access UNIX, Brookline, MA jonasw@lysator.liu.se (Jonas Wallden) writes: >>Boolean OwnWindow(WindowPtr aWindow) { >> Boolean ownWindow = false; >> MinWinInfoHandle theInfoHandle; >> >> if (aWindow != nil) { /* can only own existent windows */ >> theInfoHandle = (MinWinInfoHandle)GetWRefCon(aWindow); >> if (theInfoHandle != nil) { /* and we always add a refCon */ >> if ((**theInfoHandle).identifier == kThisAppSignature) { >The problem is that we can't be 100% sure the RefCon field holds a pointer >or handle for *all* windows as some windows not created by our application >can appear in our WindowList. These external windows may use the RefCon >field in any way (e.g. hold flags or whatever), making it impossible to >dereference the value to check for the magic cookie. So use a "ValidHandle" routine to determine that the refcon is a handle before messing with it: - Check that it's even. - Check that it's below BufPtr. - Do both checks again for the "assumed" master pointer. - Call HandleZone. in that order. Then you know you have a handle you can safely dereference. -Ivan - - Ivan Cavero Belaunde (ivanski@world.std.com) Avid VideoShop Project Lead Avid Technology, Inc. +++++++++++++++++++++++++++ >From mhl@icf.hrb.com (MARK H. LINTON) Date: 1 Sep 94 13:27:35 EST Organization: HRB Systems, Inc. From: jonasw@lysator.liu.se (Jonas Wallden) >>In article <342t26$1ia@newsy.ifm.liu.se>, jonasw@lysator.liu.se (Jonas Wallden) writes: >>> mhl@icf.hrb.com (MARK H. LINTON) writes: >>>> >>>> if (aWindow != nil) { /* can only own existent windows */ >>>> theInfoHandle = (MinWinInfoHandle)GetWRefCon(aWindow); >>>> if (theInfoHandle != nil) { /* and we always add a refCon */ >>>> if ((**theInfoHandle).identifier == kThisAppSignature) { >>> >>> The problem is that we can't be 100% sure the RefCon field holds a pointer >>> or handle for *all* windows as some windows not created by our application >>> can appear in our WindowList. [snip] >> >>Jonas, >> Correct me if I'm wrong here. I did not say that the refCon WAS a handle. >>The cast on the GetWRefCon tells the compiler to ASSUME that the refCon is >>a handle. [snip] >> >>BTW my applications require System 7 and at least a 68030 to run, so I do not >>care if in my (**) I come across an odd address ;^) > >But you can get address errors on these machines as well! How do you think >EvenBetterBusError works? > Gosh, I guess I was wrong :) and, yes, I have EvenBetterBusError installed, but I seem to recall the release notes saying something about needing to allow certain Toolbox routines to do things that would normally trigger EBBE. Perhaps this is the sort of thing that required that. (?) > >And like I, Jon and others have said earlier, one can check the windowKind >field first to avoid these cases. But that is just as bad as appending data to >the WindowRecord as long as there isn't any high-level (i.e. future-compatible) >way to do this. > Yes, I agree. I really do not like the windowKind check. From: ivanski@world.std.com (Ivan M CaveroBelaunde) > >So use a "ValidHandle" routine to determine that the refcon is a handle >before messing with it: > - Check that it's even. > - Check that it's below BufPtr. > - Do both checks again for the "assumed" master pointer. > - Call HandleZone. > >in that order. Then you know you have a handle you can safely dereference. > Hey! Way Cool! Where I originally said "if (theInfoHandle != nil) {", I really should have said "if (ValidHandle((Handle)theInfoHandle)) {". Got any CODE? ;^) From: dazuma@cco.caltech.edu (Daniel Azuma) > >You still have to worry, even if you require an '020/'030. Trying to >dereference addresses in a certain range-- I don't know the range, but the >famous constant 0x50FFC001 is within it-- will cause a bus error. > Yes. I keep getting told this :^) and pardon my ignorance but what is that famous constant? > >What I've ended up doing is keeping my own data structure listing all the >windows I "know about", including modeless dialogs. My array keeps the >WindowPtr, a constant describing the kind of window, and some other fields >containing various other info. Then, when I need to know something about a >particular window (say, from FrontWindow()), I look the WindowPtr up in >the table and snatch whatever info I need. If the WindowPtr isn't there, I >know it's a window someone else rudely :) stuck into my window list. Not >the most efficient way of doing things, I'm sure, but I think it's >relatively un-breakable. > >And, of course, later I can replace the WindowPtr field with a WindowRef >and have it work the same way. > Until today I would have gaged at the extra baggage here. But I have been following this other thread (Subject: Selecting Window via menus) on which was recently posted a reasonable solution (From: Matt Slot ) that required a similar structure. Now that I see the two side by side, I might try to roll them together and come up with a reasonable "Window Manager". Hey, now wasn't that Jonas' original point? :) Mark +++++++++++++++++++++++++++ >From dazuma@cco.caltech.edu (Daniel Azuma) Date: Thu, 01 Sep 1994 11:37:34 -0700 Organization: California Institute of Technology mhl@icf.hrb.com (MARK H. LINTON) wrote: > From: ivanski@world.std.com (Ivan M CaveroBelaunde) > > > >So use a "ValidHandle" routine to determine that the refcon is a handle > >before messing with it: > > - Check that it's even. > > - Check that it's below BufPtr. > > - Do both checks again for the "assumed" master pointer. > > - Call HandleZone. > > > >in that order. Then you know you have a handle you can safely dereference. That's pretty cool, yeah! My question is, how would it work when running PPC native? I'm kinda clueless about PowerMac memory management... > >You still have to worry, even if you require an '020/'030. Trying to > >dereference addresses in a certain range-- I don't know the range, but the > >famous constant 0x50FFC001 is within it-- will cause a bus error. > > Yes. I keep getting told this :^) and pardon my ignorance but what is that > famous constant? It's the long that EBBE stuffs into nil. Supposedly, it's designed to cause a bus or address error on any mac with any memory configuration. I don't know exactly what's so special about this constant as opposed to, say, 0x60FFC001, though. :) Dan - ---------------------------------------------------------------- Daniel Azuma | "Rejoice in the Lord always; again I Caltech | will say, Rejoice..." dazuma@cco.caltech.edu | --Philippians 4:4 - ---------------------------------------------------------------- +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Fri, 02 Sep 1994 11:37:10 +0800 Organization: NCRPDA, Curtin University In article <1994Sep1.085027.21786@hrbicf>, mhl@icf.hrb.com (MARK H. LINTON) wrote: >BTW my applications require System 7 and at least a 68030 to run, so I do not >care if in my (**) I come across an odd address ;^) Yeah, but what if it is an address that isn't valid, or isn't mapped, or whatever. It'll still go bang. You need to use some variant of ValidHandle, checking that the ptr is even, and inside your heap, and that the ptr points to a ptr that is even and in your heap are definitely good ideas if you are going to use this scheme. Peter. -- Peter N Lewis - Macintosh TCP fingerpainter +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Fri, 02 Sep 1994 09:18:41 +0200 Organization: Royal Institute of Something or other In article <344tf7$4d2@newsy.ifm.liu.se>, jonasw@lysator.liu.se (Jonas Wallden) wrote: >And like I, Jon and others have said earlier, one can check the windowKind >field first to avoid these cases. But that is just as bad as appending data to >the WindowRecord as long as there isn't any high-level (i.e. future-compatible) >way to do this. I do a #define GetWindowKind(w) ((WindowPeek)w)->windowKind Then when the real call comes around... The interesting thing is that Apple promises that if you follow the current API, and READ but not WRITE where there are no accessor functions, there will be a compatiblity mode. However, to take advantage of the new features, you need a partial re-design and total recompile. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Reality exists only in your imagination. +++++++++++++++++++++++++++ >From siegel@netcom.com (Rich Siegel) Date: Fri, 2 Sep 1994 18:02:45 GMT Organization: Bare Bones Software In article dazuma@cco.caltech.edu (Daniel Azuma) writes: >> From: ivanski@world.std.com (Ivan M CaveroBelaunde) >> > >> >So use a "ValidHandle" routine to determine that the refcon is a handle >> >before messing with it: >> > - Check that it's even. >> > - Check that it's below BufPtr. >> > - Do both checks again for the "assumed" master pointer. >> > - Call HandleZone. >> > >> >in that order. Then you know you have a handle you can safely dereference. > >That's pretty cool, yeah! My question is, how would it work when running >PPC native? I'm kinda clueless about PowerMac memory management... It works just the same. The second word in "Power Macintosh" is "Macintosh", and that's just what a Power Macintosh is, from the application programmer's point of view. Incidentally, you probably only want to use Ivan's handle check in debugging code, not in shipping code: HandleZone() doesn't come for free. R. -- Rich Siegel % siegel@netcom.com % President & CEO, Bare Bones Software Inc. --> For information about BBEdit, finger bbedit@world.std.com <-- +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Sun, 04 Sep 1994 13:17:08 +0200 Organization: Royal Institute of Something or other In article , dazuma@cco.caltech.edu (Daniel Azuma) wrote: >It's the long that EBBE stuffs into nil. Supposedly, it's designed to >cause a bus or address error on any mac with any memory configuration. I >don't know exactly what's so special about this constant as opposed to, >say, 0x60FFC001, though. :) 50ff is also an illegal instruction, so if you JUMP to 0L, you'll get an immediate break. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Engineering: "How will this work?" Science: "Why will this work?" Management: "When will this work?" Liberal Arts: "Do you want fries with that?" -- Jesse N. Schell +++++++++++++++++++++++++++ >From Ron_Hunsinger@bmug.org (Ron Hunsinger) Date: Wed, 7 Sep 94 03:23:37 PST Organization: Berkeley Macintosh Users Group siegel@netcom.com writes: >Incidentally, you probably only want to use Ivan's handle check in >debugging code, not in shipping code: HandleZone() doesn't come for >free. And if you were a ship-builder, I suppose your ships would only be equipped with life boats while you tested them in the harbor, but you would remove all that extra baggage before sending them out to sea? -Ron Hunsinger +++++++++++++++++++++++++++ >From kluev@jonathan.srcc.msu.su (Kluev) Date: Wed, 7 Sep 94 20:22:41 +0400 Organization: (none) In article <9668AA8B9BCC.DC7EB6@klkmac014.nada.kth.se> h+@nada.kth.se (Jon W{tte) wrote: In article <342t26$1ia@newsy.ifm.liu.se>, jonasw@lysator.liu.se (Jonas Wallden) wrote: > > >The problem is that we can't be 100% sure the RefCon field holds a pointer > >or handle for *all* windows as some windows not created by our application > >can appear in our WindowList. These external windows may use the RefCon > > All windows in our window list that are not our own have > negative windowKinds, or at least windowKinds < 8. The problem doesn't go away: how to distinguish system dialog and my dialog? (windowKind = dialogKind = 2 in this case). The only compatible solution is the one suggested by someone else: keep your own list of windows in addition to standard one (FrontWindow()-> nextWindow-> nextWindow-> ...). Michael Kluev. +++++++++++++++++++++++++++ >From mxmora@unix.sri.com (Matt Mora) Date: 8 Sep 1994 09:09:29 -0700 Organization: SRI International, Menlo Park, CA In article <523026979413@jonathan.srcc.msu.su> kluev@jonathan.srcc.msu.su (Kluev) writes: >compatible solution is the one suggested by someone else: keep your >own list of windows in addition to standard one >(FrontWindow()-> nextWindow-> nextWindow-> ...). I have missed most of the thread but if its about seeing if the window is yours or not I usally add a field called magicSig and stuff that with The app signature or something. So you can tell a window is yours by doing the windowPeek->magicSig == mySig trick. Xavier -- ___________________________________________________________ Matthew Xavier Mora Matt_Mora@sri.com SRI International mxmora@unix.sri.com 333 Ravenswood Ave Menlo Park, CA. 94025 +++++++++++++++++++++++++++ >From gbolsinga@aol.com (GBolsinga) Date: 8 Sep 1994 16:29:04 -0400 Organization: America Online, Inc. (1-800-827-6364) I haven't been able to follow the whole thread, but when can your app get windows that don't belong to it? I certain that I read in NIM: Mac Toolbox Essentials that your app can't get windows from other apps. I can't remember if it was in the Event Mgr or Window Mgr Chapter. I know that there are some errors in NIM. Could someone please let me know how a window from another app could be seen by my app? You see, I am trying to decide how I will keep my extra data with the window, since I'm starting on a new project, and I wasn't too happy with the way I have been doing it. Thanks. Greg Bolsinga MPI Multimedia /* these are my opinions */ +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Fri, 09 Sep 1994 10:07:15 +0200 Organization: Royal Institute of Something or other In article <0019C298.fc@bmug.org>, Ron_Hunsinger@bmug.org (Ron Hunsinger) wrote: >>Incidentally, you probably only want to use Ivan's handle check in >>debugging code, not in shipping code: HandleZone() doesn't come for >>free. >And if you were a ship-builder, I suppose your ships would only be >equipped with life boats while you tested them in the harbor, but you >would remove all that extra baggage before sending them out to sea? This is interesting! If you were a ship builder, would you equip the release version of your ship with helocopters, VTOL jets, lifeboats AND an inflatable cruiser, each capable of holding twice the capacity of the original ship? Debugging code is there to help you catch bugs automatically. By the time you ship, you're supposed to have removed all the bugs (right :-) so users might be somewhat unenthusiastic about waiting two minutes for an "Open File" dialog box to show up. That aside, I usually ship with the debug version of the oops libraries, meaning method calls for unknown methods or illegal objects are usually flagged as command failures (using the old TCL) HandleZone, however, or RecoverHandle, are so expensive that you shouldn't use them in production code unless totally necessary. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden This is the kind of totally-gross-out-sick stuff you can do with C++ that makes the language kind of neat. -- Keith Rollin +++++++++++++++++++++++++++ >From Jens Alfke Date: Sat, 10 Sep 1994 00:02:57 GMT Organization: Apple Computer Kluev, kluev@jonathan.srcc.msu.su writes: > The problem doesn't go away: how to distinguish system dialog and > my dialog? (windowKind = dialogKind = 2 in this case). The only > compatible solution is the one suggested by someone else: keep your > own list of windows in addition to standard one > (FrontWindow()-> nextWindow-> nextWindow-> ...). Or just don't use dialogs at all. I've found that the effort needed to replace the dialog manager isn't much more than the effort needed to write a bunch of good dialog utilities to make the dialog manager easily useable... --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From peter.lewis@info.curtin.edu.au (Peter N Lewis) Date: Sun, 11 Sep 1994 16:30:33 +0800 Organization: NCRPDA, Curtin University >Or just don't use dialogs at all. I've found that the effort needed to >replace the dialog manager isn't much more than the effort needed to write a >bunch of good dialog utilities to make the dialog manager easily useable... Yep, very true. I've gone the other way (using only DLOGs), and if I had it to do over again, I'd swap. Peter. -- Peter N Lewis - Macintosh TCP fingerpainter FTP my programs from redback.cs.uwa.edu.au:Others/PeterLewis/ or amug.org:pub/peterlewis/ or nic.switch.ch:software/mac/peterlewis/ +++++++++++++++++++++++++++ >From kluev@jonathan.srcc.msu.su (Kluev) Date: Sun, 11 Sep 94 20:36:53 +0400 Organization: (none) In article <34ncvp$4ji@unix.sri.com> mxmora@unix.sri.com (Matt Mora) wrote: > In article <523026979413@jonathan.srcc.msu.su> > kluev@jonathan.srcc.msu.su > (Kluev) writes: > > >compatible solution is the one suggested by someone else: keep your > >own list of windows in addition to standard one > >(FrontWindow()-> nextWindow-> nextWindow-> ...). > > I have missed most of the thread but if its about seeing if the window > is yours or not I usally add a field called magicSig and stuff that with > The app signature or something. So you can tell a window is yours by > doing the windowPeek->magicSig == mySig trick. This works of course under current Mac ToolBox/OS. This will work in near future also. But this couldn't be treated as a good long-term solution: 1. Nobody guarantees that system windows will not have magicSig after their DialogRecord/WindowRecord. 2. Future OS may have intelligent memory protection, so you will not be able to write or read from locations beyond memory blocks. 3. Future Toolbox may switch from WindowRecords to WindowRefcons, so you won•t be able to concatenate there your data. (You may emulate this future feature right now: pass NIL as a first parameter to NewDialog/NewWindow.) Again, all this (except 1) is about mystical "future OS". Michael Kluev. +++++++++++++++++++++++++++ >From ivan_cavero_belaunde@avid.com (Ivan Cavero Belaunde) Date: 12 Sep 1994 11:28:41 GMT Organization: Avid Technology, Inc. In article <9668AA95E453.201F4@klkmac004.nada.kth.se>, h+@nada.kth.se (Jon W{tte) wrote: > In article <0019C298.fc@bmug.org>, > Ron_Hunsinger@bmug.org (Ron Hunsinger) wrote: > >>Incidentally, you probably only want to use Ivan's handle check in > >>debugging code, not in shipping code: HandleZone() doesn't come for > >>free. > >And if you were a ship-builder, I suppose your ships would only be > >equipped with life boats while you tested them in the harbor, but you > >would remove all that extra baggage before sending them out to sea? That's a bit harsh; Rich's remark is on target - I believe HandleZone involves walking through a zone's master pointer list. It's pretty costly. > If you were a ship builder, would you equip the release version > of your ship with helocopters, VTOL jets, lifeboats AND an > inflatable cruiser, each capable of holding twice the capacity > of the original ship? > ... > HandleZone, however, or RecoverHandle, are so expensive that > you shouldn't use them in production code unless totally > necessary. Actually, I avoid hard and fast rules with the ValidHandle routine. Depending on how the likelihood (which is related to how you got the "handle") that you got a fake handle, the necessity of it being a handle (are you going to pass it to the toolbox as one?), how often the code would be called (if it's called once in a blue moon ValidHandle ain't that expensive) and the time-consumingness (ack, bad word) of the rest of the operation. In other words, it's a judgment call. That being said, Rich and Jon are dead on, Valid Handle is way expensive. I keep a ValidHandle and a ValidHandleSafe that I choose among - ValidHandle has the HandleZone routine #ifdef DEBUG'd out. -Ivan - -- Ivan Cavero Belaunde (ivan_cavero_belaunde@avid.com) Avid VideoShop Lead Avid Technology, Inc. Disclaimer: All views expressed are entirely my own and do not reflect the opinions of Avid Technology, Inc. +++++++++++++++++++++++++++ >From besbris@jeeves.ucsd.edu (David Besbris) Date: 15 Sep 1994 17:40:51 GMT Organization: University of California at San Diego I usually do append stuff to the windowptr, but if you want to be REALLY anal... You can keep your own linked list of your window like: Type NodePtr = ^ NodeRec; NodeRec = record of AWindow : WindowPtr; MyData : Handle; Link : NodePtr; end; And then when you want to know if a window is yours just search the list to get your data. The overhead of this is really quite small, and it can insulate you from all of the worries of using the refcons or appending data directly to a structure that you pass to the system. My 2 cents, Dave besbris@jeeves.ucsd.edu --------------------------- >From westwig@msc.cornell.edu (Erik Anton Westwig) Subject: Dialogs and (de)activate events Date: Wed, 14 Sep 1994 11:54:07 -0500 Organization: Cornell University Here's a HIG type question for 'ya The frontmost window has some active text in it. The user then does something to bring up a dialog. When should I deactivate the text? I looked at ThinkC 5 and it wasn't even consistent with itself: 1. if you bring up the About ThinkC box with text selected in the editor, it WILL NOT deselect the text. 2. But if you choose New in the File Menu, it WILL deselect it. I then looked at TeachText which I figured would follow whatever Apple wanted programmers to do, and it didn't deselect the text when a dialog was brought up. This seems backwards to me, since in other parts of IM vol I, it tells you explicitly to deselect text when a window is not in the front. So which is it (and why)? Also since you aren't going to receive a deactivate event in your app when you use a Modal dialog, you will need to call the whatever deactivation routin within your dialog routine (right?). Is this different for a modless box? Thanks for the advice, ERIK -- "IT's over to you..." +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 14 Sep 1994 21:29:25 GMT Organization: Apple Computer Erik Anton Westwig, westwig@msc.cornell.edu writes: > The frontmost window has some active text in it. > The user then does something to bring up a dialog. > When should I deactivate the text? Always. You should disable the active window when a dialog appears and re-enable it when it goes away. It takes a little bit of extra effort to do this, and apps are pretty inconsistent about doing it. Note that if the dialog applies to the current selection, you may want to display a "dimmed" selection when the window is inactive, so the user can still tell what area is selected. > Also since you aren't going to receive a deactivate event in your app when > you > use a Modal dialog, you will need to call the whatever deactivation routin > within your dialog routine (right?). Is this different for a modless box? You do actually get a deactivate event, but the modal dialog ignores it by default because it doesn't know diddly about your document windows. To get the event yourself, use a modal dialog filter and watch for activate events. When you get one for a document window, do the right thing. This also applies to update events; that way your document windows will still update while there is a dialog up (let's say a screen saver kicked in...) --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From bb@lightside.com (Bob Bradley) Date: Tue, 13 Sep 1994 05:23:23 -0800 Organization: SS Software Inc. In article , westwig@msc.cornell.edu (Erik Anton Westwig) wrote: > Here's a HIG type question for 'ya > > The frontmost window has some active text in it. > The user then does something to bring up a dialog. > > When should I deactivate the text? I always thought it was stupid that calling StandardGetFile wouldn't generate an activate event for the window it's coming in front of and even worse, it's inconsistant, since the window itself (the part the window manager handles for you) is deactivated (ie. the drag region is changed to inactivate state) but, a deactivate event isn't generated. What I do is isolate all my activate/deactivate code into a single HandleActivate routine that will normally be called when I receive an activate event. Then if I'm going to put up a dialog (like StandardFile) that doesn't generate an activate event, I'll manually call HandleActivate for that frontmost window (since it's the only one that would be active). For your own dialogs, calling ShowWindow before calling ModalDialog should generate the deactivate event for the previous frontmost window. --------------------------- >From mmah@alias.com (Ming Mah) Subject: Lets talk OpenDoc Date: Thu, 18 Aug 1994 14:28:06 GMT Organization: Alias Research Inc., Toronto ON Canada Hi gang, I have not seen a discussion thread about OpenDoc, and I wanted to start one up with some initial impressions that I had. I saw the discussion about OLE being bundled in the August issue of MacTech, and I went to pick it up. I also read about being able to get a copy of the OpenDoc alpha CD by sending some mail to OPENDOC@applelink.apple.com, and so I did that as well (and I have to say I am really impressed with Apple in that regards. I sent out my request on Friday, and by Tuesday I had received the OpenDoc CD ... with all the discussion about getting the CD (I know, it branched off into a general tirade about Apple's SDK policies) I have to say this was VERY impressive). Any ways, on to what I wanted to say. I first installed the OLE stuff, and tried to play around with the sample applications that were included, and I have to admit that I was really confused about just what Microsoft was trying to show, and how to go about doing anything useful at all. After exploring the CD a bit, I came across an 'OLE vs. OpenDoc' discussion, and things were pretty much downhill from there. The document has tons of (I think) uncalled for jabs at OpenDoc, and a lot of defensiveness about design differences between the two technologies. The impression I had with OLE is that it is an enabling technology to allow for document centric inter-application communications. I could not get a very nice feel for "in-place" editting as the few things I tried (an Excel spreadsheet, and embedding a QuickTime movie) both ended up launching seperate applications (Excel and a QuickTime movie player). In order to even play the movie, I had to switch over to another application to get it started, although once started it did play within my document. OpenDoc though seems to be a tremendous leap forward with the Macintosh "user experience" (I have come to REALLY like that phrase). OpenDoc is layered on top of Drag-and-drop and shared libraries (although apparently the shared library stuff will go away). The OpenDoc application itself is only 20K !! Viewing and editing "parts" is very intuitive (well almost, I did have to dig a little bit to find out about pressing command to move a part around, as opposed to activating it). And the interaction with the Finder was really nice. All part editing happened within the document, and it was kind of neat to see the menus switching as I went from part to part. A QuickTime movie is embedded by opening a QuickTime part editor (which does not seem "right" to me), but the movie itself was embedded directly in my document, and playing the movie is done by activating the badge. Back to the 'OLE vs. OpenDoc' discussion on the OLE CD. OLE seems to me to be just a protocol for inter-application communications (I know "just" is a rather harsh and over-simple word), whereas OpenDoc encompasses a lot more than that. OpenDoc is tightly integrated within the Macintosh experience (again, it was just "right" to drag a piece of text to the trash, and have it removed from my document), and is a well thought out extension to it. OpenDoc also includes some really neat file support tools, especially the draft version-ability. I thought that it again just shows a lot of thought and attention to what users want to do with a document. Well, these were just my first impressions, and if you have not already, I would urge you to take a look at both technologies (especially since they can be gotten for almost free (OpenDoc IS free)). I am starting to feel realy warm and fuzzy with OpenDoc, and I would be interested in continued discussions about OpenDoc part development. Have fun. Ming +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: 18 Aug 1994 22:15:21 GMT Organization: The Information Workshop Ming, I had the exact same identical experience, and assessment, as you did. Microsoft may have put the stuff in our hands NOW, and for FREE, but I could not make heads or tails of where to start to dive in. There was no read-me that was the big arrow pointing to "Start Here". A fatal mistake. Also, the "OpenDoc vs. OLE: Information for Customers" thing was filled with unprofessional "jabs" as you rightly called them, and this makes it obvious that a certain entity feels a little insecure, and will resort to mud-slinging, since there must be little to point to which can stand on its own. Hmmmmm. Mark Hanrek The Information Workshop +++++++++++++++++++++++++++ >From rob@eats.com (Rob Newberry) Date: Thu, 18 Aug 1994 18:34:34 UNDEFINED Organization: Education and Technology Solutions >Microsoft may have put the stuff in our hands NOW, and for FREE, but I >could not make heads or tails of where to start to dive in. There was no >read-me that was the big arrow pointing to "Start Here". A fatal >mistake. My goodness. You get a free bunch of code, and you want someone to step you through the whole thing too? Come on! If you want to learn about the OLE stuff on the CD, take a look at the Microsoft Press book, "Inside OLE 2". It is primarily Windows-oriented, but the OLE code is (FTMP) well explained and portable. >Also, the "OpenDoc vs. OLE: Information for Customers" thing was filled >with unprofessional "jabs" as you rightly called them, and this makes it >obvious that a certain entity feels a little insecure, and will resort to >mud-slinging, since there must be little to point to which can stand on >its own. Didn't read it. I'm not surprised, though... Rob +++++++++++++++++++++++++++ >From nick+@pitt.edu ( nick.c ) Date: Thu, 18 Aug 94 23:19:42 GMT Organization: The Pitt, Chemistry In Article , hanrek@cts.com (Mark Hanrek) wrote: >Microsoft may have put the stuff in our hands NOW, and for FREE, but I >could not make heads or tails of where to start to dive in. There was no For what it's worth, Apple will put OpenDoc in your hands now and free too. After the initial flurry regarding the MacTech distribution of OLE, I responded to Tre's suggestion that anyone who was interested could get the equivalent OpenDoc SDK. Just got the package today, and it's in Alpha release - and I sure haven't figured out enough to comment on the superiority of one or the other. But the take home lesson is the resources exist to start working on either standard today, and at no cost. Figure I'll be doing a little reading tonight :-). -- nick Disclaimer: Just my opinion. _/ _/ _/ _/_/_/ _/ _/ Interet: nick@pitt.edu _/_/ _/ _/ _/ _/ _/_/_/ eWorld: nick _/ _/_/ _/ _/ _/ _/ CIS: 71232,766 _/ _/ _/ _/_/_/ _/ _/ "Science is nothing but perception" - Plato +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 18 Aug 94 23:22:13 MST Organization: (none) In article , hanrek@cts.com (Mark Hanrek) writes: > Ming, > > I had the exact same identical experience, and assessment, as you did. > > Microsoft may have put the stuff in our hands NOW, and for FREE, but I > could not make heads or tails of where to start to dive in. There was no > read-me that was the big arrow pointing to "Start Here". A fatal > mistake. > > Also, the "OpenDoc vs. OLE: Information for Customers" thing was filled > with unprofessional "jabs" as you rightly called them, and this makes it > obvious that a certain entity feels a little insecure, and will resort to > mud-slinging, since there must be little to point to which can stand on > its own. > > Hmmmmm. What I found fasckinatin was the review/comparison given in MacTech Journal. I noted a certain assumption that everyone must use C++ and that all vendors must use the same object format and that the overall feel of OLE vs OpenDOc was a tie as far as H-I concerns were concerned, etc. Even though I'm not competent to refute any of his observations, I felt that the tone of the article was "Microsoft paid me to write this and so I'm putting it in the best possible light." Anyone else get this feeling? Lawson +++++++++++++++++++++++++++ >From Ken Prehoda Date: 19 Aug 1994 16:57:26 GMT Organization: Univ of Wisc-Madison In article <1994Aug18.232213@west.cscwc.pima.edu> , 103t_english@west.cscwc.pima.edu writes: >Even though I'm not competent to refute any of his observations, I felt that >the tone of the article was "Microsoft paid me to write this and so I'm putting >it in the best possible light." > > >Anyone else get this feeling? I got the same feeling. I was definitely surprised at the authors SOM-bashing. I am not that familiar with SOM but have heard good things. The author of the MacTech article made it sound as if SOM was completely unacceptable. Are there any unbiased opinions on SOM vs. COM? -Ken Prehoda kenp@nmrfam.wisc.edu +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Fri, 19 Aug 1994 22:27:21 +0200 Organization: Royal Institute of Something or other In article <1994Aug18.232213@west.cscwc.pima.edu>, 103t_english@west.cscwc.pima.edu wrote: >I noted a certain assumption that everyone must use C++ and that all vendors >must use the same object format Uh, not under OpenDoc you don't have to. OpenDoc will layer on top of SOM, which is language neutral and even provides network transparency in DSOM. However, the current _ALPHA_ release uses the ASLM which demands either MPW C++ _or_ SC++ for MPW for the entire build. >and that the overall feel of OLE vs OpenDOc was >a tie as far as H-I concerns were concerned, etc. Simply not true, as anyone who has tried to create and edit a composite document in OLE 2 versus OpenDoc will tell you. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden "TextEdit does everything right." ‹ Jon W{tte +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Fri, 19 Aug 1994 22:27:23 +0200 Organization: Royal Institute of Something or other In article , rob@eats.com (Rob Newberry) wrote: >My goodness. You get a free bunch of code, and you want someone to step you >through the whole thing too? Come on! You DO get that on the OpenDoc CD. It has lots of useful recepies for various things, and also comes with PartMaker, which generates a part shell for you which you can extend. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden "TextEdit does everything right." ‹ Jon W{tte +++++++++++++++++++++++++++ >From mmah@alias.com (Ming Mah) Date: Fri, 19 Aug 1994 21:08:23 GMT Organization: Alias Research, Inc., Toronto ON Canada In <1994Aug18.232213@west.cscwc.pima.edu> 103t_english@west.cscwc.pima.edu writes: >What I found fasckinatin was the review/comparison given in MacTech Journal. >I noted a certain assumption that everyone must use C++ and that all vendors >must use the same object format and that the overall feel of OLE vs OpenDOc was >a tie as far as H-I concerns were concerned, etc. >Even though I'm not competent to refute any of his observations, I felt that >the tone of the article was "Microsoft paid me to write this and so I'm putting >it in the best possible light." >Anyone else get this feeling? >Lawson Hi Lawson, Yes, that was the same feeling I had. In terms of H-I, OpenDoc is really easy to use, and feels very natural (although A LOT of this has to do with drag-and-drop). Editing in place feels really nice with OpenDoc, and although it may have been just that OLE was not set up with workable demos, launching Excel to edit a spreadsheet somehow just does not feel the same. A major "argument" that I saw in the MacTech review was the underlying support architecture, and the way OpenDoc's SOM was described sounded really intimidating to me. Now currently the OpenDoc Alpha uses Shared Libraries (which I do not know how to create either), and PartMaker creates all the necessary configuration files (including make files and such) so I would suspect that when OpenDoc goes SOM that the same thing would happen. I am sure that if someone HAD to get down and dirty that SOM-ness (or whatever) could be scary, but so far (and I have a very simple part running after only playing around for two days) I have NOT run into any difficulties at all, let alone any of the nature that were speculated upon in the review article. The review does feel really very much as if it was written by Microsoft, and not by someone who has used OpenDoc much (if at all !!). I still really feel that the document structure file support (for things like drafts and mostly transparent access to drag-and-drop and links) is a cool feature of OpenDoc way beyond a simple IAC interface. Have fun. Ming +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Sat, 20 Aug 1994 04:44:10 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) 103t_english@west.cscwc.pima.edu writes: >What I found fasckinatin was the review/comparison given in MacTech Journal. >I noted a certain assumption that everyone must use C++ and that all vendors >must use the same object format and that the overall feel of OLE vs OpenDOc was >a tie as far as H-I concerns were concerned, etc. >Even though I'm not competent to refute any of his observations, I felt that >the tone of the article was "Microsoft paid me to write this and so I'm putting >it in the best possible light." >Anyone else get this feeling? I didn't get that feeling. The Microsoft position is much stronger, and can be found in "White Papers:Point CounterPoint" on the OLE CD-ROM. OLE is definitely C++ oriented; it knows about C++ vtables. OpenDoc bought into IBM's System Object Model, which is language-neutral, sort of. The languages have to know about SOM, or at least it works better if they do. A more fundamental problem is that all this machinery exists mostly so you can embed different documents in your word processor and still edit them with appropriate tools. It's sort of "Publish and Subscribe, The Next Generation". Yes, you can do other stuff, but the touted advantage is mostly for integrated documents. It's all focused on what documents look like, not what they mean. Is that really worth all this complexity? John Nagle +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 20 Aug 94 00:50:01 MST Organization: (none) In article , nagle@netcom.com (John Nagle) writes: > 103t_english@west.cscwc.pima.edu writes: >>What I found fasckinatin was the review/comparison given in MacTech Journal. >>I noted a certain assumption that everyone must use C++ and that all vendors >>must use the same object format and that the overall feel of OLE vs OpenDOc was >>a tie as far as H-I concerns were concerned, etc. > >>Even though I'm not competent to refute any of his observations, I felt that >>the tone of the article was "Microsoft paid me to write this and so I'm putting >>it in the best possible light." >>Anyone else get this feeling? > > I didn't get that feeling. The Microsoft position is much stronger, > and can be found in "White Papers:Point CounterPoint" on the OLE CD-ROM. > > OLE is definitely C++ oriented; it knows about C++ vtables. > OpenDoc bought into IBM's System Object Model, which is language-neutral, > sort of. The languages have to know about SOM, or at least it works > better if they do. > > A more fundamental problem is that all this machinery exists mostly > so you can embed different documents in your word processor and still > edit them with appropriate tools. It's sort of "Publish and Subscribe, > The Next Generation". Yes, you can do other stuff, but the touted > advantage is mostly for integrated documents. It's all focused on > what documents look like, not what they mean. Is that really worth all > this complexity? > > John Nagle So, is the complexity for the programmer or for the user, and just who is more important? Lawson +++++++++++++++++++++++++++ >From philip@cs.uct.ac.za (Philip Machanick) Date: 20 Aug 1994 14:40:56 +0200 Organization: Computer Science Department, University of Cape Town Ming Mah (mmah@alias.com) wrote: : I saw the discussion about OLE being bundled in the August issue : of MacTech, and I went to pick it up. I also read about being able : to get a copy of the OpenDoc alpha CD by sending some mail to : OPENDOC@applelink.apple.com, and so I did that as well (and I have : to say I am really impressed with Apple in that regards. I sent : out my request on Friday, and by Tuesday I had received the OpenDoc Took a little longer in my case, but I am on a different continent and they sent it DHL at their expense. I haven't seen the OLE CD yet - if anyone wants to get rid of theirs, let me know (I don't mind if you can't afford DHL :). If so please send mail to philipm@is.co.za - my regular mail server is broken. : CD ... with all the discussion about getting the CD (I know, it : branched off into a general tirade about Apple's SDK policies) I : have to say this was VERY impressive). [...] : Back to the 'OLE vs. OpenDoc' discussion on the OLE CD. OLE seems to : me to be just a protocol for inter-application communications (I know : "just" is a rather harsh and over-simple word), whereas OpenDoc : encompasses a lot more than that. OpenDoc is tightly integrated within : the Macintosh experience (again, it was just "right" to drag a piece : of text to the trash, and have it removed from my document), and is : a well thought out extension to it. I wonder what there is in it for Microsoft to wholeheartedly embrace the concept of lots of small plug and play editors. Microsoft relies on selling big bloated apps for income. Apple has always been a paradigm-shift company - even if they sometimes forget this - whereas Microsoft is a kludge-shift company. Apple has an inherent need to push new ways of doing things as a selling point for a minority platform. Microsoft has to please conservative managers by pretending they aren't changing the way things are done, just covering corporate asses by filling out the feature list as fully as possible. This leads to gigantic monolithic apps. It's hard to see how MS Word, Excel etc. fit into a document centric world. That's partly why I would like to check out the OLE CD. Is it really document centric - or is it just a way of embedding pieces of other apps' documents in one app's documents? -- Philip Machanick philip@cs.wits.ac.za Computer Science Department, University of he Witwatesrand 2050 Wits, South Africa 27(11)716-3309 fax 339-7965 (at University of Cape Town until November: 27(21)650-4058) +++++++++++++++++++++++++++ >From sandvik@apple.com (Kent Sandvik) Date: Sat, 20 Aug 1994 19:16:32 GMT Organization: Dr. Stupid Meets Frankenstein In article <334tko$jjq@cs.uct.ac.za> philip@cs.uct.ac.za (Philip Machanick) writes: > Apple has always been a paradigm-shift company - even if they > sometimes forget this - whereas Microsoft is a kludge-shift > company. Apple has an inherent need to push new ways of doing things > as a selling point for a minority platform. Microsoft has to please > conservative managers by pretending they aren't changing the way > things are done, just covering corporate asses by filling out the > feature list as fully as possible. This leads to gigantic monolithic > apps. It's hard to see how MS Word, Excel etc. fit into a > document centric world. > > That's partly why I would like to check out the OLE CD. Is it > really document centric - or is it just a way of embedding > pieces of other apps' documents in one app's documents? You are on the right track, a lot of the OLE versus OpenDoc has to do with techno-political, strategic games. Microsoft would not like to loose the lucrative market of selling base applications to office environments. Imagine a future where anyone could buy cheaper components and put together their favourite environment. The content is the content, and the tools are the tools. There will of course be a nice market for companies that bundle part handlers so the end result is indeed a classical application. However Microsoft would no longer have full control of their base line application offerings, and that's something they don't want to loose. Thus their technical drive behind OLE is more to make sure that applications offer OLE support, and of course their applications are the prime OLE engines. Think about this next time you read technical blurbs from Microsoft about OLE. Anyway, private comments. I would rather see a world where all kinds of companies are allowed to compete on the application arena, instead of having one single big company dictate the rules. Cheers, Kent Kent Sandvik, Apple Computer Inc. sandvik@apple.com --Private activities on the net -- +++++++++++++++++++++++++++ >From michael@elwing.otago.ac.nz (Michael(tm) Hamel) Date: Sat, 20 Aug 1994 21:06:17 GMT Organization: University of Otago 103t_english@west.cscwc.pima.edu wrote: > I noted a certain assumption that everyone must use C++ and that all vendors > must use the same object format and that the overall feel of OLE vs OpenDOc was > a tie as far as H-I concerns were concerned, etc. What really gets me about OpenDoc is that its another factor thats going to push my company off the Macintosh. We have a substantial code base written in Object Pascal. Apple are saying to us, "Hey, rewrite everything in C++ in this entirely different way and thats the future". The trouble is, thats exactly the effort required to put us on Windows. Now, I believe, and I'm sure you'll agree, that moving to OpenDoc would be a much "nicer" thing to do and would produce a better user experience, etc. But it requires us to trust the Apple who brought us MacApp and BedRock with an awfully similar-looking exercise. And we just can't afford to do that. Maybe in twelve or eighteen months it will be clearer that we can, but we may have to commit ourselves before then. To Windows. -- Michael(tm) Hamel ADInstruments, Dunedin, New Zealand michael@otago.ac.nz "The Galaxy's a fun place. You'll need to have this fish in your ear." +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 20 Aug 94 16:51:02 MST Organization: (none) In article , michael@elwing.otago.ac.nz (Michael(tm) Hamel) writes: > 103t_english@west.cscwc.pima.edu wrote: > >> I noted a certain assumption that everyone must use C++ and that all vendors >> must use the same object format and that the overall feel of OLE vs OpenDOc was >> a tie as far as H-I concerns were concerned, etc. > > What really gets me about OpenDoc is that its another factor thats going to > push my company off the Macintosh. > > We have a substantial code base written in Object Pascal. Apple are saying to > us, "Hey, rewrite everything in C++ in this entirely different way and thats > the future". The trouble is, thats exactly the effort required to put us on > Windows. Now, I believe, and I'm sure you'll agree, that moving to OpenDoc > would be a much "nicer" thing to do and would produce a better user experience, > etc. But it requires us to trust the Apple who brought us MacApp and BedRock > with an awfully similar-looking exercise. And we just can't afford to do that. > Maybe in twelve or eighteen months it will be clearer that we can, but we may > have to commit ourselves before then. To Windows. > WHile I don't know that OpenDoc will work with Object Pascal, the fact that it is touted as more language-independent than OLE suggest that it should... Any OpenDoc gurus/designers lurking? Lawson +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: 21 Aug 1994 01:08:05 GMT Organization: The Information Workshop >> >> Mark Hanrek said... >> >> Microsoft may have put the stuff in our hands NOW, and for FREE, but I >> could not make heads or tails of where to start to dive in. There was no >> read-me that was the big arrow pointing to "Start Here". A fatal >> mistake. > In article , rob@eats.com (Rob Newberry) wrote: > > My goodness. You get a free bunch of code, and you want someone to step you > through the whole thing too? Come on! > Rob, Boy, you must not work in a business-oriented environment do you? This isn't a "guessing game" we're playing here. This is business. Time is money. We take the "path of least resistance" and work on a need-to-know basis. And a question business-oriented programmer find themselves asking is... Do you want us to use the technology or not? This is why I take advantage of every opportunity to put forth the recommendation that Apple, and any other company that wants programmers to use their technology and APIs, to take the well-known world of "user-interface" and "ease of use" and extend it to programmers, because programmers are humans too. - --- In a separate thread, we noted MacTech's success and praised them, and it was mentioned that "if a company cares about the customer, then everything else falls into place nicely". Likewise, if "programmer-interface" is recognized, and the principles of "programmer ease-of-use" are implemented, then everything falls into place nicely. It is a simple way to catch a myriad of things that slow programmers down which can easily be eliminated. This isn't about making things all nice and pretty and neat for sissy programmers. It has to do with making it so we can go in, do what we need to do, and get the hell out of there because we have to move on to 25 other issues and we don't have time to screw around being confused, being predisposed to making mistakes that have already been made, encountering bugs that have already been found, and asking the same questions over and over and over. - --- If someone at Microsoft had been paying attention to what was going on, they wouldn't have forgotten to "guide" the programmer interested in OLE, telling them to "start here, play with that, then get into this, then graduate to this other thing if you wish, and before you start, here is some perspective as to how all these things fit together". If someone there truly "cared" about the OLE CD being truly effective, they would have discovered this oversight. This kind of implies something... that this is what happens when you have a bunch of people trained to do only what they are told, and to not ask questions, or bother having any "ideas". :) I am glad I am aligned with Macintosh, and OpenDoc. Mark Hanrek The Information Workshop +++++++++++++++++++++++++++ >From neil_ticktin@xplain.com (Neil Ticktin) Date: Sun, 21 Aug 1994 03:42:37 GMT Organization: MacTech Magazine/Xplain Corporation In article <1994Aug18.232213@west.cscwc.pima.edu>, 103t_english@west.cscwc.pima.edu wrote: >> Even though I'm not competent to refute any of his observations, I felt that >> the tone of the article was "Microsoft paid me to write this and so I'm >> putting it in the best possible light." >> >> Anyone else get this feeling? Lawson, Rest assured that at the time of writing the article, Jeff Alger was independent from both Apple and Microsoft. In fact, we checked with both companies to see if Jeff was a "fair" choice before embarking on the article. Both gave their "ok". Jeff wrote an article that a lot of people agree with and a lot of people disagree with. The important thing is that Jeff worked with both sets of software just as any developer would and then wrote up his opinions. Jeff, as you know, liked OLE better. Why? Because he found it easier to work with and did not like SOM. Realize that Jeff's opinion on SOM is just that, an opinion. I personally don't agree with it from what I've heard, but I feel strongly that people are entitled to their opinion. Jeff's also spent more time working with the stuff than a lot of people have. Also realize that Jeff was working with whatever was available at the time. Documentation and tools for OpenDoc and OLE have been moving very quickly. The articles were written back in the June timeframe and things are much different already. Jeff based his comments on what he saw at that moment in time, not promises for the future. One last thing. Even though Jeff favored OLE, he took a bunch of jabs at it. Microsoft had enough respect for Jeff's comments that they've now offered him a job. They seem to be truly interested in making their product better. This all came to pass AFTER the article was published, let alone written. In the end, I believe that OpenDoc will win because the technology, I think, is cool and is better integrated. But, Microsoft is putting up one hell of a fight in the mean time. Our goal at MacTech was to put the technology and concepts in your hands. As a developer, the choice is up to you. Hope it was of help. Thanks, Neil Ticktin MacTech Magazine - --------------------------------------------------------------------- Neil Ticktin, MacTech Magazine (formerly MacTutor) PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: 310-575-0925 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain custservice@xplain.com * editorial@xplain.com * adsales@xplain.com marketing@xplain.com * accounting@xplain.com * pressreleases@xplain.com progchallenge@xplain.com * publisher@xplain.com * info@xplain.com +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Sun, 21 Aug 1994 15:06:39 +0800 Organization: Department of Computer Science, The University of Western Australia In article , michael@elwing.otago.ac.nz (Michael(tm) Hamel) wrote: >We have a substantial code base written in Object Pascal. Apple are saying to >us, "Hey, rewrite everything in C++ in this entirely different way and thats >the future". I disagree with this. SOM puts you in a much better position to support Pascal than any of the other technologies Apple is using (specifically ASLM). At least with SOM there's a hope of you being able to compile the IDL into Pascal. Everywhere else on the Mac the interfaces are written in C and then given to someone who doesn't know Pascal (and doesn't care IMHO) to port. With SOM you should be able to do the job yourself (and hence get it done well). btw This is all speculation from what I've read in OS/2 Developer magazine. I haven't actually got the OpenDoc CD. -- Quinn "The Eskimo!" "Support HAVOC!" Department of Computer Science, The University of Western Australia Who's sick and tired of Apple Pascal interfaces that won't even run through the bloody compiler! Negligence IMHO. +++++++++++++++++++++++++++ >From philip@cs.uct.ac.za (Philip Machanick) Date: 21 Aug 1994 11:07:22 +0200 Organization: Computer Science Department, University of Cape Town John Nagle (nagle@netcom.com) wrote: : A more fundamental problem is that all this machinery exists mostly : so you can embed different documents in your word processor and still : edit them with appropriate tools. It's sort of "Publish and Subscribe, : The Next Generation". Yes, you can do other stuff, but the touted : advantage is mostly for integrated documents. It's all focused on : what documents look like, not what they mean. Is that really worth all : this complexity? I think you miss the point. You can move away from a world of monolithic apps like word processors to generic apps in which you use your favourite editors. This is paradigm shift, not change of detail. Whether it will work or not is hard to say at this stage because of the potential for problems with managing a highly customizable world. Consider an example that is not word processing, like software development. Your major outer level document looks like a Think/CW project. It contains embedded documents that are source code, object code, resources etc. Each of these embedded objects has editors - which you can replace by other editors that have the right semantics, but maybe a different look and feel. Object code's editor would be a compiler with behaviours like bring up to date. The overall project document would also have an editor that would bring the whole project up to date. Take this a step further and embed this in a version control system - one more layer of document. Embed this in a documentation system and you've reinvented Knuth's Web. If this is done right, vast potential is opened up for restructuring the way you work around a document-centric view of the world. The biggest problem is that everyone is going to want to do it - and not everyone will have the necessary design skills. This is a brave new world that Apple is creating for us and it will revolutionise the way we work as much as the original Mac did. -- Philip Machanick philip@cs.wits.ac.za Computer Science Department, University of he Witwatesrand 2050 Wits, South Africa 27(11)716-3309 fax 339-7965 (at University of Cape Town until November: 27(21)650-4058) +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Sun, 21 Aug 1994 13:28:08 +0200 Organization: Royal Institute of Something or other In article , michael@elwing.otago.ac.nz (Michael(tm) Hamel) wrote: >What really gets me about OpenDoc is that its another factor thats going to >push my company off the Macintosh. Huh? No-one's forcing you to write for OpenDoc. The monolthic app approach will not die for several years yet. >We have a substantial code base written in Object Pascal. Apple are saying to >us, "Hey, rewrite everything in C++ in this entirely different way and thats >the future". The trouble is, thats exactly the effort required to put us on No, that's not what they're saying. You will have to re-structure your UI around the way OpenDoc delivers user interaction; true; and you will also have to re-write your saving code a bit, but OpenDoc is LANGUAGE NEUTRAL since it uses SOM. OLE, on the other hand, parses vtables, so it HAS to be written in C++. Maybe you're confusing the design of OpenDoc with the current alpha implementation, which does indeed temporarily require C++. >etc. But it requires us to trust the Apple who brought us MacApp and BedRock >with an awfully similar-looking exercise. And we just can't afford to do that. No. You have to trust CILabs. CILabs is sponsored by Apple, IBM, Novell, Word Perfect and lots of other people. Word Perfect is doing the Windows version of OpenDoc, and I hear the alpha is already out. Writing for OpenDoc really means writing for OpenDoc, not for a particular platform. There are of course platform-specific areas that need to be covered, but you can take your own cross-platform approach, or you can use an existing library (like the Open Parts Framework) Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Not speaking for IBM. +++++++++++++++++++++++++++ >From pchang@Xenon.Stanford.EDU (The Weasel) Date: 21 Aug 1994 16:05:16 GMT Organization: Computer Science Department, Stanford University. >Even though I'm not competent to refute any of his observations, I felt that >the tone of the article was "Microsoft paid me to write this and so I'm putting >it in the best possible light." Well, Jeff Alger does work for Microsoft now. I don't recall the articl ementioning this. Peter +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 21 Aug 94 15:55:16 MST Organization: (none) In article <337tvs$qkv@Times.Stanford.EDU>, pchang@Xenon.Stanford.EDU (The Weasel) writes: >>Even though I'm not competent to refute any of his observations, I felt that >>the tone of the article was "Microsoft paid me to write this and so I'm putting >>it in the best possible light." > > Well, Jeff Alger does work for Microsoft now. I don't recall the articl > ementioning this. > > Peter > > I got e-amil from the MacTech guy (another what'sisname) who says that Jeff A. was NOT working for MS when the article was published... Fair enough. However, one might wonder as to when Mr. Alger submitted his application to Microsoft (or did they approach him?), and did he hope that they would read his article in a favorable light, thereby being more likely to hire him. Interesting: via the Internet, we can establish possible motives for biased reporting that can be read and debated by thousands of interested folks. 20 years ago, we would probably be waiting for an expose from the newspapers which probably wouldn't be forthcoming in this case. Lawson +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Mon, 22 Aug 1994 01:50:25 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) philip@cs.uct.ac.za (Philip Machanick) writes: >John Nagle (nagle@netcom.com) wrote: >: A more fundamental problem is that all this machinery exists mostly >: so you can embed different documents in your word processor and still >: edit them with appropriate tools. It's sort of "Publish and Subscribe, >: The Next Generation". Yes, you can do other stuff, but the touted >: advantage is mostly for integrated documents. It's all focused on >: what documents look like, not what they mean. Is that really worth all >: this complexity? >I think you miss the point. You can move away from a world of monolithic >apps like word processors to generic apps in which you use your >favourite editors. This is paradigm shift, not change of detail. This assumes you want an editor/document centered world. There are other models, such as a database-centered world. For coordinating the work of multiple people, a database-centered world may be more appropriate. Whatever happened to Apple's SQL interface, anyway? It was in System 7, and optional in 7.1. Is it in 7.5 at all? I was hoping for more data-centered apps, and groupware based on databases. The MacTech article indicates that OpenDoc is weak on locking and networking. How does this editor/document model work for multiple users? John Nagle +++++++++++++++++++++++++++ >From sandvik@apple.com (Kent Sandvik) Date: Mon, 22 Aug 1994 03:07:52 GMT Organization: Dr. Stupid Meets Frankenstein In article michael@elwing.otago.ac.nz (Michael(tm) Hamel) writes: > We have a substantial code base written in Object Pascal. Apple are saying to > us, "Hey, rewrite everything in C++ in this entirely different way and thats > the future". The trouble is, thats exactly the effort required to put us on > Windows. Now, I believe, and I'm sure you'll agree, that moving to OpenDoc > would be a much "nicer" thing to do and would produce a better user experience, > etc. But it requires us to trust the Apple who brought us MacApp and BedRock > with an awfully similar-looking exercise. And we just can't afford to do that. > Maybe in twelve or eighteen months it will be clearer that we can, but we may > have to commit ourselves before then. To Windows. Hmm, I thought it was the other way around, OLE requires vtables and SOM used in OpenDoc is more language independent. I need to check this out. I think the reason some believe that OpenDoc is C++ centric is that it uses ASLM today, but that's transitory. As for Jeff A. writing the article, hehehe.... That explains the controversy. He's also involved in MFC training and consulting. Anyway, nobody's neutral in the computing wars. Where are the CORBRA followers, BTW? Cheers, Kent - - Kent Sandvik, sandvik@apple.com --Private activities on the net, not related to the company I work for -- +++++++++++++++++++++++++++ >From neil_ticktin@xplain.com (Neil Ticktin) Date: Mon, 22 Aug 1994 06:26:02 GMT Organization: MacTech Magazine/Xplain Corporation In article <337tvs$qkv@Times.Stanford.EDU>, pchang@Xenon.Stanford.EDU (The Weasel) wrote: >> >Even though I'm not competent to refute any of his observations, I felt that >> >the tone of the article was "Microsoft paid me to write this and so I'm putting >> >it in the best possible light." >> >> Well, Jeff Alger does work for Microsoft now. I don't recall the articl >> ementioning this. >> >> Peter Peter, I need to be perfectly clear here. Jeff was not in any way affiliated or discussing affiliation with Microsoft until AFTER the article was published. As I heard it, Microsoft was so impressed by the article, they asked him to join the company. See what writing for MacTech Magazine can do for your career? :) But again -- he was unbiased at the time he wrote the article and that is what is important. Thanks, Neil Ticktin MacTech Magazine - --------------------------------------------------------------------- Neil Ticktin, MacTech Magazine (formerly MacTutor) PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: 310-575-0925 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain custservice@xplain.com * editorial@xplain.com * adsales@xplain.com marketing@xplain.com * accounting@xplain.com * pressreleases@xplain.com progchallenge@xplain.com * publisher@xplain.com * info@xplain.com +++++++++++++++++++++++++++ >From philip@cs.uct.ac.za (Philip Machanick) Date: 21 Aug 1994 11:59:23 +0200 Organization: Computer Science Department, University of Cape Town Kent Sandvik (sandvik@apple.com) wrote: : In article <334tko$jjq@cs.uct.ac.za> : You are on the right track, a lot of the OLE versus OpenDoc has to do : with techno-political, strategic games. Microsoft would not like to : loose the lucrative market of selling base applications to office : environments. Imagine a future where anyone could buy cheaper : components and put together their favourite environment. The content is : the content, and the tools are the tools. : There will of course be a nice market for companies that bundle part : handlers so the end result is indeed a classical application. However : Microsoft would no longer have full control of their base line : application offerings, and that's something they don't want to loose. : Thus their technical drive behind OLE is more to make sure that : applications offer OLE support, and of course their applications are : the prime OLE engines. : Think about this next time you read technical blurbs from Microsoft : about OLE. Anyway, private comments. I would rather see a world where : all kinds of companies are allowed to compete on the application arena, : instead of having one single big company dictate the rules. I would still like to see more on OLE - even if I am on the right track without knowing anything :) Does MS have an ftp site or WW server with documentation? In 1987, I started thinking about Brad Cox's Software IC idea - reusable components written in a object-oriented language. His notion was that software should be sold in small reusable units, the way chips are sold. However, I felt that something was missing. Most people who add ICs (chips) to things like computers are not engineers who design the whole thing from board level up. What was really needed was the software analog of the printed circuit board (PCB), already populated with enough ICs to get you started. Something like a PC logic board, with RAM, FPU and other options left out - and slots for expansion. I considered various candidates for software PCBs among existing OO tools, and felt none of them provided enough support for plugging in components - they were more like the software equivalent of wire wrap prototypes. A true software PCB would have to define an infrastructure for adding components that would not only define default behaviours, like low-level printer protocols, but also ways for components to interact (the software analog of traces on the PCB, and hardware interaction protocols - voltage levels etc.). Components would have to define how they appeared on a page, shared space with neighouring objects, etc. Another idea I had was that everything should be a document - there shouldn't even be a separate file system. Viewing what's on your disk then becomes a special case of viewing contents of a document - and alternative views also become a natural concept. I dislike imposing a single hierarchy on the world, and by allowing alternative views of the "file system", it should be possible to navigate through your disk in a way natural to the task at hand. For example, group together everything created after a certain date, view everything related to a specific project etc. I also thought up the idea of thumbnail views - I felt something was needed between an icon and a full view of a document. I think it would be very interesting to put together an OpenDoc hierarchical browser similar to the Smalltalk browser, which would allow navigation of the file system according to a range of criteria (take the System 7 Find as a starting point). The lowest level of the browser would be a document - which you could start working on. One level up, names of everything that matched the search criteria, with the option of expanding to thumbnail views. Next level up, the search criteria. I don't claim all these ideas are original - though until OpeDoc appeared, I don't recall seeing them put together in this way. The way OpenDoc packages these concepts is a paradigm shift - it changes the way we thing about documents and applications - it is not just another kludge to make it easier to share information. I had a student do a protype software PCB in MacApp and tried to get a paper published on the subject, and guess what? A few of the referees were really taken with the idea, others said so what - everyone's doing this. (Something like the people who are now saying so what - OLE is almost the same as OpenDoc.) My prototype was not very complete - I didn't have a very good model of dynamic linking - but it was prossible in principle to paste in editors using ResEdit. I also didn't have all the machinery for communication between different kinds of objects (parts in OpenDoc terminology). I suppose I could have pushed the idea further but I moved on to other things. More recently, I saw an element of the idea in the way Claris Works integrated patches of other documents in a base document, though without the extensibility. It is interesting that a lot of the examples in the OpenDoc printed documentation come from Claris Works. Where does OpenDoc fit into this? A base OpenDoc collection of part handlers, ready to have more added to make a useful "application", is a software PCB. OpenDoc itself is more like a standard and set of tools for creating such PCBs - the software analogue of something like PReP. Any further thoughts on this? -- Philip Machanick philip@cs.wits.ac.za Computer Science Department, University of he Witwatesrand 2050 Wits, South Africa 27(11)716-3309 fax 339-7965 (at University of Cape Town until November: 27(21)650-4058) +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Mon, 22 Aug 1994 14:54:24 +0200 Organization: Royal Institute of Something or other In article , nagle@netcom.com (John Nagle) wrote: >Whatever happened to Apple's SQL interface, anyway? It was in >System 7, and optional in 7.1. Is it in 7.5 at all? I was hoping for >more data-centered apps, and groupware based on databases. It's undergone development; they now support ODBC alongside with DAL. ODBC is of course a Microsoft standard, but in this one case it seems Apple and Microsoft could agree on using the same technology... Of course, doing ODBC -> DAL tranlsation, talking to a DAL server that translates into native SQL, and then finally getting at the database isn't optimal, performance-wise. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden "Don't Deal with a Dragon." +++++++++++++++++++++++++++ >From sandvik@apple.com (Kent Sandvik) Date: Tue, 23 Aug 1994 00:41:13 GMT Organization: Dr. Stupid Meets Frankenstein In article <3378hr$mkp@cs.uct.ac.za> philip@cs.uct.ac.za (Philip Machanick) writes: > In 1987, I started thinking about Brad Cox's Software IC idea - > reusable components written in a object-oriented language. His notion > was that software should be sold in small reusable units, the way > chips are sold. Jacobson's book "Object Oriented Software Engineering" has a fairly good chapter describing all the problems why software reusable components never took off in the initial place. The latest Scientific American also has an article describing more about the implications. My terse comment is: "It's all in the culture, dammit". One tricky way to bypass such cases is to promote a frame into which people could write extensions, and promote the content rather than the functionality (Photoshop, Premier, OpenDoc...). Another example of a smart content container is QuickTime; it is defined, and it's up to developers to write applications and tools that reuse or create content (QT). Personally I think this is the way to do rather than forcing companies and developers to use pre-defined components that don't do the work required, and we are back on the hacking drawing board. And we should not lock ourselves to a particular computer language (style OLE and vtables). Anyway, personal and of course politically flavored comments :-). --Kent - - Kent Sandvik, sandvik@apple.com --Private activities on the net, not related to the company I work for -- +++++++++++++++++++++++++++ >From pathak@world.std.com (Heeren H Pathak) Date: Tue, 23 Aug 1994 13:26:19 GMT Organization: The World Public Access UNIX, Brookline, MA In article , John Nagle wrote: > This assumes you want an editor/document centered world. There >are other models, such as a database-centered world. For coordinating >the work of multiple people, a database-centered world may be more >appropriate. > Believe it or not this is where OpenDoc may really shine. Despite the blasting of SOM in Jeff Alger's article comparing OpenDoc vs OLE, SOM may be the the biggest "enabling " technology of OpenDoc. OpenDoc is really an object model on extending SOM. SOM is a technology for supporting distributed objects. This happens to be ideal for developing object components. SOM is based on a "industry standard" specification released by a consoritium called the Object Management Group. There are working groups in this consortia that are defining object models and frameworks for database systems, collaborative computing, transaction processing, etc... As these object models get defined, there is no technical reason they could not be adopted by CLI. In fact, CLI has been asked to submit OpenDoc as the "standard" for compound documents. The biggest danger in all of this is the "standard" will be too late. I believe this is a real risk. However, I think the OMG has a very early start on this technology and has plenty of time to get things done. Heeren Pathak +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 24 Aug 1994 00:39:33 GMT Organization: Apple Computer 103t_english@west.cscwc.pima.edu writes: > Even though I'm not competent to refute any of his observations, I felt that > the tone of the article was "Microsoft paid me to write this and so I'm putting > it in the best possible light." > Anyone else get this feeling? I'm obviously not unbiased in this, so I'll skip my own opinions of the article; but I can point out that since the publication of said article, the author has accepted a position at Microsoft. Draw your own conclusions. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From alger@netcom.com (Jeff Alger) Date: Thu, 25 Aug 1994 06:51:41 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) OK, I've had enough of this. If you want to disagree with my opinions, fine. I have yet to have anyone question items of fact in all of a 6000 word article which was submitted to both Microsoft and Apple for review before publication. I will say this once and only once because it isn't worth the trouble. Until becoming an employee of Microsoft last week, two months after the article was completed, I had never accepted a dime from Microsoft nor had any business relationship whatsoever, other than asking them for information as I would have Apple or any other vendor. I had no interest in getting a job with Microsoft or anyone else at the time of writing the article. Microsoft approached me AFTER the article was submitted to MacTech in final form. I find it highly doubtful that they would have been interested in hiring me if my integrity was for sale and I certainly would not have been interested in working for a company that would act in such an unethical way. At no time was any offer of money or employment made in connection with the article. There are many of you out there that have known me for many years within the Mac community - Chairman of MADA for two years, instructor at Apple's Developer University, author of a popular book on object-oriented development for the Mac, consultant, contributing editor to Frameworks, presenter at several WWDC's. My consulting practice has always been built on the highest degree of professionalism and integrity and yes, Kent, I have dealt with Windows, as well as Mac, mainframe, business process reengineering and any other problems my clents have needed help with. That is in part why I was chosen to write this article. Certainly that was known to Apple when they OK'd me as an independent reviewer of the two products. This sort of mud-slinging has no place in a professional forum. If any of you have a problem with my ethics, take it up directly with me; don't drop snide observations in a public forum. Those who know me can tell you that I will answer any and all questions honestly about my assumptions, methodology and motivations in writing the article. I can be reached either at this email address or at jeffal@microsoft.com. Regards, Jeff Alger Jens Alfke (jens_alfke@powertalk.apple.com) wrote: : 103t_english@west.cscwc.pima.edu writes: : > Even though I'm not competent to refute any of his observations, I felt : that : > the tone of the article was "Microsoft paid me to write this and so I'm : putting : > it in the best possible light." : > Anyone else get this feeling? : I'm obviously not unbiased in this, so I'll skip my own opinions of the : article; but I can point out that since the publication of said article, the : author has accepted a position at Microsoft. Draw your own conclusions. : --Jens Alfke jens_alfke@powertalk.apple.com : "A man, a plan, a yam, a can of Spam ... Bananama!" -- +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: 25 Aug 1994 21:08:03 GMT Organization: The Information Workshop > This sort of mud-slinging has no place in a professional forum. Here! Here! Everyone deserves respect, and the benefit of the doubt. Mark Hanrek The Information Workshop - -------------------------------------------------------------------- ( And y'all though I was going to point out that csmp is a newsgroup, not a forum, dintcha! :) >From eric.larson@f620.n2605.z1.fidonet.org (eric larson) Subject: Lets talk OpenDoc Date: 21 Aug 94 08:27:51 - Organization: FidoNet: Shockwave Rider, USR V.Everything +1(908)294-0659 > A more fundamental problem is that all this machinery exists mostly > so you can embed different documents in your word processor and still > edit them with appropriate tools. It's sort of "Publish and Subscribe, > The Next Generation". Yes, you can do other stuff, but the touted > advantage is mostly for integrated documents. It's all focused on > what documents look like, not what they mean. Is that really worth all > this complexity? One concern I have about this technology is what it is going to do to document portability. +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Mon, 29 Aug 1994 19:04:43 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) eric.larson@f620.n2605.z1.fidonet.org (eric larson) writes: Nagle wrote: > > A more fundamental problem is that all this machinery exists mostly > > so you can embed different documents in your word processor and still > > edit them with appropriate tools. It's sort of "Publish and Subscribe, > > The Next Generation". Yes, you can do other stuff, but the touted > > advantage is mostly for integrated documents. It's all focused on > > what documents look like, not what they mean. Is that really worth all > > this complexity? >One concern I have about this technology is what it is going to do to document >portability. Or long-term document integrity. Will you still be able to read your document a few years downstream, after all the applications have changed? And if you can't, which vendor do you call for help? And reading a document two decades hence may present real problems. John Nagle +++++++++++++++++++++++++++ >From E.J. Draper Date: 29 Aug 1994 20:29:43 GMT Organization: U.T.M.D. Anderson Cancer Center >> > edit them with appropriate tools. It's sort of "Publish and Subscribe, >> > The Next Generation". Yes, you can do other stuff, but the touted How many times a day do you use Publish and Subscribe? The one, and only, application I have for Publish and Subscribe technology is checking the amount of vacation hours I've got coming to me from the departmental spreadsheet. I use it once a week at the most, probably more like once a month. I can see some interesting applications of OpenDoc technology, but I certainly don't feel it's as mind-boggling awesome as the market-droids would have us think. What's OpenDoc going to do for me? Does a compiler part make sense? How about news reader part? An email part? A PIM part? A Resorcerer part? How does OpenDoc improve the way that people work with information? Does it make the computer more approachable to novice users? What specific problem is it trying to solve? It seems like the whole OpenDoc paradigm starts breaking down after you get past the Graphic+MooV+Text+Spreadsheet model. |E|J- ED DRAPER rEpar|D|<- Radiologic/Pathologic Institute The University of Texas M.D. Anderson Cancer Center draper@utmdacc.mda.uth.tmc.edu +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Tue, 30 Aug 1994 05:28:45 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) E.J. Draper writes: >It seems like the whole OpenDoc paradigm starts breaking down after you >get past the Graphic+MooV+Text+Spreadsheet model. I think he has a point. I can imagine a CAD system based on this approach, where you click on a subassembly to get to the detailed drawings. But that doesn't even fit the OpenDoc model, which is 2D, not 3D. What, besides embed stuff in word processor documents, is one really likely to do with OpenDoc? By the way, how does OpenDoc do version management? John Nagle +++++++++++++++++++++++++++ >From quinlan@kits.sfu.ca (Brian Quinlan) Date: 30 Aug 94 07:09:52 GMT Organization: Simon Fraser University E.J. Draper writes: >I can see some interesting applications of OpenDoc technology, but I >certainly don't feel it's as mind-boggling awesome as the market-droids >would have us think. What's OpenDoc going to do for me? Does a compiler >part make sense? How about news reader part? An email part? A PIM part? >A Resorcerer part? How does OpenDoc improve the way that people work >with information? Does it make the computer more approachable to novice >users? What specific problem is it trying to solve? You could build a development system by have a project manager as the base and compiler, interface builders, object browsers, debuggers and editors as parts. Notice that Symantic has a project manager and then calls the appropriate compiler and editor when they are needed. You could have a bases upon which you had a newreader, email and ftp parts. Anyone agree with this? +++++++++++++++++++++++++++ >From jdelkins@lilly.com (Joel D. Elkins) Date: Tue, 30 Aug 1994 09:39:27 -0600 Organization: NewMedia, Inc., Indianapolis, IN In article <33tgfn$r62@oac4.hsc.uth.tmc.edu>, E.J. Draper wrote: > I can see some interesting applications of OpenDoc technology, but I > certainly don't feel it's as mind-boggling awesome as the market-droids > would have us think. What's OpenDoc going to do for me? Does a compiler > part make sense? How about news reader part? An email part? A PIM part? > A Resorcerer part? How does OpenDoc improve the way that people work > with information? Does it make the computer more approachable to novice > users? What specific problem is it trying to solve? And what about client-server based apps, much in use by corporations today, for which the "document" paradigm really doesn't apply. Most of the c/s apps I've seen are more "forms" based. How will OpenDoc improve such apps? Unless it does, I don't see widespread acceptance by corporations for their in-house development efforts. -- Joel D. Elkins, N5USU | NewMedia, Inc. JDElkins@lilly.com | Indianapolis, IN +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Tue, 30 Aug 1994 12:47:01 -0500 Organization: One Step Beyond jdelkins@lilly.com (Joel D. Elkins) wrote: ) And what about client-server based apps, much in use by corporations ) today, for which the "document" paradigm really doesn't apply. Most of ) the c/s apps I've seen are more "forms" based. How will OpenDoc improve ) such apps? Unless it does, I don't see widespread acceptance by ) corporations for their in-house development efforts. While Apple has emphasised the user interface portion of OpenDoc, the "document-centered" model, from my conversations with one of the OpenDoc developers at the last MacWorld expo, I firmly beleive that OpenDoc's flexible architecture will help corporate developers a great deal. Aside... Q: What is the difference between a "form" and a "document"? A: A form only has 1 page, but document's have a lot! :-) A couple of, not widely talked about, components are integrall here. The first is the name space management feature. I guess this is part of SOM, but OpenDoc gives you an architecture to wrap your mind around. With name space management, you could register a "analysis engine" part on one machine, and have documents on another machine access it to perform the analysis. Other parts that could/are being developed include hooks for retreiving data from SQL databases, intelligent report writing, etc. Another problem that OpenDoc will eventually help solve is the dreaded "why can't XYZ app do what Excel does?" How many times have you, as a in house developer, written a software package only to have the users come back asking for features that are found in other commercial packages? It may be obvious to us that adding these frills would take too much time and cost too much, but it's not obvious to the users. By encouraging more vendors to implement a wide variety of parts that can interoperate together easily, we'll be able to add these frills at minimal cost. Personally, I think that OpenDoc could make the creation of special purpose software much easier and much more enjoyable. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From lentz@rossi.astro.nwu.edu (Robert Lentz) Date: 30 Aug 1994 16:45:54 GMT Organization: Northwestern University, Evanston, Illinois, USA In article <33tgfn$r62@oac4.hsc.uth.tmc.edu>, E.J. Draper wrote: >... >It seems like the whole OpenDoc paradigm starts breaking down after you >get past the Graphic+MooV+Text+Spreadsheet model. Well, that covers all the basic types which other applications use too. Let's see: newsreader using a text part for composing messages, same with mail program; perhaps sometimes using a WWW part for displaying HTML documents, which then uses the text part and any necessary graphics parts again... I think it could go far. -Robert -- lentz@rossi.astro.nwu.edu http://www.astro.nwu.edu/lentz/plan.html "You have to push as hard as the age that pushes against you." -Flannery O'Connor +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Tue, 30 Aug 1994 16:40:42 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) quinlan@kits.sfu.ca (Brian Quinlan) writes: >You could build a development system by have a project manager as the >base and compiler, interface builders, object browsers, debuggers and >editors as parts. Notice that Symantic has a project manager and then >calls the appropriate compiler and editor when they are needed. The whole development environment shouldn't be a structured document, but source programs might be. Programs today have parts which are visual and parts which are textual, and those parts need to be better connected. HyperCard already does this. >You could have a basis upon which you had a newsreader, email and ftp parts. You could, but why would you want to embed those functions in a structured document? A document is the wrong metaphor for that collection of functions. There's no content in which you're embedding those functions. A multiwindow application is more appropriate. An OpenDoc or OLE-based creation system for multimedia content would make sense, but that's an extension of the word processor metaphor. The whole multi-source document concept is useful, but only for things that naturally have a document metaphor. John Nagle +++++++++++++++++++++++++++ >From susser@apple.com (Joshua Susser) Date: Tue, 30 Aug 1994 17:29:47 GMT Organization: Apple Computer - AppleSoft I'm going to try to respond to several issues raised in this thread, to keep the branching factor down. I don't usually have time to do this, but since I do, here goes... eric.larson@f620.n2605.z1.fidonet.org (eric larson) writes: > One concern I have about this technology is what it is going to do to > document portability. If anything, OpenDoc should make your documents MORE portable. OpenDoc documents will be binary-compatible across all supported platforms. Our acid test is being able to open a document on a server from a Mac and a Windows machine at the same time, which you should be able to do when we ship. nagle@netcom.com (John Nagle) wrote: > Or long-term document integrity. Will you still be able to read > your document a few years downstream, after all the applications have > changed? And if you can't, which vendor do you call for help? > > And reading a document two decades hence may present real problems. I already have this problem. Some documents I have that are only 3 or 4 years old are suddenly non-readable, because their applications won't run on current software, or whatever. But we have factored the architecture so that if you don't have an editor for one kind of part in your document, you can still open the document and edit the other parts for which you do have editors. We also encourage developers to store their parts in multiple formats, so that if you don't have an editor for one format, you may for another. I have no idea what the world will be like in 20 years, and neither do you. I doubt anyone will be using anything as mundane as compound documents by then, so don't worry about it. :-) nagle@netcom.com (John Nagle) wrote: > E.J. Draper writes: > >It seems like the whole OpenDoc paradigm starts breaking down after you > >get past the Graphic+MooV+Text+Spreadsheet model. > > I think he has a point. I can imagine a CAD system based on this > approach, where you click on a subassembly to get to the detailed drawings. > But that doesn't even fit the OpenDoc model, which is 2D, not 3D. > What, besides embed stuff in word processor documents, is one really likely > to do with OpenDoc? OpenDoc windows and layout objects are 2D, because that's the dimensionality of the imaging devices available today (for the most part). But we did leave enough room in the API to support 3D parts. It should in fact be possible to embed a text part onto the surface of a 3D sphere part. But even without 3D, OpenDoc is suitable for much more than just a "Graphic+MooV+Text+Spreadsheet" kind of document. See below. > By the way, how does OpenDoc do version management? OpenDoc documents provide a facility for creating a named revision of your document called a "draft". Each draft is basically a checkpoint of the state of the document. You can create a new draft at any time, have as many as you like, open old drafts to compare to newer, etc. Using Bento, we can store each draft as a delta on the state of the previous draft, so we don't double the size of a document to add a second draft. There's lots more about drafts, but you can read the documentation for that. jdelkins@lilly.com (Joel D. Elkins) wrote: > And what about client-server based apps, much in use by corporations today, > for which the "document" paradigm really doesn't apply. Most of > the c/s apps I've seen are more "forms" based. How will OpenDoc improve > such apps? Unless it does, I don't see widespread acceptance by corporations > for their in-house development efforts. Actually, OpenDoc has a great story for in-house MIS types. They have two big desires - being able to use COTS (Commercial Off The Shelf) Software, and getting a vertical solution for their special needs. Notice these two desires are in direct conflict. But with component technology like OpenDoc, you can buy a set of COTS part editors and maybe only have to write one or two special purpose ones in house. Then create standard stationery using these chosen editors, write some scripts to integrate the parts functionality, and presto, it's an instant vertical application, custom made for your department with mostly COTS components. As for client-server, OpenDoc supports the concept of what we've been calling an "embedded client". Create a part editor that can operate as a client for a remote server. Now you have client parts that you can embed in your document anywhere you'd like. The state of the part is the query rule plus some cached information about the results of the last query. When you open the document, push a button, or whatever, the part queries the server and then displays the results of the query as its contents. I saw a demo yesterday of just such a client part editor written by Oracle (it's a demo, not a future product). You could even link a chart part to data returned by a query. Apparently this is even more powerful than current solutions, as it is much easier to have a document ("solution") that interacts with many databases - just create a part for each one. Other kinds of embedded clients are easily possible. Imagine a stock ticker part that gave running price quotes on your 10 favorite stocks. Link this to a spreadsheet part to help you compute the net value of your portfolio. A good rule of thumb for what could and should be written as a part editor is: "If it has a user interface, it should be a part." Well, my compile is done, so back to work... Joshua Susser, Object Contortionist Apple Computer - AppleSoft, OpenDoc Engineering inet: susser@apple.com | link: susser.j | phone: 408/974-6997 +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Tue, 30 Aug 1994 20:33:09 +0200 Organization: Royal Institute of Something or other In article <33tgfn$r62@oac4.hsc.uth.tmc.edu>, E.J. Draper wrote: >would have us think. What's OpenDoc going to do for me? Does a compiler >part make sense? Yes; or rather; an IDE is a collection of parts like an editor part, a code generator part, a project file part, ... >How about news reader part? That's also a collection of an editor part, a news collection part, ... >An email part? See above. >users? What specific problem is it trying to solve? Read the OpenDoc white paper. A simple example: Your news reader comes with the SimpleText text edittig part. Unfortunately, this part does not handle parts larger than 32k, so to decode alt.binaries.pictures.erotica.jello, you instead use the Alpha text editting part which handles larger documents, and write a small script that scans the news collection part for multi-part postings, uses Alpha to concatenate them, uses the StuffIt mangling part to get an image which you display in the JPEGView picture display part. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Reality exists only in your imagination. +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 30 Aug 94 11:18:38 MST Organization: (none) In article , nagle@netcom.com (John Nagle) writes: > quinlan@kits.sfu.ca (Brian Quinlan) writes: >>You could build a development system by have a project manager as the >>base and compiler, interface builders, object browsers, debuggers and >>editors as parts. Notice that Symantic has a project manager and then >>calls the appropriate compiler and editor when they are needed. > The whole development environment shouldn't be a structured document, > but source programs might be. Programs today have parts which are visual > and parts which are textual, and those parts need to be better connected. > HyperCard already does this. > >>You could have a basis upon which you had a newsreader, email and ftp parts. > You could, but why would you want to embed those functions in a > structured document? A document is the wrong metaphor for that collection > of functions. There's no content in which you're embedding those > functions. A multiwindow application is more appropriate. > > An OpenDoc or OLE-based creation system for multimedia content > would make sense, but that's an extension of the word processor metaphor. > > The whole multi-source document concept is useful, but only for things > that naturally have a document metaphor. > > John Nagle Something that everyone seems to be missing in this discussion: a while back, the OpenDoc architects had an AOL discussion which was archived. >From the archive, I gleaned this interesting tidbit (from memory, sorry): OpenDoc is robust enough to allow the creation of a Virtual REality where every object in the VR is run on its own computer and collated by OpenDoc over the network. One would assume that the "document" in this case, would be a set of 3D VR glasses or a 3D virtual environment complete with sound effects and tactile effects ala high-end flight simulators (and beyond). Given this ability of OpenDoc, what CAN'T it do? Lawson +++++++++++++++++++++++++++ >From E.J. Draper Date: 30 Aug 1994 18:47:40 GMT Organization: U.T.M.D. Anderson Cancer Center >If anything, OpenDoc should make your documents MORE portable. OpenDoc >documents will be binary-compatible across all supported platforms. Bento, and not OpenDoc, is the technology that will enable us to do this. Bento can be used quite easily by software other than OpenDoc parts. >Actually, OpenDoc has a great story for in-house MIS types. Wrong. Users who *do not* build *DOCUMENTS* will be annoyed at having to artificially create documents and incorporate parts just to get something done. The result of every human-machine interaction is *not* a document. OpenDoc is an interesting and useful addition to the concept of building documents, but it's only interesting and useful in those terms. OLE has been around for quite some time and what has the industry learned? How many people are using OLE in mission critical applications every day? How many people are out there screaming for OLE versions of Doom and Netware Client tools? >A good rule of thumb for what could and should be written as a part editor is: >"If it has a user interface, it should be a part." I vehemently disagree. |E|J- ED DRAPER rEpar|D|<- Radiologic/Pathologic Institute The University of Texas M.D. Anderson Cancer Center draper@utmdacc.mda.uth.tmc.edu +++++++++++++++++++++++++++ >From tbrown@magnus.acs.ohio-state.edu (Ted C Brown) Date: 30 Aug 1994 19:15:12 GMT Organization: The Ohio State University In article <33vno2$gco@news.acns.nwu.edu>, Robert Lentz wrote: >In article <33tgfn$r62@oac4.hsc.uth.tmc.edu>, >E.J. Draper wrote: >>... >>It seems like the whole OpenDoc paradigm starts breaking down after you >>get past the Graphic+MooV+Text+Spreadsheet model. > >Well, that covers all the basic types which other applications use too. > >Let's see: newsreader using a text part for composing messages, same with >mail program; perhaps sometimes using a WWW part for displaying HTML >documents, which then uses the text part and any necessary graphics parts >again... Having the "display HTML" part available would make any text editor closer to a graphical HTML editor. All the "Helper" apps would fold within the document as well (but there isn't much gain here). Sure make it easier to add the option-click on URL in Newswatcher though. Also, having all the parts work within OpenDoc makes it easier to have a central point that all such apps go to get user information. No more constant filling out email/server names for each new net application that is installed. I know this could be done some other way -- but it seems it would be simple in OpenDoc. The OpenDoc method might allow two people to have open connects at the same time, something you can't do currently with net packages. If someone else wants to read mail with Eudora on my machine, I have to quit Eudora so they can restart it with the proper settings file. +++++++++++++++++++++++++++ >From edcessna@netcom.com (Edward Cessna) Date: Tue, 30 Aug 1994 12:54:59 -0700 Organization: Disney > An OpenDoc or OLE-based creation system for multimedia content > would make sense, but that's an extension of the word processor metaphor. > > The whole multi-source document concept is useful, but only for things > that naturally have a document metaphor. This also applies to client/server applications where the data being retrieved from a database determines what the user sees on the screen. > jdelkins@lilly.com (Joel D. Elkins) wrote: > > Aside... > Q: What is the difference between a "form" and a "document"? > A: A form only has 1 page, but document's have a lot! :-) There is a bigger difference between forms and documents: forms have a rigid structure whereas documents do not. You can change the structure of a document but *not* of a form (I wish I could change the structure of my 1040 every April 15--sigh). You could have a database query part that could be embedded within an OpenDoc document. Editing the query part would mean change the query statement defined within it. What you would see in the document would be the results of the query. As for a database browser as an OpenDoc part, I don't believe that this would yield anything meaningful (akin to putting the finder in a OpenDoc document?). If anything, a database browser (a database application) would end up being an OpenDoc container application. When I use the term "database browser" I mean an application that could visit the various data within a database, allow the user to select something and, optionally, modify it. The user would also have the ability to delete old information and to insert new information. I'm not trying to imply that OpenDoc isn't useful to client/server applications, I just do not see how the document-centered approach would be practical. Other aspect of OpenDoc, like distributive objects, would be very useful however. -- Edward Cessna -- Walt Disney Pictures and Television +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Tue, 30 Aug 1994 22:29:13 +0200 Organization: Royal Institute of Something or other In article , jdelkins@lilly.com (Joel D. Elkins) wrote: >And what about client-server based apps, much in use by corporations today, >for which the "document" paradigm really doesn't apply. Most of >the c/s apps I've seen are more "forms" based. How will OpenDoc improve >such apps? Unless it does, I don't see widespread acceptance by corporations >for their in-house development efforts. This is IDEAL for OpenDoc; you'd make forms as stationery of linked parts with AppleScript as the glue in the middle. Because you then can make a form of ANYTHING, you gain instant multimedia forms! Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Reality exists only in your imagination. +++++++++++++++++++++++++++ >From E.J. Draper Date: 30 Aug 1994 20:51:18 GMT Organization: U.T.M.D. Anderson Cancer Center >That's also a collection of an editor part, a news collection >part, ... It seems that a great deal of the hype that surrounded AppleEvents before the release of System 7 is being recycled in OpenDoc propaganda. Everyone heard that they were going to be able to use one spell check program for all their needs. They'd also use one graphics program, one communications program, etc., etc.. Of course, all these programs were going to communicate together to enrich the Macintosh experience and open new profit channels for Apple and their developers. So now we've got shared libraries and the AppleEvent performance bottleneck is diminished. I'm still skeptical ... >Your news reader comes with the SimpleText text edittig part. >Unfortunately, this part does not handle parts larger than 32k, >so to decode alt.binaries.pictures.erotica.jello, you instead >use the Alpha text editting part which handles larger >documents, and write a small script that scans the news >collection part for multi-part postings, uses Alpha to >concatenate them, uses the StuffIt mangling part to get an >image which you display in the JPEGView picture display part. This solution would be inelegant, overly complex, neophyte hostile, and slow. What's so compelling about it? BTW- I did read the OpenDoc white paper. |E|J- ED DRAPER rEpar|D|<- Radiologic/Pathologic Institute The University of Texas M.D. Anderson Cancer Center draper@utmdacc.mda.uth.tmc.edu +++++++++++++++++++++++++++ >From edcessna@netcom.com (Edward Cessna) Date: Tue, 30 Aug 1994 14:21:56 -0700 Organization: Disney In article , susser@apple.com (Joshua Susser) wrote: > Actually, OpenDoc has a great story for in-house MIS types. They have two > big desires - being able to use COTS (Commercial Off The Shelf) Software, > and getting a vertical solution for their special needs. Notice these two > desires are in direct conflict. But with component technology like > OpenDoc, you can buy a set of COTS part editors and maybe only have to > write one or two special purpose ones in house. Then create standard > stationery using these chosen editors, write some scripts to integrate the > parts functionality, and presto, it's an instant vertical application, > custom made for your department with mostly COTS components. Interesting concept. So, when the user double-clicks on the stationery, a document will be created and they will be able to do their work. Question: is the structure of the document fixed? In other words, could the user accidentally delete or change one or more of the part editors? If the answer is yes, then this is a totally wash-out for our in-house users! We would spend more time helping the users and they would get annoyed at being able to "destroy" the app. > As for client-server, OpenDoc supports the concept of what we've been > calling an "embedded client". Create a part editor that can operate as a > client for a remote server. This would be great for our in-house developers but not our users! > A good rule of thumb for what could and should be written as a part editor is: > "If it has a user interface, it should be a part." I wish it was so... > Well, my compile is done, so back to work... So quickly? I think I got another 10 minutes to go on my link--sigh. -- Edward Cessna -- Walt Disney Pictures and Television +++++++++++++++++++++++++++ >From rmah@panix.com (Robert Mah) Date: Tue, 30 Aug 1994 17:39:12 -0500 Organization: One Step Beyond edcessna@netcom.com (Edward Cessna) wrote: ) There is a bigger difference between forms and documents: forms have a ) rigid structure whereas documents do not. You can change the structure of ) a document but *not* of a form (I wish I could change the structure of my ) 1040 every April 15--sigh). ) ) You could have a database query part that could be embedded within an ) OpenDoc document. Editing the query part would mean change the query ) ... I think you're putting too much emphasis on the term "document" here. Nothing in OpenDoc says that the user _must_ be able to manipulate the layout of the individual parts in a document/form. That is dependent upon a piece of software called something like the "framework" or "layout" app. You could easily, create a "forms" based part layout application that prevented the user from modifing the underlying part layout/structure. Cheers, Rob _____________________________________________________________________ Robert S. Mah Software Development +1.212.947.6507 One Step Beyond and Network Consulting rmah@panix.com +++++++++++++++++++++++++++ >From afcjlloyd@aol.com (AFC JLloyd) Date: 30 Aug 1994 17:40:02 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <33vusc$n5d@oac4.hsc.uth.tmc.edu>, E.J. Draper writes: >>Actually, OpenDoc has a great story for in-house MIS types. > >Wrong. Users who *do not* build *DOCUMENTS* will be annoyed at having to >artificially create documents and incorporate parts just to get something >done. The result of every human-machine interaction is *not* a document. >OpenDoc is an interesting and useful addition to the concept of building >documents, but it's only interesting and useful in those terms. Perhaps the term "document" is misleading you. If you grok object-oriented programming, substitute the concept "object" for a while. In its most basic definition, an "object" is something that has state, behavior, and identity (see Booch, Object Oriented Design). A document, while on disk, is simply state and identity. When the document is opened, OpenDoc dynamically binds the state to a part editor, which provides the behavior. A stationery document, by the way, is like a class -- a template for instantiating objects with default state. If you think in these more generic terms, I expect many of your objections will disappear. In all human-machine interaction, the machine is displaying some visual representation for some state. If you're concerned that OpenDoc won't work for things like databases because the database records can't be placed in Bento containers, then you just need to consider that the state stored in the Bento containers might be simply a "pointer" (or query, etc.) to where the data is actually stored. This results in "dynamically updated" objects -- the query doesn't change by the answer does. Document's like this will need to have a piece of state that says how often the query should be repeated in order to keep the displayed data up to date. >OLE has been around for quite some time and what has the industry >learned? How many people are using OLE in mission critical applications >every day? How many people are out there screaming for OLE versions of >Doom and Netware Client tools? You're right. No one is screaming for OLE or OpenDoc tools. This doesn't mean users won't very much appreciate (and ultimately demand) these kinds of tools, once they are done right. As I recall, most DOS users weren't screaming for GUI's until well after Microsoft did their third iteration of attempting to copy the Macintosh. Users don't usually scream for a solution, they just grumble about problems. However, once they see a good solution, they will generally scream if they aren't allowed to use the solution. This is even true of DOS users, they're just a bit slow ;-). > >>A good rule of thumb for what could and should be written as a part >editor is: >>"If it has a user interface, it should be a part." > >I vehemently disagree. Not everything that has a user interface *should* be made into a part, but just about anything with a UI *could* be made into a part, and doing so would provide a lot of flexibility that currently doesn't exist. As in all engineering endeavors, one should do a costs/benefits analysis first. Jim Lloyd afcjlloyd@aol.com -or- Jim_Lloyd@powertalk.apple.com +++++++++++++++++++++++++++ >From afcjlloyd@aol.com (AFC JLloyd) Date: 30 Aug 1994 20:53:02 -0400 Organization: America Online, Inc. (1-800-827-6364) In article <340646$o0q@oac4.hsc.uth.tmc.edu>, E.J. Draper writes: >>That's also a collection of an editor part, a news collection >>part, ... > >It seems that a great deal of the hype that surrounded AppleEvents before >the release of System 7 is being recycled in OpenDoc propaganda. >Everyone heard that they were going to be able to use one spell check >program for all their needs. They'd also use one graphics program, one >communications program, etc., etc.. Of course, all these programs were >going to communicate together to enrich the Macintosh experience and open >new profit channels for Apple and their developers. So now we've got >shared libraries and the AppleEvent performance bottleneck is diminished. > I'm still skeptical ... When new technologies are introduced, the "vision" of the "visionaries" who create the technology has to be communicated. Visionaries aren't perfect, they will often be wrong in the details, even if they are right in the generalities. So what if we don't yet have a universal spelling checker? It may still happen, and it may not. AppleEvents has already resulted in a lot of value, and is an enabling technology that will only become more important over time. If you feel bitter because of hype that hasn't become true, I suggest you develop your ability to read between the lines when presented with hype. >>Your news reader comes with the SimpleText text edittig part. >>Unfortunately, this part does not handle parts larger than 32k, >>so to decode alt.binaries.pictures.erotica.jello, you instead >>use the Alpha text editting part which handles larger >>documents, and write a small script that scans the news >>collection part for multi-part postings, uses Alpha to >>concatenate them, uses the StuffIt mangling part to get an >>image which you display in the JPEGView picture display part. > >This solution would be inelegant, overly complex, neophyte hostile, and >slow. What's so compelling about it? I won't comment on something as subjective as "elegance". The solution may be "complex", but a lot is happening. If a specific complex problem can be solved by breaking it down into subproblems that can each be solved with off-the-shelf parts, then complexity is reduced, not increased. Requiring a neophyte to do the above from scratch would certainly be hostile, but if you provide that neophyte with a previously prepared stationery document, it should be no more hostile than a traditional solution for this kind of application. Finally, why should the above be slow? Almost all of the computation is I/O bound. The slowest part of the implementation would be the execution speed of the scripts, and this would be dominated by the I/O. Jim Lloyd afcjlloyd@aol.com -or- Jim_Lloyd@powertalk.apple.com +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Tue, 30 Aug 1994 19:13:38 -0800 Organization: Integer Poet Software In article <340646$o0q@oac4.hsc.uth.tmc.edu>, E.J. Draper wrote: > So now we've got shared libraries and the AppleEvent performance > bottleneck is diminished. I'm still skeptical ... Do you believe it's the case that AppleEvents and AppleScript haven't happened according to the hype because of the performance overhead associated with AppleEvents? If so, I urge you to figure out exactly how to write an OSA-compliant app without attending a class at Apple DU. It takes a long time, and that's if you're actually enthusiastic enough about the ideas to try hard. It's not that the concepts are overly confusing; the documentation simply isn't good. There are other problems (for example the lack of compile-time type-checking when building AppleEvents and Object Specifiers), but the problem is certainly not performance. -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "Even during a particularly harsh (Colorado) winter... many of the 300 families in the VCTV (movies-on-demand) trial continued to go to video stores." -- eis@murrow.tufts.edu, in Wired 2.09 p62 +++++++++++++++++++++++++++ >From Bruce@hoult.actrix.gen.nz (Bruce Hoult) Date: Wed, 31 Aug 1994 13:18:42 +1200 (NZST) Organization: (none) E.J. Draper writes: > >> > edit them with appropriate tools. It's sort of "Publish and Subscribe, > >> > The Next Generation". Yes, you can do other stuff, but the touted > > How many times a day do you use Publish and Subscribe? > > The one, and only, application I have for Publish and Subscribe > technology is checking the amount of vacation hours I've got coming to me > from the departmental spreadsheet. I use it once a week at the most, > probably more like once a month. You might not use publish&subscribe. I know that, as a programmer, doing programmer things, I don't. But in the office I support, there is a huge structure of linked spreadsheets, graphics documents and word processing documents, all linked together by publish&subscribe. Eventually, we'd like to have all this managed by a proper database system, but for now Publish&subscribe is a huge improvement over the alternatives, even if the performance does stink (especially in Excel). -- Bruce +++++++++++++++++++++++++++ >From scouten@uiuc.edu (Eric Scouten) Date: Tue, 30 Aug 1994 23:49:14 -0500 Organization: University of Illinois In article , edcessna@netcom.com (Edward Cessna) wrote: > In article , susser@apple.com > (Joshua Susser) wrote: > > > Actually, OpenDoc has a great story for in-house MIS types. > > Interesting concept. So, when the user double-clicks on the stationery, a > document will be created and they will be able to do their work. Question: > is the structure of the document fixed? In other words, could the user > accidentally delete or change one or more of the part editors? If the > answer is yes, then this is a totally wash-out for our in-house users! We > would spend more time helping the users and they would get annoyed at > being able to "destroy" the app. I believe in the OpenDoc white paper, there's a section on "access control" that addresses just this issue. Can't remember exactly how it's implemented, but I don't think the system is as naive as you have suggested. -Eric __________________________________________________________________________ Eric Scouten * MS Comp Sci, Univ of Illinois The Pledge of Allegiance says, "liberty and justice for all." Which part of "all" don't you understand? -Rep. Pat Schroeder +++++++++++++++++++++++++++ >From quinlan@kits.sfu.ca (Brian Quinlan) Date: 31 Aug 94 06:20:31 GMT Organization: Simon Fraser University nagle@netcom.com (John Nagle) writes: > The whole development environment shouldn't be a structured document, >but source programs might be. Programs today have parts which are visual >and parts which are textual, and those parts need to be better connected. >HyperCard already does this. I'll have to disagree here. I would love to see my program as a flowchart, object relation diagram or dataflow diagram. When I click on a box representing an object, method or function I would get an editor. It could click on a line and get an interface editor. > You could, but why would you want to embed those functions in a >structured document? A document is the wrong metaphor for that collection >of functions. There's no content in which you're embedding those >functions. A multiwindow application is more appropriate. Your right, I was grasping at straws here. > An OpenDoc or OLE-based creation system for multimedia content >would make sense, but that's an extension of the word processor metaphor. True, it is most easy to see the benifits for a word processor but I think it would be helpful in other situations as well. I think that for OpenDoc to be usefull you need to be working on some sort of document. When programming you do use documents (rez, source, etc.) and you could use OpenDoc to integrate these parts into a unified whole. > The whole multi-source document concept is useful, but only for things >that naturally have a document metaphor. I wish I had read this more carefully before making my last comment! +++++++++++++++++++++++++++ >From hanrek@cts.com (Mark Hanrek) Date: 31 Aug 1994 09:23:21 GMT Organization: The Information Workshop In article , gurgle@dnai.com (Pete Gontier) wrote: > Do you believe it's the case that AppleEvents and AppleScript haven't > happened according to the hype because of the performance overhead > associated with AppleEvents? If so, I urge you to figure out exactly how > to write an OSA-compliant app without attending a class at Apple DU. It > takes a long time, and that's if you're actually enthusiastic enough about > the ideas to try hard. It's not that the concepts are overly confusing; > the documentation simply isn't good. There are other problems (for example > the lack of compile-time type-checking when building AppleEvents and > Object Specifiers), but the problem is certainly not performance. Pete, I agree 100%, as someone who has spent a good deal of time with those subjects. There is a "difficulty barrier" in assimilating the AE/AS technologies which need not exist. There could easily be certain materials and/or utilities that would help make Apple events and related subjects easy to deal with. These technologies have now become "fundamental" and "required". Hopefully Apple will be able to help turn this molasses back into water. I get the feeling that it is just a matter of time until this boil will need to be lanced. - ---- Visibility I believe "visibility" is one leveraged key to success here. If we had doohickies that showed Apple events moving around, allowed us to examine them as AEGizmo-like things on screen, and had materials that made clear the relationships between AppleScript statements, aete resources, and object accessors, kinda thing, there'd likely be a lot more happening. Extrapolating from the past, it will probably be some time before there any new relief here from Apple. This topic could have been clarified years ago. If only we [the development community] had the ability to "turn up the volume" with these technologies ourselves. - ---- Interesting Alternative One major event which has yet to happen is for the Macintosh Development Community to organize itself, and consequently have for the first time the realistic opportunity to "see to some of its own needs", drawn from its own resources. In many instances, it is not appropriate to expect that Apple is supposed to provide a solution, or even to have an accurate perception of its development community. We accidentally think Apple should solve our problems or understand us because we are generally powerless to do anything beyond what our spare time will allow. But the organized spare time of 10 programmers can accomplish some significant things. Or a seed planted by one programmer, and refined 10 times over. Unfortunately, the event of us organizing ourselves won't likely be able to occur until true electronic forums are available on the Internet. Forums provide the means of easily developing consensus, electing leadership or an agenda, and facilitating collaboration, among other essentials. There's that "forum" word again. Interesting, eh? :) :) Mark "a-newsgroup-is-not-a-forum" Hanrek The Information Workshop +++++++++++++++++++++++++++ >From sw@network-analysis-ltd.co.uk (Sak Wathanasin) Date: Wed, 31 Aug 94 09:57:57 BST Organization: Network Analysis Ltd In article (comp.sys.mac.programmer), nagle@netcom.com (John Nagle) writes: > >You could have a basis upon which you had a newsreader, email and ftp parts. > You could, but why would you want to embed those functions in a > structured document? A document is the wrong metaphor for that collection I'd have thought it would be the other way round - the doucment would be in the mail or news article. Or better, the mail message or news article would be the document. That's the way it worked with Xerox Viewpoint - when you got something in the mailbox, you opened it and there would (sometimes) be a header part and the rest would be the document. You didn't have to save an attachment or anything; it could be dragged on to the desktop and operated on as a normal WP document. Xerox VP had quite a few of the OpenDoc ideas implemented (although OD goes much further, of course). Appl-centric and doc-centric objects can co-exist quite happily. Or at least I didn't go around clutching my head screaming "Oh, my God! Is that an appl or document object?" I just double-clicked on it and went about my business... Sak Wathanasin Network Analysis Limited 178 Wainbody Ave South, Coventry CV3 6BX, UK Internet: sw@network-analysis-ltd.co.uk uucp: ...!uknet!nan!sw AppleLink: NAN.LTD Phone: (+44) 203 419996 Mobile:(+44) 850 587411 Fax: (+44) 203 690690 +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Wed, 31 Aug 1994 12:07:57 +0200 Organization: Royal Institute of Something or other In article , edcessna@netcom.com (Edward Cessna) wrote: >is the structure of the document fixed? In other words, could the user Yes; you can lock the frames of parts in OpenDoc compound documents. This is in the white paper. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Reality exists only in your imagination. +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Wed, 31 Aug 1994 12:07:59 +0200 Organization: Royal Institute of Something or other In article <340646$o0q@oac4.hsc.uth.tmc.edu>, E.J. Draper wrote: >This solution would be inelegant, overly complex, neophyte hostile, and >slow. What's so compelling about it? The neophyte buys a pre-configured stationery/part editor bundle that behaves as an integrated whole. The non-neophyte can go in and change whatever he wants in the bundle to make it fit his needs. The information systems people in an organization can use off-the-shelf parts and their own custom glue to create needed applications. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Reality exists only in your imagination. +++++++++++++++++++++++++++ >From philip@cs.wits.ac.za (Philip Machanick) Date: 31 Aug 1994 13:05:05 GMT Organization: Computer Science Dept, U of Witwatersrand In article <33tgfn$r62@oac4.hsc.uth.tmc.edu>, E.J. Draper wrote: > I can see some interesting applications of OpenDoc technology, but I > certainly don't feel it's as mind-boggling awesome as the market-droids > would have us think. What's OpenDoc going to do for me? Does a compiler > part make sense? How about news reader part? An email part? A PIM part? Compiler makes sense - but you are not trying to think of where the "document" comes in. Look at something like CodeWarrior or ThinkC. Each item in the project file is a part. You can open it to a window, you can drag it around in the project. Cut, copy, paste are less obvious - maybe there is use for these. News reader the same thing. A newsreader consists of a number of documents with different behaviours. If you don't use NewsWatcher you may not see the possibilities. NewsWatcher has features like extract binhex, fetch ftp from reference in article etc. Such things could be added as new behaviours in a news document. On the other hand some web viewers allow you to retrieve news articles. OpenDoc could make for much more seemless integration of all these things. Imagine: a different part handler for each kind of URL. > A Resorcerer part? How does OpenDoc improve the way that people work > with information? Does it make the computer more approachable to novice > users? What specific problem is it trying to solve? It's trying to solve the problem of the monolith application. All these people who are compaining that the Mac doesn't have proper protection etc. are right, only they are too late. The application of today is bigger and more complex than the operating system of the time when schedulers, paging etc. were invented (VM goes back to the 1950s). What is needed now is a way of putting together complex behaviour in smaller packages. Look up Brad Cox's book on software ICs (I forget the title). OpenDoc is a framework for plugging together software ICs - call it a software PCB. Not that protection etc. should not be addressed - but _only_ adding protection and pre-emption would give us a good 1970s OS without addressing the monolithic app problem. With a good OS underneath it OpenDoc could turn out to be a dinosaur killer. The underlying idea is not new. The Xerox Star was programmed like this and Apple has some of the people who were at Parc at the time pushing it along. > It seems like the whole OpenDoc paradigm starts breaking down after you > get past the Graphic+MooV+Text+Spreadsheet model. It breaks down when you can't conceive of what you are doing as manipulating a document. The same thing was true of understanding why windowed interfaces are better than command line interfaces. Some people still don't get it :( but some of us are very happy programming in windowed environments like CodeWarrior. -- Philip Machanick philip@cs.wits.ac.za Department of Computer Science, University of the Witwatersrand 2050 Wits, South Africa (at University of Cape Town 4 July-7 Nov) phone 27(11)716-3309 fax 27(11)339-7965 +++++++++++++++++++++++++++ >From philip@cs.wits.ac.za (Philip Machanick) Date: 31 Aug 1994 13:14:39 GMT Organization: Computer Science Dept, U of Witwatersrand In article , nagle@netcom.com (John Nagle) wrote: > > I think he has a point. I can imagine a CAD system based on this > approach, where you click on a subassembly to get to the detailed drawings. > But that doesn't even fit the OpenDoc model, which is 2D, not 3D. > What, besides embed stuff in word processor documents, is one really likely > to do with OpenDoc? Embed word processing in graphics documents :) In what sense are you saying OpenDoc is 2D? It is based on frames which can have an arbitrary shape so I suppose there is potentially a problem implementing a part picker that is aware of depth. It is possible this could be layered on top of the model of passing messages to contained parts. Maybe someone who has gone further into detail could answer this. > By the way, how does OpenDoc do version management? At some point in the history of a document you can start a new edition, and go back to previous editions. Since there is supposed to be support for cross-platform collaborative editing, there ought to be more sophisticated features, but I have seen nothing about this. There are a lot of potential problems with OpenDoc but it is a real attempt at rethinking the document-application relationship. I would like to see how it develops. I'm less sure about all the weird infrastructure it's being pinned onto though - a good simple kernel plus an object-oriented language with better dynamic binding than C++ would have been a better start. -- Philip Machanick philip@cs.wits.ac.za Department of Computer Science, University of the Witwatersrand 2050 Wits, South Africa (at University of Cape Town 4 July-7 Nov) phone 27(11)716-3309 fax 27(11)339-7965 +++++++++++++++++++++++++++ >From lentz@rossi.astro.nwu.edu (Robert Lentz) Date: 31 Aug 1994 14:40:12 GMT Organization: Northwestern University, Evanston, Illinois, USA In article <340k9e$mdv@search01.news.aol.com>, AFC JLloyd wrote: >... >When new technologies are introduced, the "vision" of the "visionaries" >who create the technology has to be communicated. Visionaries aren't >perfect, they will often be wrong in the details, even if they are right >in the generalities. So what if we don't yet have a universal spelling >checker? It may still happen, and it may not. AppleEvents has already >resulted in a lot of value, and is an enabling technology that will only >become more important over time. If you feel bitter because of hype that >hasn't become true, I suggest you develop your ability to read between the >lines when presented with hype. >... And complain to those developers that have not seen the light. Would it not be nice to be able to ask Word to spell check a document for you? -Robert -- lentz@rossi.astro.nwu.edu http://www.astro.nwu.edu/lentz/plan.html "You have to push as hard as the age that pushes against you." -Flannery O'Connor +++++++++++++++++++++++++++ >From Jaeger@fquest.com (Brian Stern) Date: 31 Aug 1994 15:24:32 GMT Organization: The University of Texas at Austin, Austin, Texas In article , hanrek@cts.com (Mark Hanrek) wrote: < ------ Interesting Alternative < < One major event which has yet to happen is for the Macintosh Development < Community to organize itself, and consequently have for the first time the < realistic opportunity to "see to some of its own needs", drawn from its < own resources. You're right, we're not organized. < In many instances, it is not appropriate to expect that Apple is supposed < to provide a solution, or even to have an accurate perception of its < development community. We accidentally think Apple should solve our < problems or understand us because we are generally powerless to do < anything beyond what our spare time will allow. Yes, Apple does what it wants, what it has resources to do, and what it *thinks* we want. < But the organized spare time of 10 programmers can accomplish some < significant things. Or a seed planted by one programmer, and refined 10 < times over. Absoluteley. < Unfortunately, the event of us organizing ourselves won't likely be able < to occur until true electronic forums are available on the Internet. < Forums provide the means of easily developing consensus, electing < leadership or an agenda, and facilitating collaboration, among other < essentials. < < There's that "forum" word again. Interesting, eh? < Here's where you lose me. What does a forum have that a newsgroup doesn't have? Don't tell me archiving of every message because most of what's posted here does not deserve to be saved for posterity. If you want something you have to ask for it. And in a way that people understand what it is that you're asking for. I agree with you that the tools available and information available to us are often inadequate. Discussing that in this forum (sorry) is one way of letting the tool/information providers know what we want. If you want something from the programming community this also a good place for discussion of that. My question is: What do you want? < :) :) < < Mark "a-newsgroup-is-not-a-forum" Hanrek < The Information Workshop -- Brian Stern :-{)} Jaeger@fquest.com +++++++++++++++++++++++++++ >From 103t_english@west.cscwc.pima.edu Date: 31 Aug 94 15:29:30 MST Organization: (none) In article , Jaeger@fquest.com (Brian Stern) writes: > In article , hanrek@cts.com (Mark > Hanrek) wrote: > > > < ------ Interesting Alternative > < There's that "forum" word again. Interesting, eh? > < I think that Mark is hinting at a commercial project that he is working on, and many of his posts, while they are valid, are simply an attempt to steer folks to the conclusion that something remarkably similar to what he is planning on marketing, is actually a good idea and that they would buy it. I don't know if I am correct or not, but it feels this way to me. Personally, I think it a REALLY GOOD marketing ploy if I am correct. > > Here's where you lose me. What does a forum have that a newsgroup doesn't > have? Don't tell me archiving of every message because most of what's > posted here does not deserve to be saved for posterity. If you want > something you have to ask for it. And in a way that people understand > what it is that you're asking for. > > I agree with you that the tools available and information available to us > are often inadequate. Discussing that in this forum (sorry) is one way of > letting the tool/information providers know what we want. If you want > something from the programming community this also a good place for > discussion of that. My question is: What do you want? > > < :) :) > < > < Mark "a-newsgroup-is-not-a-forum" Hanrek > < The Information Workshop > > -- > Brian Stern :-{)} > Jaeger@fquest.com Lawson +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Thu, 1 Sep 1994 05:14:15 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) philip@cs.wits.ac.za (Philip Machanick) writes: >It's trying to solve the problem of the monolith application. All these >people who are compaining that the Mac doesn't have proper protection etc. >are right, only they are too late. The application of today is bigger and >more complex than the operating system of the time when schedulers, paging >etc. were invented (VM goes back to the 1950s). What is needed now is a >way of putting together complex behaviour in smaller packages. Look up >Brad Cox's book on software ICs (I forget the title). OpenDoc is a >framework for plugging together software ICs - call it a software PCB. Not >that protection etc. should not be addressed - but _only_ adding >protection and pre-emption would give us a good 1970s OS without >addressing the monolithic app problem. With a good OS underneath it >OpenDoc could turn out to be a dinosaur killer. PenPoint had the right idea on this. It's worth looking at how PenPoint worked internally. Forget about the pen stuff (PenPoint was the OS for the now-defunct EO, which failed mostly because a $4000 PDA was too expensive); the document model in PenPoint looked good. Like OpenDoc, a document appeared as a number of areas on screen, with each area maintained by a different application. Unlike OpenDoc, each application ran in a separate address space with full protection. The notion of "application launch" was eliminated; as you scrolled through a document, processes were created and terminated as required. PenPoint had no installed base with which they had to be compatible, so they could use a much simpler architecture. All PenPoint apps are derived classes from base classes of the OS. This makes apps much smaller and simpler, and enforces standardization. But it's not an architecture you can retrofit. The price we pay for backwards compatibility is seen in the complexity of OLE and OpenDoc. John Nagle +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Thu, 01 Sep 1994 08:56:19 +0200 Organization: Royal Institute of Something or other In article <3424oc$9ba@news.acns.nwu.edu>, lentz@rossi.astro.nwu.edu (Robert Lentz) wrote: >And complain to those developers that have not seen the light. Would it not >be nice to be able to ask Word to spell check a document for you? No, because Word uses Houghton-Mifflin spell checking, which you can license yourself. Don't. Their Mac code would compile on a 1984 Mac, and that's it. It uses FSOpen(). It uses signed chars interchangeably with unsigned chars. Etc. Their English dictionary is also nothing good unless you buy all the extra libraries. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Reality exists only in your imagination. +++++++++++++++++++++++++++ >From philip@cs.uct.ac.za (Philip Machanick) Date: 1 Sep 1994 10:08:40 +0200 Organization: Computer Science Department, University of Cape Town Just curious. I wonder how many of the people saying OpenDoc is no good - AAARGH NO! IT'S CONFIGURABLE - THE USERS WILL BREAK IT - are the same ones who used to run down the Mac because it isn't configurable like X. I must say though I can have some empathy with this fear having wasted large chunks of time trying to make X usable every time I move to a new place. -- Philip Machanick philip@cs.wits.ac.za Computer Science Department, University of he Witwatesrand 2050 Wits, South Africa 27(11)716-3309 fax 339-7965 (at University of Cape Town until November: 27(21)650-4058) +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Thu, 01 Sep 1994 14:55:18 +0200 Organization: Royal Institute of Something or other In article , nagle@netcom.com (John Nagle) wrote: > The price we pay for backwards compatibility is seen in the >complexity of OLE and OpenDoc. Guess what? In OpenDoc, all applications are subclasses of a system class, ODPart to be exact, and all storage is subclasses of ODStorageUnit (or whatever) etc. OpenDoc also requires total rewrite of everything; it's NOT designed to be backwards compatible (which OLE is, to some degree) However, you're confusing the issues of an application runtime architecture with the issues of various OS support. There's no reason why OpenDoc parts cannot live in separate protected address spaces. Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden Reality exists only in your imagination. +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Thu, 1 Sep 1994 16:26:12 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) >In article , hanrek@cts.com (Mark >Hanrek) wrote: >< In many instances, it is not appropriate to expect that Apple is supposed >< to provide a solution, or even to have an accurate perception of its >< development community. We accidentally think Apple should solve our >< problems or understand us because we are generally powerless to do >< anything beyond what our spare time will allow. >Yes, Apple does what it wants, what it has resources to do, and what it >*thinks* we want. Apple needs to realize that 1) the development tools for the Macintosh are now inferior to those for Windows, and 2) this is Apple's problem, whether Apple likes it or not. John Nagle +++++++++++++++++++++++++++ >From jonpugh@netcom.com (Jon Pugh) Date: Thu, 1 Sep 1994 21:50:31 GMT Organization: Will hack for food John Nagle (nagle@netcom.com) wrote: > Apple needs to realize that 1) the development tools for the > Macintosh are now inferior to those for Windows, and 2) this is Apple's > problem, whether Apple likes it or not. This is off the thread, but I just wanted to refute this statement. We have just gone from all Mac development to doing some Windows development too. We had heard this line for some time but it does not jibe with our experience. We have yet to find a single tool that operates as nicely as THINK, CW _or_ MPW. Sure, some are faster, some have cool features, but nothing works as well or as integrated. Just trying to write some scripts to mimic some of our MPW Projector scripts was a nightmare! All in all, we should start a different thread and argue about this some more. Macintosh development tools are damn nice compared to the mess on Windows. Jon +++++++++++++++++++++++++++ >From bobd@zaphod.UUCP (Bob Dalgleish) Date: 2 Sep 94 16:12:19 GMT Organization: Develcon Electronics Ltd., Saskatoon, SK, Canada In article susser@apple.com (Joshua Susser) writes: >nagle@netcom.com (John Nagle) wrote: >> E.J. Draper writes: >> >It seems like the whole OpenDoc paradigm starts breaking down after you >> >get past the Graphic+MooV+Text+Spreadsheet model. >> >> I think he has a point. I can imagine a CAD system based on this >> approach, where you click on a subassembly to get to the detailed drawings. >> But that doesn't even fit the OpenDoc model, which is 2D, not 3D. >> What, besides embed stuff in word processor documents, is one really likely >> to do with OpenDoc? > >OpenDoc windows and layout objects are 2D, because that's the >dimensionality of the imaging devices available today (for the most >part). But we did leave enough room in the API to support 3D parts. It >should in fact be possible to embed a text part onto the surface of a 3D >sphere part. > >But even without 3D, OpenDoc is suitable for much more than just a >"Graphic+MooV+Text+Spreadsheet" kind of document. See below. I started to have a vision. Having followed this thread for awhile, and read through the WWDC documentation, installed BBEdit 3.0, Symantec C 7, and MW CW, purchased and installed a *very expensive* CASE system, and still being faced with elementary problems of envisioning software, I started to see a trend. Software project forms a document (in SC7, this is a project file), to which are attached source files, object files, library files, resource files, resource source files, and pretty much anything you want. The TPM uses the file suffix to assign a "part editor" to each type of file, and "does the right thing" at the right time. How does this differ from an OpenDoc document with part editors for distinct parts, and a document "application" co-ordinating the make process? Even though we think of source code as a text file, we, in fact, treat it as a specialized database of relationships. Witness PopUpFuncs, CMaster, ObjectMaster, and other extensions to the basic set of text manipulation tools. Someone else has suggested "Could I not see my source code as a flow-chart, data-flow chart, decision table, coverage checklist?" The model we already use for software development is that of an OpenDoc architecture with only three providers and some hangers-on. A true OpenDoc document for a development project would have resource editors, text editors, compilers, graphers, analyzers, etc., as part editors that could be applied at any time for any purpose that the devious minds of developers can come up with. >> By the way, how does OpenDoc do version management? > >OpenDoc documents provide a facility for creating a named revision of your >document called a "draft". Each draft is basically a checkpoint of the >state of the document. You can create a new draft at any time, have as >many as you like, open old drafts to compare to newer, etc. There's >lots more about drafts, but you can read the documentation for that. This is much more sophisticated than Projector or SourceServer or RCS. As long as there was a way to get drafts of parts, most programmers would be happy to work in such a world. Any programmer will tell you that comments don't cut it as for keeping sufficient information to maintain software, but it is the only tool available. New part editors, and ways to co-ordinate them may be just the way to do it. Okay, who's up for writing an OpenDoc document to replace Think C and CodeWarrior? -- -- * * * CFV: net.short.signatures * * *-- Bob Dalgleish zaphod!bobd@tribune.usask.ca CompuServe: 70521,2011 +++++++++++++++++++++++++++ >From will@cs.su.oz.au (William Uther) Date: 3 Sep 1994 10:36:00 +1000 Organization: Basser Dept of Computer Sciece, Uni of Sydney, Australia In article <5865@zaphod.uucp>, Bob Dalgleish wrote: >In article susser@apple.com (Joshua Susser) writes: [snip] >>But even without 3D, OpenDoc is suitable for much more than just a >>"Graphic+MooV+Text+Spreadsheet" kind of document. See below. > >I started to have a vision. Having followed this thread for awhile, and >read through the WWDC documentation, installed BBEdit 3.0, Symantec C 7, >and MW CW, purchased and installed a *very expensive* CASE system, and >still being faced with elementary problems of envisioning software, I >started to see a trend. [snip] >Even though we think of source code as a text file, we, in fact, treat >it as a specialized database of relationships. Witness PopUpFuncs, >CMaster, ObjectMaster, and other extensions to the basic set of text >manipulation tools. Someone else has suggested "Could I not see my >source code as a flow-chart, data-flow chart, decision table, coverage >checklist?" [snip] >Okay, who's up for writing an OpenDoc document to replace Think C and >CodeWarrior? This sounds very like the Gwydion project CMU are working on (with Apple?). The WWW page URL is: http://legend.gwydion.cs.cmu.edu:8001/gwydion/ They are working on a development environment for Dylan (aka BHS) which includes being able view your code as hypertext. They mention version control where you can lock functional parts on the program - e.g. if you were changing the interface to a function you could lock "this function and all functions that reference it". Anyway, have a look the WWW page for more info. \x/ill :-} +++++++++++++++++++++++++++ >From deanp@zikzak.apana.org.au (Dean Perry) Date: 8 Sep 1994 04:45:11 GMT Organization: Zikzak public access UNIX, Melbourne Australia eric larson (eric.larson@f620.n2605.z1.fidonet.org) wrote: : > A more fundamental problem is that all this machinery exists mostly : > so you can embed different documents in your word processor and still : > edit them with appropriate tools. It's sort of "Publish and Subscribe, : > The Next Generation". Yes, you can do other stuff, but the touted : > advantage is mostly for integrated documents. It's all focused on : > what documents look like, not what they mean. Is that really worth all : > this complexity? : One concern I have about this technology is what it is going to do to document : portability. Like what do you do when you don't have all the parts to view something... I guess this will come about along the lines of what happens if you have a QuickTime clip in a document on a machine without it installed - you get a dead placeholder that may or may not represent the content. The whole idea of *distributed* parts freaks me a little - what do you do when your document relies on net connections to multiple remote servers and the net goes away? dean -- Zikzak public access UNIX, Melbourne, Australia. +++++++++++++++++++++++++++ >From quinn@cs.uwa.edu.au (Quinn "The Eskimo!") Date: Thu, 08 Sep 1994 17:50:17 +0800 Organization: Department of Computer Science, The University of Western Australia In article , nagle@netcom.com (John Nagle) wrote: > Or long-term document integrity. Will you still be able to read >your document a few years downstream, after all the applications have >changed? And if you can't, which vendor do you call for help? I don't think this will be a problem. Unless there are nasty bugs in the part handlers, OpenDoc should still be able to open the document, even if you can't edit (or even view) it. You'll be able to rip it apart and try to find out which part handler is having the bad day. Alternatively it's likely that sooner or later, someone will build 'ResEdit for Bento', an application that lets you tear OpenDoc documents apart at a low level. This means you'll be able to break any document up into its component parts and hence edit them that way. Let's face it, you face exactly the same problem today with non-compound documents. If WidgetWorks Inc goes down the tubes and, 3 years later, WidgetWorks fails to run under Gerschwin, well you're screwed, aren't you? Share and Enjoy. -- Quinn "The Eskimo!" "Scout in a can. Simple, cheap, easy to use and it's expendable!" +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Thu, 08 Sep 1994 09:40:32 -0800 Organization: Integer Poet Software In article <34m4t5$k9p@lazar.apana.org.au>, deanp@zikzak.apana.org.au (Dean Perry) wrote: > : One concern I have about this technology is what it is going to do to > : document portability. > > Like what do you do when you don't have all the parts to view > something... I guess this will come about along the lines of what happens > if you have a QuickTime clip in a document on a machine without it > installed - you get a dead placeholder that may or may not represent the > content. Good answer. Gold star. :-) However, this is not a complete solution. We all know what happens when an app fails to save font names in its documents as opposed to font numbers. The font numbers will work as long as (1) the doc stays on one machine, and (2) the user doesn't mess with hir Fonts folder. Deprive the document of either one of those conditions, though, and the page layout goes straight in the toilet, even if you're able to find a similar font and apply it through some kind of global style mechanism (because presumably there are too many changes to make manually). Now imagine what's missing is not just a font but a program. Presumably the program is a bit more complex than a font. Don't get me wrong; it might be as clean as a QuickTime PICT. But we can't really guess what unfortunate portability issues will appear until they do appear, because nobody has done this before. > The whole idea of *distributed* parts freaks me a little - what > do you do when your document relies on net connections to multiple remote > servers and the net goes away? It doesn't strike me that this is any worse than a part editor which is missing when the doc is opened. One important difference is that the app shell might be able to take a snap shot of the part's screen representation before the part editor goes away. -- Pete Gontier // impudent ass // gurgle@dnai.com "The need to be (or appear to be) sophisticated pervades the very atmosphere in which we, the Magazine Reading Class, move." -- Ellis Weiner, Spy Magazine, 9/94 +++++++++++++++++++++++++++ >From Jens Alfke Date: Thu, 8 Sep 1994 18:40:11 GMT Organization: Apple Computer Dean Perry, deanp@zikzak.apana.org.au writes: > : One concern I have about this technology is what it is going to do to document > : portability. > Like what do you do when you don't have all the parts to view > something... There are three levels of support for this: * If you don't have the preferred editor for that part, but have another editor that can edit one or more of the content types saved for that part, that editor will be used. (Note that an editor can save a part in multiple representations, kind of like writing to the Clipboard or drag mgr today.) * If that fails, but there is a translator available that knows how to translate one of the part's formats into something one of your available editors can read, the translator will be used. (On the Mac, this uses the translation system from Mac Easy Open. Other platforms will implement it differently.) * If all else fails, the part will display as a gray box that displays its content type(s). Note that the document will still open, and all other parts for which an editor could be found will appear. Someone else mentioned a "Bento ResEdit" ... someone (not at Apple) has written a tool like that. I'm not sure whether they're going to finish the implementation or distribute it more widely. It'd be quite useful. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Fri, 09 Sep 1994 10:07:24 +0200 Organization: Royal Institute of Something or other In article <34m4t5$k9p@lazar.apana.org.au>, deanp@zikzak.apana.org.au (Dean Perry) wrote: >Like what do you do when you don't have all the parts to view >something... Part Viewers are encouraged to be free, while the editors would cost money. Also, a Part Editor is encouraged to store its info in one or more standard formats (i e PICT) as well as its own format, so you can use the "SimpleText" part to view but not edit it. >content. The whole idea of *distributed* parts freaks me a little - what >do you do when your document relies on net connections to multiple remote >servers and the net goes away? What do you do when the power goes out? Oh, it doesn't go out often, but it happens, right? Networks will have about the same reliability. (And aside from having an UPS, I now am looking for a V.24 adapter for my digital cellular phone :-) Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden This is the kind of totally-gross-out-sick stuff you can do with C++ that makes the language kind of neat. -- Keith Rollin +++++++++++++++++++++++++++ >From nagle@netcom.com (John Nagle) Date: Fri, 9 Sep 1994 16:36:15 GMT Organization: NETCOM On-line Communication Services (408 261-4700 guest) gurgle@dnai.com (Pete Gontier) writes: >In article <34m4t5$k9p@lazar.apana.org.au>, deanp@zikzak.apana.org.au >(Dean Perry) wrote: >> : One concern I have about this technology is what it is going to do to >> : document portability. >> >> Like what do you do when you don't have all the parts to view >> something... >We all know what happens when an app fails to save font names in its >documents as opposed to font numbers. ... >Now imagine what's missing is not just a font but a program. ... Yeah. Supposedly the plan for OpenDoc is that a PICT representation of the object is carried with the document, so it can be viewed without the appropriate editor. One implication is that even simple documents will be big. A more subtle implication is that document editability may invisibly degrade over time as the underlying applications change. The document may look just fine until you try to do something to it. John Nagle +++++++++++++++++++++++++++ >From jonpugh@netcom.com (Jon Pugh) Date: Tue, 13 Sep 1994 22:57:58 GMT Organization: Will hack for food John Nagle (nagle@netcom.com) wrote: > Yeah. Supposedly the plan for OpenDoc is that a PICT representation > of the object is carried with the document, so it can be viewed without > the appropriate editor. > One implication is that even simple documents will be big. A more > subtle implication is that document editability may invisibly degrade over > time as the underlying applications change. The document may look just > fine until you try to do something to it. These are all concerns relating to OLE also. In fact, Microsoft advocates OLE as a superior technology because it includes a picture along with the data whereas OpenDoc does not (according to this MicroSoft OLE comparison paper I've been reading). My favorite part is where they claim that because the picture is included, the document may be printed without the editor being involved. They seem to have missed the whole resolution issue. Personally, I like the OpenDoc approach better. It takes a more functional attitude, where parts can work the way they want instead of the way the container wants, which is the OLE approach. This paper says that OLE can do OpenDoc's in place activation (normal OLE parts are inactive until clicked) if the container app wants to. It doesn't mention that no OLE apps want to. I can see why. If you activate an Excel graph in Word when it scrolls onto the screen, you need to launch Excel. That's a nontrivial operation. The real question is, will you be able to init all your parts fast enough. The OLE folks don't think so, which is why they advocate static pictures, no implicit activation and printing from the pictures. Jon +++++++++++++++++++++++++++ >From philip@cs.wits.ac.za (Philip Machanick) Date: 14 Sep 1994 07:07:06 GMT Organization: Computer Science Dept, U of Witwatersrand In article , jonpugh@netcom.com (Jon Pugh) wrote: > Personally, I like the OpenDoc approach better. It takes a more functional > attitude, where parts can work the way they want instead of the way the > container wants, which is the OLE approach. This paper says that OLE can do > OpenDoc's in place activation (normal OLE parts are inactive until clicked) > if the container app wants to. It doesn't mention that no OLE apps want to. > I can see why. If you activate an Excel graph in Word when it scrolls onto > the screen, you need to launch Excel. That's a nontrivial operation. The > real question is, will you be able to init all your parts fast enough. The > OLE folks don't think so, which is why they advocate static pictures, no > implicit activation and printing from the pictures. The OLE people think this way because they are trying to move dinosaurs around with a fly whisk. OpenDoc breaks apps down into more manageable chunks - or at least will if programmers use it the way it was intended. Launching a spreadsheet part (viewer not editor is the minimum needed) handler should be a much more lightweight operation than launching Excel. Another strategy would be to make resolution in a more general sense the deciding factor on whether you need a part handler - to print to higher resolution device, to open the object to edit it, to display it on a screen with more colours etc. -- Philip Machanick philip@cs.wits.ac.za Department of Computer Science, University of the Witwatersrand 2050 Wits, South Africa (at University of Cape Town 4 July-7 Nov) phone 27(11)716-3309 fax 27(11)339-7965 --------------------------- >From alain@cs.uchicago.edu (Alain Aslag Roy) Subject: Linking with QuickTime.xcoff for the power pc Date: Tue, 13 Sep 1994 03:44:44 GMT Organization: It lurks in the night. I've been working on an application that uses QuickTime 2.0 on the power macintosh. I figured out how to link with the Import library for quicktime (I got it from the Beta CD) and it works fine. Until I launch the program in a low memory situation. Then I get a message about not being able to find the QuickTime Libary or something like that. If I free up some memory, I don't have that problem. Now, I'd really like it if I could handle this error on my own instead of the system handling it for me. My program doesn't require QuickTime, but can use it if it's there. Is there a way for me to prevent the system from reporting this error and for me to handle it myself? I'm using MPW with PPCC (The RISC SDK), the most recent version, if that matters. Thanks in advance for any advice. -alain +++++++++++++++++++++++++++ >From zstern@adobe.com (Zalman Stern) Date: Tue, 13 Sep 1994 20:58:20 GMT Organization: Adobe Systems Incorporated Alain Aslag Roy writes [Program fails to launch when QuickTime library cannot be loaded, say for low memory reasons, or because it is not isntalled.] > Now, I'd really like it if I could handle this error on my own instead of the > system handling it for me. > > I'm using MPW with PPCC (The RISC SDK), the most recent version, if that > matters. You want to make the linkage of the library "weak". This is done by adding a tilde after the library name in the argument to the makepef command. Like so: makepef <...> -l QuickTimeLib.xcoff=QuickTimeLib~ Figuring out if the library is actually there or not is another story. In theory there is a gestalt selector to do this, but it doesn't work. Instead you should test if a routine you use from the QuickTime library is NULL or not. The whole mass of code I put in to MacApp to deal with this looks like so: /* Start with the Gestalt in as for a 68k. */ theConfiguration.hasCompressionManager = Gestalt (gestaltCompressionMgr, response) == noErr; /* For PowerPC make sure we can actually call QuickTime if its there... * This piece of code is incredibly screwed up because we link to QuickTime * weakly. Meaning that if the library is not there, undefined externals * referencing that library do not keep us from running. However, there * seems to be a case where the library is there, but cannot be loaded due * to a lack of memory. In this case, the gestalt call says its there, but * the routines we call are still NULL. So what the hell, I just check one * of the routines that is supposed to be in that library. */ #ifdef __powerc theConfiguration.hasCompressionManager = (theConfiguration.hasCompressionManager && (Gestalt(gestaltQuickTimeFeatures, response) == noErr) && (response & (1 << gestaltPPCQuickTimeLibPresent)) && &CustomGetFilePreview != NULL); #endif -- Zalman Stern zalman@adobe.com (415) 962 3824 Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900 Please do not change color while I am talking to you -- MC 900 Ft Jesus. --------------------------- >From gmcgath@condes.mv.com (Gary McGath) Subject: Multiple monitors Date: Sun, 4 Sep 1994 13:14:42 GMT Organization: Conceptual Design As a result of my unusual monitor configuration, I've developed an awareness of problems that often crop up in applications whose programmers fail to think about multiple monitors. Here are my suggestions for good multiple monitor programming style; I welcome additions and comments. Perhaps someone would care to throw in some suggestions for Pivot monitors to go with these? To figure the maximum window size, check the GrayRgn, not ScreenBits. The user should be able to size a window across two monitors, or to stretch it to the dimensions of a screen that may be bigger than the main screen. Don't assume that just because the main device is monochrome, the system doesn't have color. Use GetMaxDevice. If it's important that a new window be displayed in color, put it on the screen with the greatest depth. This is especially important with non-draggable dialogs. It's frustrating to have a color picker window nailed to a monochrome monitor when there's a perfectly good color monitor next to it. If you have a graphic with both monochrome and color versions, check which device it's being drawn to when deciding which version to use. (Some calls, such as PlotCIcon, will do this automatically.) Clicking on the zoom box of a window should position it in the screen which it's currently occupying, rather than always hauling it to the main device. (Defining which screen a window is occupying in the general case is tricky, to be sure.) Remember that if your window occupies the whole main screen, it doesn't necessarily occupy all of the desktop. It's still possible for the user to click outside the window. When bringing up a window, be sure that at least its title bar is on the screen. If the user plays with the Monitors control panel and then reboots, a window which was on screen last time may be out of reach this time. Some old DA's are especially bad about this, and can permanently vanish into offscreen limbo. -- Gary McGath gmcgath@condes.mv.com +++++++++++++++++++++++++++ >From h+@nada.kth.se (Jon W{tte) Date: Mon, 05 Sep 1994 17:34:25 +0200 Organization: Royal Institute of Something or other >To figure the maximum window size, check the GrayRgn, not ScreenBits. Yes. Most apps that do this wrong, can be coerced by using the command key when resizing the window. >Don't assume that just because the main device is monochrome, the system >doesn't have color. Use GetMaxDevice. However, GetMaxDevice crashes on non-color machines, and if those are a factor, you have to check some more. I recently did an about box for someone else, which went pretty much like this: depth = 1 ; Is there color QD? If yes, is there QuickTime? If yes, depth = depth of GetMaxDevice() If depth < 8, depth = 1 Load and draw pictures using b/w if depth = 1, else color. If depth is 8, use the palette of the screen the window's on (which is the deepest screen, to show off the colors :-) QuickTime is required because of the JPEG about picture. Code and images for 24-bit color and black/white come in at under 40k! >If you have a graphic with both monochrome and color versions, check >which device it's being drawn to when deciding which version to use. >(Some calls, such as PlotCIcon, will do this automatically.) Use DeviceLoop() >Clicking on the zoom box of a window should position it in the screen >which it's currently occupying, rather than always hauling it to the Yes! The screen with the most pixels of the window on it. It should also move the window as little as possible, i e first grow it down/right until it can grow it no more; then keep growing up-left 'til the screen is full. >When bringing up a window, be sure that at least its title bar is on the >screen. If the user plays with the Monitors control panel and then Yeah, this is a killer. I have an FKEY that staggers all visible app windows. Can do funky things to palettes, but saves the day occasionally :-) Cheers, / h+ -- Jon Wätte (h+@nada.kth.se), Hagagatan 1, 113 48 Stockholm, Sweden This signature is kept shorter than 4 lines in the interests of UseNet S/N ratio. +++++++++++++++++++++++++++ >From neil_ticktin@xplain.com (Neil Ticktin) Date: Mon, 5 Sep 1994 17:54:25 GMT Organization: MacTech Magazine/Xplain Corporation In article , gmcgath@condes.mv.com (Gary McGath) wrote: >> As a result of my unusual monitor configuration, I've developed an >> awareness of problems that often crop up in applications whose >> programmers fail to think about multiple monitors. Here are >> my suggestions for good multiple monitor programming style; I >> welcome additions and comments. Perhaps someone would care to throw >> in some suggestions for Pivot monitors to go with these? Gary, We found the similar things. We published an article about how to support multiple monitors a couple issues back. We hope, as you do, that people will provide more support for multiple monitors -- it's annoying when they don't. Thanks, Neil - --------------------------------------------------------------------- Neil Ticktin, MacTech Magazine (formerly MacTutor) PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: 310-575-0925 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain custservice@xplain.com * editorial@xplain.com * adsales@xplain.com marketing@xplain.com * accounting@xplain.com * pressreleases@xplain.com progchallenge@xplain.com * publisher@xplain.com * info@xplain.com +++++++++++++++++++++++++++ >From jonpugh@netcom.com (Jon Pugh) Date: Mon, 5 Sep 1994 20:02:00 GMT Organization: Will hack for food Gary McGath (gmcgath@condes.mv.com) wrote: > When bringing up a window, be sure that at least its title bar is on the > screen. If the user plays with the Monitors control panel and then > reboots, a window which was on screen last time may be out of reach > this time. Some old DA's are especially bad about this, and can > permanently vanish into offscreen limbo. I only require that the 16 bits or so of the left or right end of the title bar be on screen. This allows you to slam a window offscreen into the bottom corners of the screen and remain there after it is closed and reopened. I suppose it doesn't catch the big window with both ends off screen, but I don't think anyone's managed to get that and not minded it being reset. We regularly get into window wars at work via Projector. My compatriot has his menubar on the little color screen (for some of the reasons outlined before) and edits on a large b&w monitor next to it. Then he checks in and I open the window half off my little color monitor and not on my 16" color monitor. Since the title bar is on screen, it doesn't move though. I don't see a good way to fix this without saving the entire monitor setup. Jon +++++++++++++++++++++++++++ >From Charles B. Cranston Date: 6 Sep 1994 19:55:23 GMT Organization: Network Infrastructure U Maryland College Park It may be worth mentioning that there is an Apple Human Interface Note on the right things to do for multiple monitors, and this information has also been integrated into the McGraw Hill "Macintosh Human Interface Guidelines", mostly in chapter 5. It is amazing how much software does NOT do the right things, even MPW didn't zoom correctly until 3.3 came out... +++++++++++++++++++++++++++ >From joseph@joebloe.maple-shade.nj.us (Joseph "Moof-in'" Hall) Date: Thu, 8 Sep 94 01:36:24 MST Organization: comp.sys.mac.programmer.moof Advocacy In article (comp.sys.mac.programmer), jonpugh@netcom.com (Jon Pugh) writes: ) We regularly get into window wars at work via Projector. My compatriot has ) his menubar on the little color screen (for some of the reasons outlined ) before) and edits on a large b&w monitor next to it. [...] I've wondered why apps don't save window position as an offset relative to the nearest corner or something like that. It would certainly solve some window placement disputes. =============== O Fortuna, velut Luna, statu variabilis =============== uunet!joebloe!joseph (602) 732-2549 day joseph%joebloe@uunet.uu.net 1400 N Alma School #163 Chandler, AZ 85224 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * Be hip! Support comp.sys.mac.programmer.moof! +++++++++++++++++++++++++++ >From jonpugh@netcom.com (Jon Pugh) Date: Sat, 10 Sep 1994 22:10:28 GMT Organization: Will hack for food Joseph "Moof-in'" Hall (joseph@joebloe.maple-shade.nj.us) wrote: > I've wondered why apps don't save window position as an offset > relative to the nearest corner or something like that. It would certainly > solve some window placement disputes. That doesn't save your window size. It's simple to just store the rect. Of course, it wouldn't be much harder to store the offset point and the window height and width point either. Sounds like it's time for some experimentation to see if this would buy you anything. It sounds identical in most cases though. Jon +++++++++++++++++++++++++++ >From ari@world.std.com Date: Thu, 15 Sep 1994 06:02:23 GMT Organization: The World Public Access UNIX, Brookline, MA In article <9668AA910721.386931@klkmac014.nada.kth.se>, Jon W{tte wrote: >>If you have a graphic with both monochrome and color versions, check >>which device it's being drawn to when deciding which version to use. >>(Some calls, such as PlotCIcon, will do this automatically.) > >Use DeviceLoop() While working on my popup CDEF, I ran into a problem drawing a color image from an offscreen graphics world when the destination rectangle spanned two monitors with different depths. The problem arose because the offscreen gworld was created with the depth of the deepest monitor. The portion of the image that was copied to the color monitor was displayed perfectly. But the portion of the image that was copied to the black and white monitor was real ugly, since all the color pixels got mapped to black. The only solution I could find was to use a DeviceLoop when drawing an image that spans monitors of different depths. Unfortunately, this meant that I couldn't use the offscreen gworld, and the image flickers if it spans monitors with different depths. -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. +++++++++++++++++++++++++++ >From ari@world.std.com Date: Thu, 15 Sep 1994 06:08:21 GMT Organization: The World Public Access UNIX, Brookline, MA In article <34ihfb$8c2@haven.umd.edu>, Charles B. Cranston wrote: >It is amazing how much software does NOT do the right things, >even MPW didn't zoom correctly until 3.3 came out... Well, I still think MPW misses the mark. And SADE and HyperCard are *very* annoying. I put the Worksheet window in SADE on my small monitor and put the source code window on my big monitor. Then, when I hit command-F to search for something, the find dialog pops up way-over-there on the little monitor; BLECH! HyperCard does similar stupid things. And THINK C 7.0 even stuck my windows OFF SCREEN!!! YES, I OPENED A WINDOW AND ITS TITLE BAR WAS HIDDEN BEHIND THE MENU BAR! Fortunately, I've been using macs for far too long, and promptly broke into MacsBug and set MBarHeight to 0 and dragged the windows back to somewhere more accessable. (The alternative of editing the menu record with MacsBug, with the associated structure and content regions, etc. just was out of the question; I don't know what I would have done with a PowerPC!) -- Ari Halberstadt ari@world.std.com One generation passes away, and another generation comes: but the earth abides for ever. -- Ecclesiastes, 1:4. --------------------------- >From qsi@cnh.wlink.nl (Peter Kocourek) Subject: The 'aete' resource and the Script Editor Date: 07 Sep 94 01:24:16 + Organization: Care Net Holland Hi, I just had strange problem with the Script Editor and the 'aete' resource. I had already added a few events to the aete resource, and everything was working fine. Then I added a simple event, with no required parameters or any fancy stuff. That's when the weirdness began. When I sent the event to myself, everything was fine. But when I tried to send the event from the Script Editor, my event handler returned errAEParamMissed, when I was making the routine check for missed parameters. Yet I had indicated in the aete, that the event did not have any parameters... So, trying to find out what kind of parameter the Script Editor was passing along, I discovered that the type of the missed parameter was 'keyw', and the type of keyword I'd missed was '----'. I merrily put in code to get the parameter, but that call to AEGetParamPtr came back with errAEDescNotFound, even though I had just extracted the relevant information about the missing parameter from the AppleEvent! I checked the Event Log in the Script Editor, and sure enough, when sending my event "foo", the Log said it had sent "foo current application". And that despite the fact that it said in the aete resource that I wanted no parameters, direct or otherwise. Ultimately, after a lot of frustration, I found the cause of the problem: in the aete resource, I had specified a the direct parameter as being of type typeNull, but I had the "is optional" flag off. Once I switched that on, everything worked fine. Is this the way the Script Editor is supposed to behave? I thought that a typeNull type indicated that no parameter was to be included under any circumstances. And the errAEDescNotFound still bothers me. If I find the type of the missed parameter, surely I should be able to extract it from the AppleEvent; in this case the AE Manager seemed to be telling me that there is an additional parameter in there, but that it can't find it. What's going on? YHS:QSI! +++++++++++++++++++++++++++ >From jonpugh@netcom.com (Jon Pugh) Date: Sat, 10 Sep 1994 21:53:36 GMT Organization: Will hack for food Peter Kocourek (qsi@cnh.wlink.nl) wrote: > I just had strange problem with the Script Editor and the 'aete' resource. > [snip] > Ultimately, after a lot of frustration, I found the cause of the problem: in > the aete resource, I had specified a the direct parameter as being of type > typeNull, but I had the "is optional" flag off. Once I switched that on, > everything worked fine. Ed Lai has been telling people to make sure they set the optional bit if they used a direct parameter of typeNull (i.e. none) for quite some time. I guess now we know why. ;) Regardless of whether it is intential or not, it is the way it works, so be sure to do this. Jon +++++++++++++++++++++++++++ >From lai@apple.com (Ed Lai) Date: 14 Sep 1994 16:16:31 GMT Organization: Apple In article <4cb_9409071502@cnh.wlink.nl>, qsi@cnh.wlink.nl (Peter Kocourek) wrote: > Hi, > > I just had strange problem with the Script Editor and the 'aete' resource. I > had already added a few events to the aete resource, and everything was > working fine. Then I added a simple event, with no required parameters or any > fancy stuff. That's when the weirdness began. > > When I sent the event to myself, everything was fine. But when I tried to send > the event from the Script Editor, my event handler returned errAEParamMissed, > when I was making the routine check for missed parameters. Yet I had indicated > in the aete, that the event did not have any parameters... > > So, trying to find out what kind of parameter the Script Editor was passing > along, I discovered that the type of the missed parameter was 'keyw', and the > type of keyword I'd missed was '----'. I merrily put in code to get the > parameter, but that call to AEGetParamPtr came back with errAEDescNotFound, > even though I had just extracted the relevant information about the missing > parameter from the AppleEvent! > > I checked the Event Log in the Script Editor, and sure enough, when sending my > event "foo", the Log said it had sent "foo current application". And that > despite the fact that it said in the aete resource that I wanted no > parameters, direct or otherwise. > > Ultimately, after a lot of frustration, I found the cause of the problem: in > the aete resource, I had specified a the direct parameter as being of type > typeNull, but I had the "is optional" flag off. Once I switched that on, > everything worked fine. > > Is this the way the Script Editor is supposed to behave? I thought that a > typeNull type indicated that no parameter was to be included under any > circumstances. And the errAEDescNotFound still bothers me. If I find the type > of the missed parameter, surely I should be able to extract it from the > AppleEvent; in this case the AE Manager seemed to be telling me that there is > an additional parameter in there, but that it can't find it. What's going on? > > > YHS:QSI! This is not a problem with the script editor. I always consider this to be a problem of AppleScript, although I was told there are reason to do it that way so it can not be fixed. As you discoverd, if the direct parameter is of type typeNull, then AppleScript would send a typeNull as the direct parameter. The AppleEvent manager checks every parameter you have accessed. If you ask for parameter missed, then it returns the keyword '----'. When you try to get the direct parameter, AEM found the type to be typeNull, which means no parameter, so AEM got fooled has say errAEDescNotFound. The last part can be considered to be an AEM bug, although it is almost excusable. -- /* Disclaimer: All statments and opinions expressed are my own */ /* Edmund K. Lai */ /* Apple Computer, MS303-3A */ /* 20525 Mariani Ave, */ /* Cupertino, CA 95014 */ /* (408)974-6272 */ zW@h9cOi --------------------------- >From eschen@molbio.cbs.umn.edu (Art Eschenlauer) Subject: can extensions send appleevents? Date: Wed, 14 Sep 1994 13:07:32 GMT Organization: University of Minnesota, Twin Cities Last night I was plughing around in my System 7.0.1 software, looking at SIZE resources. I found that the Finder has the HighLevelEventAware flag set but that the System does not. The dogma is that to send AppleEvents success- fully using AESend, an 'application' must have the HighLevelEventAware flag set. I want to send appleevents from an extension that is called via patches to drawmenubar, systemmenu, and menuselect from within ANY application (that uses the menubar). How will I get in trouble here? 1. Will I be hosed if the calling app is not HighLevelEventAware? 2. Will I be hosed all the time because the system is not HighLevelEventAware? 3. By some bizarre quirk of fate, will I be successful all the time because the Finder is HighLevelEventAware (I want to send 'odoc' events) or because code resources aren't restricted by th HighLevelEventAware bit? 4. Am I hosed all the time because code resources cannot send appleevents? Thanks! -Art -- eschen@molbio.cbs.umn.edu (Art Eschenlauer, U of M Agronomy & Plant Genetics) "The only things that you can take with you are those that you have given away." - Sign under Peter Bailey's picture in "It's a Wonderful Life" +++++++++++++++++++++++++++ >From tnleeuw@cs.vu.nl (Leeuw van der TN) Date: Wed, 14 Sep 1994 14:42:54 GMT Organization: Fac. Wiskunde & Informatica, VU, Amsterdam Maybe you could make your Control Panel communicate with a background application, that sends the AppleEvents to the Finder? I think you can use Gestalt for that. Just a passing thought. --Tim van der Leeuw tnleeuw@cs.vu.nl +++++++++++++++++++++++++++ >From Jens Alfke Date: Wed, 14 Sep 1994 20:52:09 GMT Organization: Apple Computer Art Eschenlauer, eschen@molbio.cbs.umn.edu writes: > I want to send appleevents from an extension that is called via patches > to drawmenubar, systemmenu, and menuselect from within ANY application (that > uses the menubar). How will I get in trouble here? The Apple Event Manager doesn't care what _code_ is running, only what _process_ is active. If your patch tries to send an AE, what happens depends on what app (the Finder is an app) is currently active. If it's AE-aware (as per the SIZE rsrc) you'll succeed. If not, you'll fail, probably with the infamous -903 error. These days most apps are AE-aware, but some still are not. Extensions like QuicKeys and KeyQuencer get around this problem by having a small faceless bg app that they can have send the event for them. Of course, you have to have some way of telling the app to send an event; this probably boils down to some shared memory that you access via a Gestalt selector. --Jens Alfke jens_alfke@powertalk.apple.com "A man, a plan, a yam, a can of Spam ... Bananama!" +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Thu, 15 Sep 1994 00:27:49 -0800 Organization: Integer Poet Software In article , eschen@molbio.cbs.umn.edu (Art Eschenlauer) wrote: > 1. Will I be hosed if the calling app is not HighLevelEventAware? Yes. > 2. Will I be hosed all the time because the system is not HighLevelEventAware? No. > 3. By some bizarre quirk of fate, will > I be successful all the time because the Finder is HighLevelEventAware (I want > to send 'odoc' events) or because code resources aren't restricted by th > HighLevelEventAware bit? No. > 4. Am I hosed all the time because code resources cannot send appleevents? No. Your point #1 is the important one here. When you call the AppleEvent Manager, everything it wants to know is based on the context of the current application. So when your code resource calls the AEM, you can pretend the AEM "thinks" that the current application is making the call. Consequently, if you can arrange for the calling app to be AE-aware, you win. Since Finder is guaranteed to be AE-aware, you might be able to defer sending your AE until Finder becomes the curreent app. (You can call WakeUpProcess against it to make sure this happens quickly.) Receiving AppleEvents is another matter entirely, of course, because your handlers could conflict with the handlers of the current application. There is probably a way to deal with this, but I haven't had to investigate it yet, so I don't know much more than this. There are some folks who know about undocumented interfaces to the AEM which ignore the AE-aware status of the current app. These people claim that even though the interfaces are undocumented there is enough third-party software which uses the interfaces that it's unlikely Apple will be able to break these interfaces in the future. (Probably these people have written some of that software.) I won't names names to protect the innocent, but now that I have mentioned this, perhaps someone will pipe up. -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "Yeah, that's fucking bizarre. That's one I'd never heard before. Not even on the internet." -- Bob Mould, on rumors that he and Grant Hart were lovers when Hüsker Dü broke up, _Spin_ magazine interview, 10/94 +++++++++++++++++++++++++++ >From fixer@faxcsl.dcrt.nih.gov (Chris Disavow Twinkies Tate) Date: Thu, 15 Sep 1994 13:24:10 GMT Organization: DCRT, NIH, Bethesda, MD In article , gurgle@dnai.com (Pete Gontier) writes: > >Receiving AppleEvents is another matter entirely, of course, because your >handlers could conflict with the handlers of the current application. >There is probably a way to deal with this, but I haven't had to >investigate it yet, so I don't know much more than this. As I recall, there's sample code from DTS around called something like "AEcdev," which uses an FBA as an AppleEvent "dispatcher." When you want to send an AE from your (non-application) code, you talk to the FBA (presumably launched at system startup?), and away it goes. Now: I'd have to dig into how the code resource and the FBA communicate. Can standalone code use bare PPC? Or does it have to go through something like the Gestalt mechanism that INIT/cdev combinations frequently use to communicate? Either way, it seems that one could come up with a (small) FBA whose job it is to handle two-way dispatch of AppleEvents, passing them along to the proper standalone-code recipients. The real problem, I think, is tracking which chunk of standalone code is supposed to be receiving a given AppleEvent. Hmmmm.... __________ Christopher Tate fixer@faxcsl.dcrt.nih.gov GM/CS$ d(--) H s:- g+ p0 au a- w+ v+(-*) C++ U+(--) E++ N++ K W---(++)$ M++$ V+ -po+ Y+ t+ 5-- j+ G? tv b+++ D+++ e++ u++(---) h--- f r+++ n+ y+++ +++++++++++++++++++++++++++ >From gurgle@dnai.com (Pete Gontier) Date: Thu, 15 Sep 1994 09:22:01 -0800 Organization: Integer Poet Software In article <1994Sep15.132410.1393@alw.nih.gov>, fixer@faxcsl.dcrt.nih.gov wrote: > As I recall, there's sample code from DTS around called something like > "AEcdev," which uses an FBA as an AppleEvent "dispatcher." When you > want to send an AE from your (non-application) code, you talk to the > FBA (presumably launched at system startup?), and away it goes. > Now: I'd have to dig into how the code resource and the FBA communicate. > Can standalone code use bare PPC? That, in fact, is how the DTS code sample you mention works. :-) > Or does it have to go through something like the Gestalt mechanism that > INIT/cdev combinations frequently use to communicate? And this is how I have done it in the past. PPC is too much of a hassle if you have no event loop. > The real problem, I think, is > tracking which chunk of standalone code is supposed to be receiving a > given AppleEvent. Well, if you have a one-to-one relation between FBA and code resource, there isn't much confusion. However, the original poster was talking about sending an AppleEvent from within a patch to Menu Manager traps. I don't think he's going to succeed in receiving an AppleEvent in such a context no matter how hard he tries. :-) -- Pete Gontier // CTO, Integer Poet Software // gurgle@dnai.com "Yeah, that's fucking bizarre. That's one I'd never heard before. Not even on the internet." -- Bob Mould, on rumors that he and Grant Hart were lovers when Hüsker Dü broke up, _Spin_ magazine interview, 10/94 --------------------------- End of C.S.M.P. Digest **********************