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 1