ftp.mactech.com 2010/ftp.mactech.com.tar/ftp.mactech.com/csmpdigest/csmp-digest-v3-061

Text File | 2010-09-21 | 223KB | 5,541 lines

Received-Date: Thu, 29 Sep 1994 18:36:34 +0100
From: [e-mail] (Francois Pottier)
Subject: csmp-digest-v3-061
To: [e-mail]
Date: Thu, 29 Sep 1994 18:36:24 +0100 (MET)
X-Mailer: ELM [version 2.4 PL23]
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Errors-To: [e-mail]
Reply-To: [e-mail]
X-Sequence: 66

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
([e-mail]).

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 [e-mail] 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 [e-mail]
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
[e-mail]. 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 [e-mail] (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
#  [e-mail]
#===========================================================================
# 'Word Completion', in the spirit of Paul van Mulbregt's BBXT.
#
# Composed by Mark Nagata ([e-mail])
# for Alpha 5.76, 4/22/94.
#
# Modified by Tim van der Leeuw ([e-mail]), 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 ([e-mail]) --
#
# 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 [e-mail] (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$[e-mail]>, [e-mail] (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 [e-mail] (Jonas Wallden)
Date: 31 Aug 1994 15:19:10 GMT
Organization: (none)

[e-mail] (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: [e-mail]  `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.
`.`.`.`.   AppleLink: sw1369                `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.

+++++++++++++++++++++++++++

>From [e-mail] (Bob Bradley)
Date: Tue, 30 Aug 1994 01:50:06 -0800
Organization: SS Software Inc.

In article <34271e$[e-mail]>, [e-mail] (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 [e-mail] (MARK H. LINTON)
Date: 31 Aug 94 15:39:42 EST
Organization: HRB Systems, Inc.

In article <34271e$[e-mail]>, [e-mail] (Jonas Wallden) writes:
> [e-mail] (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 [e-mail] (Jonas Wallden)
Date: 31 Aug 1994 21:35:02 GMT
Organization: (none)

[e-mail] (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: [e-mail]  `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.
`.`.`.`.   AppleLink: sw1369                `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Thu, 01 Sep 1994 14:55:07 +0200
Organization: Royal Institute of Something or other

In article <342t26$[e-mail]>,
[e-mail] (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 ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  Reality exists only in your imagination.


+++++++++++++++++++++++++++

>From [e-mail] (MARK H. LINTON)
Date: 1 Sep 94 08:50:27 EST
Organization: HRB Systems, Inc.

In article <342t26$[e-mail]>, [e-mail] (Jonas Wallden) writes:
> [e-mail] (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 [e-mail] (Daniel Azuma)
Date: Thu, 01 Sep 1994 08:06:29 -0700
Organization: California Institute of Technology

[e-mail] (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..."
  [e-mail]  |              --Philippians 4:4
- ----------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Jonas Wallden)
Date: 1 Sep 1994 15:54:15 GMT
Organization: (none)

[e-mail] (MARK H. LINTON) writes:

>In article <342t26$[e-mail]>, [e-mail] (Jonas Wallden) writes:
>> [e-mail] (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: [e-mail]  `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.`.
`.`.`.`.   AppleLink: sw1369                `.`.`.`.`.`.`.`.`.`.`.`.`.`.`.

+++++++++++++++++++++++++++

>From [e-mail] (Ivan M CaveroBelaunde)
Date: Thu, 1 Sep 1994 16:15:59 GMT
Organization: The World Public Access UNIX, Brookline, MA

[e-mail] (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 ([e-mail])
Avid VideoShop Project Lead
Avid Technology, Inc.

+++++++++++++++++++++++++++

>From [e-mail] (MARK H. LINTON)
Date: 1 Sep 94 13:27:35 EST
Organization: HRB Systems, Inc.

From: [e-mail] (Jonas Wallden)
>>In article <342t26$[e-mail]>, [e-mail] (Jonas Wallden) writes:
>>> [e-mail] (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: [e-mail] (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: [e-mail] (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
<[e-mail]>) 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 [e-mail] (Daniel Azuma)
Date: Thu, 01 Sep 1994 11:37:34 -0700
Organization: California Institute of Technology

[e-mail] (MARK H. LINTON) wrote:

> From: [e-mail] (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..."
  [e-mail]  |              --Philippians 4:4
- ----------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Peter N Lewis)
Date: Fri, 02 Sep 1994 11:37:10 +0800
Organization: NCRPDA, Curtin University

In article <1994Sep1.085027.21786@hrbicf>, [e-mail] (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 <[e-mail]> - Macintosh TCP fingerpainter

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Fri, 02 Sep 1994 09:18:41 +0200
Organization: Royal Institute of Something or other

In article <344tf7$[e-mail]>,
[e-mail] (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 ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  Reality exists only in your imagination.


+++++++++++++++++++++++++++

>From [e-mail] (Rich Siegel)
Date: Fri, 2 Sep 1994 18:02:45 GMT
Organization: Bare Bones Software

In article <[e-mail]> [e-mail] (Daniel Azuma) writes:
>> From: [e-mail] (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 % [e-mail]    % President & CEO, Bare Bones Software Inc.
--> For information about BBEdit, finger [e-mail] <--

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Sun, 04 Sep 1994 13:17:08 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (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 ([e-mail]), 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 [e-mail] (Ron Hunsinger)
Date: Wed,  7 Sep 94 03:23:37 PST
Organization: Berkeley Macintosh Users Group

[e-mail] 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 [e-mail] (Kluev)
Date: Wed, 7 Sep 94 20:22:41 +0400
Organization: (none)

In article <[e-mail]>
[e-mail] (Jon W{tte) wrote:

In article <342t26$[e-mail]>,
[e-mail] (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 [e-mail] (Matt Mora)
Date: 8 Sep 1994 09:09:29 -0700
Organization: SRI International, Menlo Park, CA

In article <[e-mail]> [e-mail] (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                       [e-mail]
SRI International                       [e-mail]
333 Ravenswood Ave                    Menlo Park, CA. 94025

+++++++++++++++++++++++++++

>From [e-mail] (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 [e-mail] (Jon W{tte)
Date: Fri, 09 Sep 1994 10:07:15 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (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 ([e-mail]), 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 <[e-mail]>
Date: Sat, 10 Sep 1994 00:02:57 GMT
Organization: Apple Computer

Kluev, [e-mail] 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                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (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 <[e-mail]> - 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 [e-mail] (Kluev)
Date: Sun, 11 Sep 94 20:36:53 +0400
Organization: (none)

In article <34ncvp$[e-mail]>
[e-mail] (Matt Mora) wrote:

> In article <[e-mail]>
> [e-mail] > (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 [e-mail] (Ivan Cavero Belaunde)
Date: 12 Sep 1994 11:28:41 GMT
Organization: Avid Technology, Inc.

In article <[e-mail]>, [e-mail] (Jon
W{tte) wrote:
> In article <[e-mail]>,
> [e-mail] (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 ([e-mail])
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 [e-mail] (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

[e-mail]


---------------------------

>From [e-mail] (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 <[e-mail]>
Date: Wed, 14 Sep 1994 21:29:25 GMT
Organization: Apple Computer

Erik Anton Westwig, [e-mail] 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                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Bob Bradley)
Date: Tue, 13 Sep 1994 05:23:23 -0800
Organization: SS Software Inc.

In article <[e-mail]>,
[e-mail] (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 [e-mail] (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
[e-mail], 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 [e-mail] (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 [e-mail] (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 [e-mail] ( nick.c )
Date: Thu, 18 Aug 94 23:19:42 GMT
Organization: The Pitt, Chemistry

In Article <[e-mail]>, [e-mail] (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: [e-mail]        _/_/ _/  _/  _/   _/  _/_/_/
      eWorld: nick                _/ _/_/  _/  _/       _/ _/
         CIS: 71232,766          _/   _/  _/   _/_/_/  _/   _/

           "Science is nothing but perception" - Plato

+++++++++++++++++++++++++++

>From [e-mail]
Date: 18 Aug 94 23:22:13 MST
Organization: (none)

In article <[e-mail]>, [e-mail] (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 <[e-mail]>
Date: 19 Aug 1994 16:57:26 GMT
Organization: Univ of Wisc-Madison

In article <[e-mail]> ,
[e-mail] 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
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Fri, 19 Aug 1994 22:27:21 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] 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 ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

"TextEdit does everything right."
    ã Jon W{tte


+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Fri, 19 Aug 1994 22:27:23 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (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 ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

"TextEdit does everything right."
    ã Jon W{tte


+++++++++++++++++++++++++++

>From [e-mail] (Ming Mah)
Date: Fri, 19 Aug 1994 21:08:23 GMT
Organization: Alias Research, Inc., Toronto ON Canada

In <[e-mail]> [e-mail] 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 [e-mail] (John Nagle)
Date: Sat, 20 Aug 1994 04:44:10 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] 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 [e-mail]
Date: 20 Aug 94 00:50:01 MST
Organization: (none)

In article <[e-mail]>, [e-mail] (John Nagle) writes:
> [e-mail] 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 [e-mail] (Philip Machanick)
Date: 20 Aug 1994 14:40:56 +0200
Organization: Computer Science Department, University of Cape Town

Ming Mah ([e-mail]) 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
: [e-mail], 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 [e-mail] - 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                      [e-mail]
Computer Science Department, University of he Witwatesrand
2050 Wits, South Africa 27(11)716-3309 fax [phone]
(at University of Cape Town until November: 27(21)650-4058)

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Sat, 20 Aug 1994 19:16:32 GMT
Organization: Dr. Stupid Meets Frankenstein

In article <334tko$[e-mail]>
[e-mail] (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. [e-mail]
--Private activities on the net --

+++++++++++++++++++++++++++

>From [e-mail] (Michael(tm) Hamel)
Date: Sat, 20 Aug 1994 21:06:17 GMT
Organization: University of Otago

[e-mail] 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
[e-mail]

"The Galaxy's a fun place. You'll need to have this fish in your ear."

+++++++++++++++++++++++++++

>From [e-mail]
Date: 20 Aug 94 16:51:02 MST
Organization: (none)

In article <[e-mail]>, [e-mail] (Michael(tm) Hamel) writes:
> [e-mail] 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 [e-mail] (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 <[e-mail]>, [e-mail] (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 [e-mail] (Neil Ticktin)
Date: Sun, 21 Aug 1994 03:42:37 GMT
Organization: MacTech Magazine/Xplain Corporation

In article <[e-mail]>,
[e-mail] 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: [phone]
 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain
  [e-mail] * [e-mail] * [e-mail]
[e-mail] * [e-mail] * [e-mail]
   [e-mail] * [e-mail] * [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Sun, 21 Aug 1994 15:06:39 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, [e-mail]
(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!"      <[e-mail]>     "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 [e-mail] (Philip Machanick)
Date: 21 Aug 1994 11:07:22 +0200
Organization: Computer Science Department, University of Cape Town

John Nagle ([e-mail]) 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                      [e-mail]
Computer Science Department, University of he Witwatesrand
2050 Wits, South Africa 27(11)716-3309 fax [phone]
(at University of Cape Town until November: 27(21)650-4058)

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Sun, 21 Aug 1994 13:28:08 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (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 ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
    Not speaking for IBM.


+++++++++++++++++++++++++++

>From [e-mail] (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 [e-mail]
Date: 21 Aug 94 15:55:16 MST
Organization: (none)

In article <337tvs$[e-mail]>, [e-mail] (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 [e-mail] (John Nagle)
Date: Mon, 22 Aug 1994 01:50:25 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Philip Machanick) writes:
>John Nagle ([e-mail]) 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 [e-mail] (Kent Sandvik)
Date: Mon, 22 Aug 1994 03:07:52 GMT
Organization: Dr. Stupid Meets Frankenstein

In article <[e-mail]>
[e-mail] (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, [e-mail]
--Private activities on the net, not related to the company I work for
--

+++++++++++++++++++++++++++

>From [e-mail] (Neil Ticktin)
Date: Mon, 22 Aug 1994 06:26:02 GMT
Organization: MacTech Magazine/Xplain Corporation

In article <337tvs$[e-mail]>, [e-mail] (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: [phone]
 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain
  [e-mail] * [e-mail] * [e-mail]
[e-mail] * [e-mail] * [e-mail]
   [e-mail] * [e-mail] * [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Philip Machanick)
Date: 21 Aug 1994 11:59:23 +0200
Organization: Computer Science Department, University of Cape Town


Kent Sandvik ([e-mail]) wrote:
: In article <334tko$[e-mail]>

: 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                      [e-mail]
Computer Science Department, University of he Witwatesrand
2050 Wits, South Africa 27(11)716-3309 fax [phone]
(at University of Cape Town until November: 27(21)650-4058)

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Mon, 22 Aug 1994 14:54:24 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (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 ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
 "Don't Deal with a Dragon."


+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Tue, 23 Aug 1994 00:41:13 GMT
Organization: Dr. Stupid Meets Frankenstein

In article <3378hr$[e-mail]>
[e-mail] (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, [e-mail]
--Private activities on the net, not related to the company I work for
--

+++++++++++++++++++++++++++

>From [e-mail] (Heeren H Pathak)
Date: Tue, 23 Aug 1994 13:26:19 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>, John Nagle <[e-mail]> 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 <[e-mail]>
Date: Wed, 24 Aug 1994 00:39:33 GMT
Organization: Apple Computer

[e-mail] 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                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (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 [e-mail].

Regards,
Jeff Alger

Jens Alfke ([e-mail]) wrote:
: [e-mail] 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                           [e-mail]
:                    "A man, a plan, a yam, a can of Spam ... Bananama!"
--


+++++++++++++++++++++++++++

>From [e-mail] (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 [e-mail] (eric larson)
Subject: Lets talk OpenDoc
Date: 21 Aug 94 08:27:51 -
Organization: FidoNet: Shockwave Rider, USR V.Everything [phone]

 >      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 [e-mail] (John Nagle)
Date: Mon, 29 Aug 1994 19:04:43 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (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 <[e-mail]>
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
             [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Tue, 30 Aug 1994 05:28:45 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

E.J. Draper <[e-mail]> 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 [e-mail] (Brian Quinlan)
Date: 30 Aug 94 07:09:52 GMT
Organization: Simon Fraser University

E.J. Draper <[e-mail]> 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 [e-mail] (Joel D. Elkins)
Date: Tue, 30 Aug 1994 09:39:27 -0600
Organization: NewMedia, Inc., Indianapolis, IN

In article <33tgfn$[e-mail]>, E.J. Draper
<[e-mail]> 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.
[e-mail]                 |                 Indianapolis, IN

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Tue, 30 Aug 1994 12:47:01 -0500
Organization: One Step Beyond

[e-mail] (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          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Lentz)
Date: 30 Aug 1994 16:45:54 GMT
Organization: Northwestern University, Evanston, Illinois, USA

In article <33tgfn$[e-mail]>,
E.J. Draper  <[e-mail]> 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
--
[e-mail]            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 [e-mail] (John Nagle)
Date: Tue, 30 Aug 1994 16:40:42 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (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 [e-mail] (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...

[e-mail] (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.

[e-mail] (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. :-)

[e-mail] (John Nagle) wrote:
> E.J. Draper <[e-mail]> 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.

[e-mail] (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: [e-mail] | link: susser.j | phone: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Tue, 30 Aug 1994 20:33:09 +0200
Organization: Royal Institute of Something or other

In article <33tgfn$[e-mail]>,
E.J. Draper <[e-mail]> 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 ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  Reality exists only in your imagination.


+++++++++++++++++++++++++++

>From [e-mail]
Date: 30 Aug 94 11:18:38 MST
Organization: (none)

In article <[e-mail]>, [e-mail] (John Nagle) writes:
> [e-mail] (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 <[e-mail]>
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
             [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ted C Brown)
Date: 30 Aug 1994 19:15:12 GMT
Organization: The Ohio State University

In article <33vno2$[e-mail]>,
Robert Lentz <[e-mail]> wrote:
>In article <33tgfn$[e-mail]>,
>E.J. Draper  <[e-mail]> 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 [e-mail] (Edward Cessna)
Date: Tue, 30 Aug 1994 12:54:59 -0700
Organization: Disney

>     An OpenDoc or OLE-based creation system for multimedia content
> would make sense, but that's an extension of the word processor metaphor.
>
>     The whole multi-source document concept is useful, but only for things
> that naturally have a document metaphor.

This also applies to client/server applications where the data being
retrieved from a database determines what the user sees on the screen.

> [e-mail] (Joel D. Elkins) wrote:
>
> Aside...
>   Q: What is the difference between a "form" and a "document"?
>   A: A form only has 1 page, but document's have a lot!  :-)

There is a bigger difference between forms and documents: forms have a
rigid structure whereas documents do not. You can change the structure of
a document but *not* of a form (I wish I could change the structure of my
1040 every April 15--sigh).

You could have a database query part that could be embedded within an
OpenDoc document. Editing the query part would mean change the query
statement defined within it. What you would see in the document would be
the results of the query. As for a database browser as an OpenDoc part, I
don't believe that this would yield anything meaningful (akin to putting
the finder in a OpenDoc document?). If anything, a database browser (a
database application) would end up being an OpenDoc container application.

When I use the term "database browser" I mean an application that could
visit the various data within a database, allow the user to select
something and, optionally, modify it. The user would also have the ability
to delete old information and to insert new information.

I'm not trying to imply that OpenDoc isn't useful to client/server
applications, I just do not see how the document-centered approach would
be practical. Other aspect of OpenDoc, like distributive objects, would be
very useful however.

-- Edward Cessna
-- Walt Disney Pictures and Television

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Tue, 30 Aug 1994 22:29:13 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (Joel D. Elkins) wrote:

>And what about client-server based apps, much in use by corporations today,
>for which the "document" paradigm really doesn't apply. Most of
>the c/s apps I've seen are more "forms" based. How will OpenDoc improve
>such apps? Unless it does, I don't see widespread acceptance by corporations
>for their in-house development efforts.

This is IDEAL for OpenDoc; you'd make forms as stationery of
linked parts with AppleScript as the glue in the middle.
Because you then can make a form of ANYTHING, you gain instant
multimedia forms!

Cheers,

                    / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  Reality exists only in your imagination.


+++++++++++++++++++++++++++

>From E.J. Draper <[e-mail]>
Date: 30 Aug 1994 20:51:18 GMT
Organization: U.T.M.D. Anderson Cancer Center


>That's also a collection of an editor part, a news collection
>part, ...

It seems that a great deal of the hype that surrounded AppleEvents before
the release of System 7 is being recycled in OpenDoc propaganda.
Everyone heard that they were going to be able to use one spell check
program for all their needs.  They'd also use one graphics program, one
communications program, etc., etc..  Of course, all these programs were
going to communicate together to enrich the Macintosh experience and open
new profit channels for Apple and their developers.  So now we've got
shared libraries and the AppleEvent performance bottleneck is diminished.
 I'm still skeptical ...

>Your news reader comes with the SimpleText text edittig part.
>Unfortunately, this part does not handle parts larger than 32k,
>so to decode alt.binaries.pictures.erotica.jello, you instead
>use the Alpha text editting part which handles larger
>documents, and write a small script that scans the news
>collection part for multi-part postings, uses Alpha to
>concatenate them, uses the StuffIt mangling part to get an
>image which you display in the JPEGView picture display part.

This solution would be inelegant, overly complex, neophyte hostile, and
slow.  What's so compelling about it?


BTW- I did read the OpenDoc white paper.


      |E|J-  ED DRAPER
 rEpar|D|<-  Radiologic/Pathologic Institute
             The University of Texas M.D. Anderson Cancer Center
             [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Edward Cessna)
Date: Tue, 30 Aug 1994 14:21:56 -0700
Organization: Disney

In article <[e-mail]>, [e-mail]
(Joshua Susser) wrote:

> Actually, OpenDoc has a great story for in-house MIS types.  They have two
> big desires - being able to use COTS (Commercial Off The Shelf) Software,
> and getting a vertical solution for their special needs.  Notice these two
> desires are in direct conflict.  But with component technology like
> OpenDoc, you can buy a set of COTS part editors and maybe only have to
> write one or two special purpose ones in house.  Then create standard
> stationery using these chosen editors, write some scripts to integrate the
> parts functionality, and presto, it's an instant vertical application,
> custom made for your department with mostly COTS components.

Interesting concept. So, when the user double-clicks on the stationery, a
document will be created and they will be able to do their work. Question:
is the structure of the document fixed? In other words, could the user
accidentally delete or change one or more of the part editors? If the
answer is yes, then this is a totally wash-out for our in-house users! We
would spend more time helping the users and they would get annoyed at
being able to "destroy" the app.

> As for client-server, OpenDoc supports the concept of what we've been
> calling an "embedded client".  Create a part editor that can operate as a
> client for a remote server.

This would be great for our in-house developers but not our users!

> A good rule of thumb for what could and should be written as a part editor is:
> "If it has a user interface, it should be a part."

I wish it was so...

> Well, my compile is done, so back to work...

So quickly? I think I got another 10 minutes to go on my link--sigh.

-- Edward Cessna
-- Walt Disney Pictures and Television

+++++++++++++++++++++++++++

>From [e-mail] (Robert Mah)
Date: Tue, 30 Aug 1994 17:39:12 -0500
Organization: One Step Beyond

[e-mail] (Edward Cessna) wrote:

) There is a bigger difference between forms and documents: forms have a
) rigid structure whereas documents do not. You can change the structure of
) a document but *not* of a form (I wish I could change the structure of my
) 1040 every April 15--sigh).
)
) You could have a database query part that could be embedded within an
) OpenDoc document. Editing the query part would mean change the query
) ...

I think you're putting too much emphasis on the term "document" here.
Nothing in OpenDoc says that the user _must_ be able to manipulate the
layout of the individual parts in a document/form.

That is dependent upon a piece of software called something like the
"framework" or "layout" app.  You could easily, create a "forms" based
part layout application that prevented the user from modifing the
underlying part layout/structure.

Cheers,
Rob
_____________________________________________________________________
Robert S. Mah           Software Development          +1.212.947.6507
One Step Beyond        and Network Consulting          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (AFC JLloyd)
Date: 30 Aug 1994 17:40:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <33vusc$[e-mail]>, E.J. Draper
<[e-mail]> writes:

>>Actually, OpenDoc has a great story for in-house MIS types.
>
>Wrong. Users who *do not* build *DOCUMENTS* will be annoyed at having to
>artificially create documents and incorporate parts just to get something
>done. The result of every human-machine interaction is *not* a document.
>OpenDoc is an interesting and useful addition to the concept of building
>documents, but it's only interesting and useful in those terms.

Perhaps the term "document" is misleading you.  If you grok
object-oriented programming, substitute the concept "object" for a while.
In its most basic definition, an "object" is something that has state,
behavior, and identity (see Booch, Object Oriented Design).  A document,
while on disk, is simply state and identity.  When the document is opened,
OpenDoc dynamically binds the state to a part editor, which provides the
behavior.  A stationery document, by the way, is like a class -- a
template for instantiating objects with default state.

If you think in these more generic terms, I expect many of your objections
will disappear.  In all human-machine interaction, the machine is
displaying some visual representation for some state.  If you're concerned
that OpenDoc won't work for things like databases because the database
records can't be placed in Bento containers, then you just need to
consider that the state stored in the Bento containers might be simply a
"pointer" (or query, etc.) to where the data is actually stored.  This
results in "dynamically updated" objects -- the query doesn't change by
the answer does.  Document's like this will need to have a piece of state
that says how often the query should be repeated in order to keep the
displayed data up to date.

>OLE has been around for quite some time and what has the industry
>learned?  How many people are using OLE in mission critical applications
>every day?  How many people are out there screaming for OLE versions of
>Doom and Netware Client tools?

You're right.  No one is screaming for OLE or OpenDoc tools.  This doesn't
mean users won't very much appreciate (and ultimately demand) these kinds
of tools, once they are done right.  As I recall, most DOS users weren't
screaming for GUI's until well after Microsoft did their third iteration
of attempting to copy the Macintosh.  Users don't usually scream for a
solution, they just grumble about problems.  However, once they see a good
solution, they will generally scream if they aren't allowed to use the
solution.  This is even true of DOS users, they're just a bit slow ;-).

>
>>A good rule of thumb for what could and should be written as a part
>editor is:
>>"If it has a user interface, it should be a part."
>
>I vehemently disagree.

Not everything that has a user interface *should* be made into a part, but
just about anything with a UI *could* be made into a part, and doing so
would provide a lot of flexibility that currently doesn't exist.  As in
all engineering endeavors, one should do a costs/benefits analysis first.

Jim Lloyd
[e-mail] -or- [e-mail]



+++++++++++++++++++++++++++

>From [e-mail] (AFC JLloyd)
Date: 30 Aug 1994 20:53:02 -0400
Organization: America Online, Inc. (1-800-827-6364)

In article <340646$[e-mail]>, E.J. Draper
<[e-mail]> writes:

>>That's also a collection of an editor part, a news collection
>>part, ...
>
>It seems that a great deal of the hype that surrounded AppleEvents before
>the release of System 7 is being recycled in OpenDoc propaganda.
>Everyone heard that they were going to be able to use one spell check
>program for all their needs.  They'd also use one graphics program, one
>communications program, etc., etc..  Of course, all these programs were
>going to communicate together to enrich the Macintosh experience and open
>new profit channels for Apple and their developers.  So now we've got
>shared libraries and the AppleEvent performance bottleneck is diminished.
> I'm still skeptical ...

When new technologies are introduced, the "vision" of the "visionaries"
who create the technology has to be communicated.  Visionaries aren't
perfect, they will often be wrong in the details, even if they are right
in the generalities.  So what if we don't yet have a universal spelling
checker?  It may still happen, and it may not.  AppleEvents has already
resulted in a lot of value, and is an enabling technology that will only
become more important over time.  If you feel bitter because of hype that
hasn't become true, I suggest you develop your ability to read between the
lines when presented with hype.

>>Your news reader comes with the SimpleText text edittig part.
>>Unfortunately, this part does not handle parts larger than 32k,
>>so to decode alt.binaries.pictures.erotica.jello, you instead
>>use the Alpha text editting part which handles larger
>>documents, and write a small script that scans the news
>>collection part for multi-part postings, uses Alpha to
>>concatenate them, uses the StuffIt mangling part to get an
>>image which you display in the JPEGView picture display part.
>
>This solution would be inelegant, overly complex, neophyte hostile, and
>slow.  What's so compelling about it?

I won't comment on something as subjective as "elegance".

The solution may be "complex", but a lot is happening.  If a specific
complex problem can be solved by breaking it down into subproblems that
can each be solved with off-the-shelf parts, then complexity is reduced,
not increased.

Requiring a neophyte to do the above from scratch would certainly be
hostile, but if you provide that neophyte with a previously prepared
stationery document, it should be no more hostile than a traditional
solution for this kind of application.

Finally, why should the above be slow?  Almost all of the computation is
I/O bound.  The slowest part of the implementation would be the execution
speed of the scripts, and this would be dominated by the I/O.

Jim Lloyd
[e-mail] -or- [e-mail]


+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Tue, 30 Aug 1994 19:13:38 -0800
Organization: Integer Poet Software

In article <340646$[e-mail]>, E.J. Draper
<[e-mail]> wrote:

> So now we've got shared libraries and the AppleEvent performance
> bottleneck is diminished. I'm still skeptical ...

Do you believe it's the case that AppleEvents and AppleScript haven't
happened according to the hype because of the performance overhead
associated with AppleEvents? If so, I urge you to figure out exactly how
to write an OSA-compliant app without attending a class at Apple DU. It
takes a long time, and that's if you're actually enthusiastic enough about
the ideas to try hard. It's not that the concepts are overly confusing;
the documentation simply isn't good. There are other problems (for example
the lack of compile-time type-checking when building AppleEvents and
Object Specifiers), but the problem is certainly not performance.

--
 Pete Gontier // CTO, Integer Poet Software // [e-mail]

 "Even during a particularly harsh (Colorado) winter... many of the
 300 families in the VCTV (movies-on-demand) trial continued to go
 to video stores." -- [e-mail], in Wired 2.09 p62

+++++++++++++++++++++++++++

>From [e-mail] (Bruce Hoult)
Date: Wed, 31 Aug 1994 13:18:42 +1200 (NZST)
Organization: (none)

E.J. Draper <[e-mail]> writes:
> >> > edit them with appropriate tools.  It's sort of "Publish and Subscribe,
> >> > The Next Generation".  Yes, you can do other stuff, but the touted
>
> How many times a day do you use Publish and Subscribe?
>
> The one, and only, application I have for Publish and Subscribe
> technology is checking the amount of vacation hours I've got coming to me
> from the departmental spreadsheet.  I use it once a week at the most,
> probably more like once a month.

You might not use publish&subscribe.  I know that, as a programmer, doing
programmer things, I don't.

But in the office I support, there is a huge structure of linked spreadsheets,
graphics documents and word processing documents, all linked together by
publish&subscribe.

Eventually, we'd like to have all this managed by a proper database system,
but for now Publish&subscribe is a huge improvement over the alternatives,
even if the performance does stink (especially in Excel).

-- Bruce

+++++++++++++++++++++++++++

>From [e-mail] (Eric Scouten)
Date: Tue, 30 Aug 1994 23:49:14 -0500
Organization: University of Illinois

In article <edcessna-3008941421560001@153.7.11.4>, [e-mail]
(Edward Cessna) wrote:

> In article <[e-mail]>, [e-mail]
> (Joshua Susser) wrote:
>
> > Actually, OpenDoc has a great story for in-house MIS types.
>
> Interesting concept. So, when the user double-clicks on the stationery, a
> document will be created and they will be able to do their work. Question:
> is the structure of the document fixed? In other words, could the user
> accidentally delete or change one or more of the part editors? If the
> answer is yes, then this is a totally wash-out for our in-house users! We
> would spend more time helping the users and they would get annoyed at
> being able to "destroy" the app.

I believe in the OpenDoc white paper, there's a section on "access
control" that addresses just this issue. Can't remember exactly how it's
implemented, but I don't think the system is as naive as you have
suggested.

-Eric

__________________________________________________________________________
Eric Scouten <[e-mail]> * MS Comp Sci, Univ of Illinois

The Pledge of Allegiance says, "liberty and justice for all."
Which part of "all" don't you understand?
   -Rep. Pat Schroeder

+++++++++++++++++++++++++++

>From [e-mail] (Brian Quinlan)
Date: 31 Aug 94 06:20:31 GMT
Organization: Simon Fraser University

[e-mail] (John Nagle) writes:

>    The whole development environment shouldn't be a structured document,
>but source programs might be.  Programs today have parts which are visual
>and parts which are textual, and those parts need to be better connected.
>HyperCard already does this.

I'll have to disagree here. I would love to see my program as a flowchart,
object relation diagram or dataflow diagram. When I click on a box
representing an object, method or function I would get an editor. It could
click on a line and get an interface editor.

>    You could, but why would you want to embed those functions in a
>structured document?  A document is the wrong metaphor for that collection
>of functions.  There's no content in which you're embedding those
>functions.  A multiwindow application is more appropriate.

Your right, I was grasping at straws here.

>    An OpenDoc or OLE-based creation system for multimedia content
>would make sense, but that's an extension of the word processor metaphor.

True, it is most easy to see the benifits for a word processor but
I think it would be helpful in other situations as well. I think that
for OpenDoc to be usefull you need to be working on some sort of document.
When programming you do use documents (rez, source, etc.) and you could
use OpenDoc to integrate these parts into a unified whole.

>    The whole multi-source document concept is useful, but only for things
>that naturally have a document metaphor.

I wish I had read this more carefully before making my last comment!


+++++++++++++++++++++++++++

>From [e-mail] (Mark Hanrek)
Date: 31 Aug 1994 09:23:21 GMT
Organization: The Information Workshop

In article <[e-mail]>, [e-mail]
(Pete Gontier) wrote:

> Do you believe it's the case that AppleEvents and AppleScript haven't
> happened according to the hype because of the performance overhead
> associated with AppleEvents? If so, I urge you to figure out exactly how
> to write an OSA-compliant app without attending a class at Apple DU. It
> takes a long time, and that's if you're actually enthusiastic enough about
> the ideas to try hard. It's not that the concepts are overly confusing;
> the documentation simply isn't good. There are other problems (for example
> the lack of compile-time type-checking when building AppleEvents and
> Object Specifiers), but the problem is certainly not performance.


Pete,

I agree 100%, as someone who has spent a good deal of time with those subjects.

There is a "difficulty barrier" in assimilating the AE/AS technologies
which need not exist.  There could easily be certain materials and/or
utilities that would help make Apple events and related subjects easy to
deal with.

These technologies have now become "fundamental" and "required".

Hopefully Apple will be able to help turn this molasses back into water.

I get the feeling that it is just a matter of time until this boil will
need to be lanced.


- ---- Visibility

I believe "visibility" is one leveraged key to success here.

If we had doohickies that showed Apple events moving around, allowed us to
examine them as AEGizmo-like things on screen, and had materials that made
clear the relationships between AppleScript statements, aete resources,
and object accessors, kinda thing, there'd likely be a lot more happening.

Extrapolating from the past, it will probably be some time before there
any new relief here from Apple. This topic could have been clarified years
ago.

If only we [the development community] had the ability to "turn up the
volume" with these technologies ourselves.


- ---- Interesting Alternative

One major event which has yet to happen is for the Macintosh Development
Community to organize itself, and consequently have for the first time the
realistic opportunity to "see to some of its own needs", drawn from its
own resources.

In many instances, it is not appropriate to expect that Apple is supposed
to provide a solution, or even to have an accurate perception of its
development community.  We accidentally think Apple should solve our
problems or understand us because we are generally powerless to do
anything beyond what our spare time will allow.

But the organized spare time of 10 programmers can accomplish some
significant things.  Or a seed planted by one programmer, and refined 10
times over.

Unfortunately, the event of us organizing ourselves won't likely be able
to occur until true electronic forums are available on the Internet.
Forums provide the means of easily developing consensus, electing
leadership or an agenda, and facilitating collaboration, among other
essentials.

There's that "forum" word again.  Interesting, eh?

:) :)

Mark "a-newsgroup-is-not-a-forum" Hanrek
The Information Workshop

+++++++++++++++++++++++++++

>From [e-mail] (Sak Wathanasin)
Date: Wed, 31 Aug 94 09:57:57 BST
Organization: Network Analysis Ltd


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (John Nagle) writes:
> >You could have a basis upon which you had a newsreader, email and ftp parts.
>     You could, but why would you want to embed those functions in a
> structured document?  A document is the wrong metaphor for that collection

I'd have thought it would be the other way round - the doucment would
be in the mail or news article. Or better, the mail message or news
article would be the document. That's the way it worked with Xerox
Viewpoint - when you got something in the mailbox, you opened it and
there would (sometimes) be a header part and the rest would be the
document. You didn't have to save an attachment or anything; it could
be dragged on to the desktop and operated on as a normal WP document.

Xerox VP had quite a few of the OpenDoc ideas implemented (although OD
goes much further, of course). Appl-centric and doc-centric objects can
co-exist quite happily. Or at least I didn't go around clutching my
head screaming "Oh, my God! Is that an appl or document object?" I just
double-clicked on it and went about my business...


Sak Wathanasin
Network Analysis Limited
178 Wainbody Ave South, Coventry CV3 6BX, UK

Internet: [e-mail]
uucp:     ...!uknet!nan!sw                       AppleLink: NAN.LTD
Phone: [phone] Mobile:[phone]  Fax: [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Wed, 31 Aug 1994 12:07:57 +0200
Organization: Royal Institute of Something or other

In article <edcessna-3008941421560001@153.7.11.4>,
[e-mail] (Edward Cessna) wrote:

>is the structure of the document fixed? In other words, could the user

Yes; you can lock the frames of parts in OpenDoc compound
documents. This is in the white paper.

Cheers,

                / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  Reality exists only in your imagination.


+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Wed, 31 Aug 1994 12:07:59 +0200
Organization: Royal Institute of Something or other

In article <340646$[e-mail]>,
E.J. Draper <[e-mail]> wrote:

>This solution would be inelegant, overly complex, neophyte hostile, and
>slow.  What's so compelling about it?

The neophyte buys a pre-configured stationery/part editor
bundle that behaves as an integrated whole.

The non-neophyte can go in and change whatever he wants in the
bundle to make it fit his needs.

The information systems people in an organization can use
off-the-shelf parts and their own custom glue to create needed
applications.

Cheers,

                / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  Reality exists only in your imagination.


+++++++++++++++++++++++++++

>From [e-mail] (Philip Machanick)
Date: 31 Aug 1994 13:05:05 GMT
Organization: Computer Science Dept, U of Witwatersrand

In article <33tgfn$[e-mail]>, E.J. Draper
<[e-mail]> wrote:

> I can see some interesting applications of OpenDoc technology, but I
> certainly don't feel it's as mind-boggling awesome as the market-droids
> would have us think.  What's OpenDoc going to do for me?  Does a compiler
> part make sense?  How about news reader part?  An email part? A PIM part?

Compiler makes sense - but you are not trying to think of where the
"document" comes in. Look at something like CodeWarrior or ThinkC. Each
item in the project file is a part. You can open it to a window, you can
drag it around in the project. Cut, copy, paste are less obvious - maybe
there is use for these.

News reader the same thing. A newsreader consists of a number of documents
with different behaviours. If you don't use NewsWatcher you may not see
the possibilities. NewsWatcher has features like extract binhex, fetch ftp
from reference in article etc. Such things could be added as new
behaviours in a news document. On the other hand some web viewers allow
you to retrieve news articles. OpenDoc could make for much more seemless
integration of all these things. Imagine: a different part handler for
each kind of URL.

> A Resorcerer part?  How does OpenDoc improve the way that people work
> with information?  Does it make the computer more approachable to novice
> users?  What specific problem is it trying to solve?

It's trying to solve the problem of the monolith application. All these
people who are compaining that the Mac doesn't have proper protection etc.
are right, only they are too late. The application of today is bigger and
more complex than the operating system of the time when schedulers, paging
etc. were invented (VM goes back to the 1950s). What is needed now is a
way of putting together complex behaviour in smaller packages. Look up
Brad Cox's book on software ICs (I forget the title). OpenDoc is a
framework for plugging together software ICs - call it a software PCB. Not
that protection etc. should not be addressed - but _only_ adding
protection and pre-emption would give us a good 1970s OS without
addressing the monolithic app problem. With a good OS underneath it
OpenDoc could turn out to be a dinosaur killer.

The underlying idea is not new. The Xerox Star was programmed like this
and Apple has some of the people who were at Parc at the time pushing it
along.

> It seems like the whole OpenDoc paradigm starts breaking down after you
> get past the Graphic+MooV+Text+Spreadsheet model.

It breaks down when you can't conceive of what you are doing as
manipulating a document. The same thing was true of understanding why
windowed interfaces are better than command line interfaces. Some people
still don't get it :( but some of us are very happy programming in
windowed environments like CodeWarrior.
--
Philip Machanick                   [e-mail]
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa        (at University of Cape Town 4 July-7 Nov)
phone [phone]  fax [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Philip Machanick)
Date: 31 Aug 1994 13:14:39 GMT
Organization: Computer Science Dept, U of Witwatersrand

In article <[e-mail]>, [e-mail] (John Nagle) wrote:
>
>       I think he has a point.  I can imagine a CAD system based on this
> approach, where you click on a subassembly to get to the detailed drawings.
> But that doesn't even fit the OpenDoc model, which is 2D, not 3D.
> What, besides embed stuff in word processor documents, is one really likely
> to do with OpenDoc?

Embed word processing in graphics documents :) In what sense are you
saying OpenDoc is 2D? It is based on frames which can have an arbitrary
shape so I suppose there is potentially a problem implementing a part
picker that is aware of depth. It is possible this could be layered on top
of the model of passing messages to contained parts. Maybe someone who has
gone further into detail could answer this.

>       By the way, how does OpenDoc do version management?

At some point in the history of a document you can start a new edition,
and go back to previous editions.

Since there is supposed to be support for cross-platform collaborative
editing, there ought to be more sophisticated features, but I have seen
nothing about this.

There are a lot of potential problems with OpenDoc but it is a real
attempt at rethinking the document-application relationship. I would like
to see how it develops. I'm less sure about all the weird infrastructure
it's being pinned onto though - a good simple kernel plus an
object-oriented language with better dynamic binding than C++ would have
been a better start.
--
Philip Machanick                   [e-mail]
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa        (at University of Cape Town 4 July-7 Nov)
phone [phone]  fax [phone]

+++++++++++++++++++++++++++

>From [e-mail] (Robert Lentz)
Date: 31 Aug 1994 14:40:12 GMT
Organization: Northwestern University, Evanston, Illinois, USA

In article <340k9e$[e-mail]>,
AFC JLloyd <[e-mail]> wrote:
>...
>When new technologies are introduced, the "vision" of the "visionaries"
>who create the technology has to be communicated.  Visionaries aren't
>perfect, they will often be wrong in the details, even if they are right
>in the generalities.  So what if we don't yet have a universal spelling
>checker?  It may still happen, and it may not.  AppleEvents has already
>resulted in a lot of value, and is an enabling technology that will only
>become more important over time.  If you feel bitter because of hype that
>hasn't become true, I suggest you develop your ability to read between the
>lines when presented with hype.
>...

And complain to those developers that have not seen the light. Would it not
be nice to be able to ask Word to spell check a document for you?

-Robert
--
[e-mail]            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 [e-mail] (Brian Stern)
Date: 31 Aug 1994 15:24:32 GMT
Organization: The University of Texas at Austin, Austin, Texas

In article <[e-mail]>, [e-mail] (Mark
Hanrek) wrote:


< ------ Interesting Alternative
<
< One major event which has yet to happen is for the Macintosh Development
< Community to organize itself, and consequently have for the first time the
< realistic opportunity to "see to some of its own needs", drawn from its
< own resources.

You're right, we're not organized.

< In many instances, it is not appropriate to expect that Apple is supposed
< to provide a solution, or even to have an accurate perception of its
< development community.  We accidentally think Apple should solve our
< problems or understand us because we are generally powerless to do
< anything beyond what our spare time will allow.

Yes, Apple does what it wants, what it has resources to do, and what it
*thinks* we want.

< But the organized spare time of 10 programmers can accomplish some
< significant things.  Or a seed planted by one programmer, and refined 10
< times over.

Absoluteley.

< Unfortunately, the event of us organizing ourselves won't likely be able
< to occur until true electronic forums are available on the Internet.
< Forums provide the means of easily developing consensus, electing
< leadership or an agenda, and facilitating collaboration, among other
< essentials.
<
< There's that "forum" word again.  Interesting, eh?
<

Here's where you lose me.  What does a forum have that a newsgroup doesn't
have?  Don't tell me archiving of every message because most of what's
posted here does not deserve to be saved for posterity.  If you want
something you have to ask for it.  And in a way that people understand
what it is that you're asking for.

I agree with you that the tools available and information available to us
are often inadequate.  Discussing that in this forum (sorry) is one way of
letting the tool/information providers know what we want.  If you want
something from the programming community this also a good place for
discussion of that.  My question is: What do you want?

< :) :)
<
< Mark "a-newsgroup-is-not-a-forum" Hanrek
< The Information Workshop

--
Brian  Stern  :-{)}
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail]
Date: 31 Aug 94 15:29:30 MST
Organization: (none)

In article <[e-mail]>, [e-mail] (Brian Stern) writes:
> In article <[e-mail]>, [e-mail] (Mark
> Hanrek) wrote:
>
>
> < ------ Interesting Alternative
> < There's that "forum" word again.  Interesting, eh?
> <

I think that Mark is hinting at a commercial project that he is working on, and
many of his posts, while they are valid, are simply an attempt to steer folks
to the conclusion that something remarkably similar to what he is planning on
marketing, is actually a good idea and that they would buy it.

I don't know if I am correct or not, but it feels this way to me.

Personally, I think it a REALLY GOOD marketing ploy if I am correct.

>
> Here's where you lose me.  What does a forum have that a newsgroup doesn't
> have?  Don't tell me archiving of every message because most of what's
> posted here does not deserve to be saved for posterity.  If you want
> something you have to ask for it.  And in a way that people understand
> what it is that you're asking for.
>
> I agree with you that the tools available and information available to us
> are often inadequate.  Discussing that in this forum (sorry) is one way of
> letting the tool/information providers know what we want.  If you want
> something from the programming community this also a good place for
> discussion of that.  My question is: What do you want?
>
> < :) :)
> <
> < Mark "a-newsgroup-is-not-a-forum" Hanrek
> < The Information Workshop
>
> --
> Brian  Stern  :-{)}
> [e-mail]



Lawson

+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Thu, 1 Sep 1994 05:14:15 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Philip Machanick) writes:
>It's trying to solve the problem of the monolith application. All these
>people who are compaining that the Mac doesn't have proper protection etc.
>are right, only they are too late. The application of today is bigger and
>more complex than the operating system of the time when schedulers, paging
>etc. were invented (VM goes back to the 1950s). What is needed now is a
>way of putting together complex behaviour in smaller packages. Look up
>Brad Cox's book on software ICs (I forget the title). OpenDoc is a
>framework for plugging together software ICs - call it a software PCB. Not
>that protection etc. should not be addressed - but _only_ adding
>protection and pre-emption would give us a good 1970s OS without
>addressing the monolithic app problem. With a good OS underneath it
>OpenDoc could turn out to be a dinosaur killer.

      PenPoint had the right idea on this.  It's worth looking at how
PenPoint worked internally.  Forget about the pen stuff (PenPoint was the
OS for the now-defunct EO, which failed mostly because a $4000 PDA was
too expensive); the document model in PenPoint looked good.  Like
OpenDoc, a document appeared as a number of areas on screen, with each
area maintained by a different application.  Unlike OpenDoc, each
application ran in a separate address space with full protection.
The notion of "application launch" was eliminated; as you scrolled through
a document, processes were created and terminated as required.

      PenPoint had no installed base with which they had to be compatible,
so they could use a much simpler architecture.  All PenPoint apps are
derived classes from base classes of the OS.  This makes apps much
smaller and simpler, and enforces standardization.  But it's not an
architecture you can retrofit.

      The price we pay for backwards compatibility is seen in the
complexity of OLE and OpenDoc.

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Thu, 01 Sep 1994 08:56:19 +0200
Organization: Royal Institute of Something or other

In article <3424oc$[e-mail]>,
[e-mail] (Robert Lentz) wrote:

>And complain to those developers that have not seen the light. Would it not
>be nice to be able to ask Word to spell check a document for you?

No, because Word uses Houghton-Mifflin spell checking, which
you can license yourself. Don't. Their Mac code would compile
on a 1984 Mac, and that's it. It uses FSOpen(). It uses signed
chars interchangeably with unsigned chars. Etc.

Their English dictionary is also nothing good unless you buy
all the extra libraries.

Cheers,

                    / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  Reality exists only in your imagination.


+++++++++++++++++++++++++++

>From [e-mail] (Philip Machanick)
Date: 1 Sep 1994 10:08:40 +0200
Organization: Computer Science Department, University of Cape Town

Just curious.

I wonder how many of the people saying OpenDoc is no good - AAARGH NO!
IT'S CONFIGURABLE - THE USERS WILL BREAK IT - are the same ones who
used to run down the Mac because it isn't configurable like X.

I must say though I can have some empathy with this fear having
wasted large chunks of time trying to make X usable every time I
move to a new place.
--
Philip Machanick                      [e-mail]
Computer Science Department, University of he Witwatesrand
2050 Wits, South Africa 27(11)716-3309 fax [phone]
(at University of Cape Town until November: 27(21)650-4058)

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Thu, 01 Sep 1994 14:55:18 +0200
Organization: Royal Institute of Something or other

In article <[e-mail]>,
[e-mail] (John Nagle) wrote:

>      The price we pay for backwards compatibility is seen in the
>complexity of OLE and OpenDoc.

Guess what? In OpenDoc, all applications are subclasses of a
system class, ODPart to be exact, and all storage is subclasses
of ODStorageUnit (or whatever) etc. OpenDoc also requires total
rewrite of everything; it's NOT designed to be backwards
compatible (which OLE is, to some degree)

However, you're confusing the issues of an application runtime
architecture with the issues of various OS support. There's no
reason why OpenDoc parts cannot live in separate protected
address spaces.

Cheers,

                / h+


--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden

  Reality exists only in your imagination.


+++++++++++++++++++++++++++

>From [e-mail] (John Nagle)
Date: Thu, 1 Sep 1994 16:26:12 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

>In article <[e-mail]>, [e-mail] (Mark
>Hanrek) wrote:
>< In many instances, it is not appropriate to expect that Apple is supposed
>< to provide a solution, or even to have an accurate perception of its
>< development community.  We accidentally think Apple should solve our
>< problems or understand us because we are generally powerless to do
>< anything beyond what our spare time will allow.

>Yes, Apple does what it wants, what it has resources to do, and what it
>*thinks* we want.

       Apple needs to realize that 1) the development tools for the
Macintosh are now inferior to those for Windows, and 2) this is Apple's
problem, whether Apple likes it or not.

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Thu, 1 Sep 1994 21:50:31 GMT
Organization: Will hack for food

John Nagle ([e-mail]) wrote:

>        Apple needs to realize that 1) the development tools for the
> Macintosh are now inferior to those for Windows, and 2) this is Apple's
> problem, whether Apple likes it or not.

This is off the thread, but I just wanted to refute this statement.  We
have just gone from all Mac development to doing some Windows development
too.  We had heard this line for some time but it does not jibe with our
experience.  We have yet to find a single tool that operates as nicely as
THINK, CW _or_ MPW.  Sure, some are faster, some have cool features, but
nothing works as well or as integrated.  Just trying to write some scripts
to mimic some of our MPW Projector scripts was a nightmare!

All in all, we should start a different thread and argue about this some
more.  Macintosh development tools are damn nice compared to the mess on
Windows.

Jon


+++++++++++++++++++++++++++

>From [e-mail] (Bob Dalgleish)
Date: 2 Sep 94 16:12:19 GMT
Organization: Develcon Electronics Ltd., Saskatoon, SK, Canada

In article <[e-mail]> [e-mail] (Joshua Susser) writes:
>[e-mail] (John Nagle) wrote:
>> E.J. Draper <[e-mail]> writes:
>> >It seems like the whole OpenDoc paradigm starts breaking down after you
>> >get past the Graphic+MooV+Text+Spreadsheet model.
>>
>>       I think he has a point.  I can imagine a CAD system based on this
>> approach, where you click on a subassembly to get to the detailed drawings.
>> But that doesn't even fit the OpenDoc model, which is 2D, not 3D.
>> What, besides embed stuff in word processor documents, is one really likely
>> to do with OpenDoc?
>
>OpenDoc windows and layout objects are 2D, because that's the
>dimensionality of the imaging devices available today (for the most
>part).  But we did leave enough room in the API to support 3D parts.  It
>should in fact be possible to embed a text part onto the surface of a 3D
>sphere part.
>
>But even without 3D, OpenDoc is suitable for much more than just a
>"Graphic+MooV+Text+Spreadsheet" kind of document.  See below.

I started to have a vision.  Having followed this thread for awhile, and
read through the WWDC documentation, installed BBEdit 3.0, Symantec C 7,
and MW CW, purchased and installed a *very expensive* CASE system, and
still being faced with elementary problems of envisioning software, I
started to see a trend.

Software project forms a document (in SC7, this is a project file), to
which are attached source files, object files, library files, resource
files, resource source files, and pretty much anything you want.  The
TPM uses the file suffix to assign a "part editor" to each type of file,
and "does the right thing" at the right time.  How does this differ from
an OpenDoc document with part editors for distinct parts, and a document
"application" co-ordinating the make process?

Even though we think of source code as a text file, we, in fact, treat
it as a specialized database of relationships.  Witness PopUpFuncs,
CMaster, ObjectMaster, and other extensions to the basic set of text
manipulation tools.  Someone else has suggested "Could I not see my
source code as a flow-chart, data-flow chart, decision table, coverage
checklist?"

The model we already use for software development is that of an OpenDoc
architecture with only three providers and some hangers-on.  A true
OpenDoc document for a development project would have resource editors,
text editors, compilers, graphers, analyzers, etc., as part editors that
could be applied at any time for any purpose that the devious minds of
developers can come up with.
>>       By the way, how does OpenDoc do version management?
>
>OpenDoc documents provide a facility for creating a named revision of your
>document called a "draft".  Each draft is basically a checkpoint of the
>state of the document.  You can create a new draft at any time, have as
>many as you like, open old drafts to compare to newer, etc.  There's
>lots more about drafts, but you can read the documentation for that.

This is much more sophisticated than Projector or SourceServer or RCS.
As long as there was a way to get drafts of parts, most programmers
would be happy to work in such a world.

Any programmer will tell you that comments don't cut it as for
keeping sufficient information to maintain software, but it is the
only tool available.   New part editors, and ways to co-ordinate them
may be just the way to do it.

Okay, who's up for writing an OpenDoc document to replace Think C and
CodeWarrior?
--
-- * * * CFV: net.short.signatures * * *--
Bob Dalgleish     zaphod![e-mail]     CompuServe: 70521,2011

+++++++++++++++++++++++++++

>From [e-mail] (William Uther)
Date: 3 Sep 1994 10:36:00 +1000
Organization: Basser Dept of Computer Sciece, Uni of Sydney, Australia

In article <[e-mail]>, Bob Dalgleish <[e-mail]> wrote:
>In article <[e-mail]> [e-mail] (Joshua Susser) writes:

[snip]

>>But even without 3D, OpenDoc is suitable for much more than just a
>>"Graphic+MooV+Text+Spreadsheet" kind of document.  See below.
>
>I started to have a vision.  Having followed this thread for awhile, and
>read through the WWDC documentation, installed BBEdit 3.0, Symantec C 7,
>and MW CW, purchased and installed a *very expensive* CASE system, and
>still being faced with elementary problems of envisioning software, I
>started to see a trend.

[snip]

>Even though we think of source code as a text file, we, in fact, treat
>it as a specialized database of relationships.  Witness PopUpFuncs,
>CMaster, ObjectMaster, and other extensions to the basic set of text
>manipulation tools.  Someone else has suggested "Could I not see my
>source code as a flow-chart, data-flow chart, decision table, coverage
>checklist?"

[snip]

>Okay, who's up for writing an OpenDoc document to replace Think C and
>CodeWarrior?

This sounds very like the Gwydion project CMU are working on (with Apple?).

The WWW page URL is:
http://legend.gwydion.cs.cmu.edu:8001/gwydion/

They are working on a development environment for Dylan (aka BHS) which
includes being able view your code as hypertext.  They mention version control
where you can lock functional parts on the program - e.g. if you were changing
the interface to a function you could lock "this function and all functions
that reference it".  Anyway, have a look the WWW page for more info.

\x/ill      :-}


+++++++++++++++++++++++++++

>From [e-mail] (Dean Perry)
Date: 8 Sep 1994 04:45:11 GMT
Organization: Zikzak public access UNIX, Melbourne Australia

eric larson ([e-mail]) wrote:
:  >      A more fundamental problem is that all this machinery exists mostly
:  > so you can embed different documents in your word processor and still
:  > edit them with appropriate tools.  It's sort of "Publish and Subscribe,
:  > The Next Generation".  Yes, you can do other stuff, but the touted
:  > advantage is mostly for integrated documents.  It's all focused on
:  > what documents look like, not what they mean.  Is that really worth all
:  > this complexity?

: One concern I have about this technology is what it is going to do to document
: portability.

Like what do you do when you don't have all the parts to view
something... I guess this will come about along the lines of what happens
if you have a QuickTime clip in a document on a machine without it
installed - you get a dead placeholder that may or may not represent the
content.  The whole idea of *distributed* parts freaks me a little - what
do you do when your document relies on net connections to multiple remote
servers and the net goes away?

dean
--
        Zikzak public access UNIX, Melbourne, Australia.

+++++++++++++++++++++++++++

>From [e-mail] (Quinn "The Eskimo!")
Date: Thu, 08 Sep 1994 17:50:17 +0800
Organization: Department of Computer Science, The University of Western Australia

In article <[e-mail]>, [e-mail] (John Nagle) wrote:

>      Or long-term document integrity.  Will you still be able to read
>your document a few years downstream, after all the applications have
>changed?  And if you can't, which vendor do you call for help?

I don't think this will be a problem.  Unless there are nasty bugs in the
part handlers, OpenDoc should still be able to open the document, even if
you can't edit (or even view) it.  You'll be able to rip it apart and try
to find out which part handler is having the bad day.

Alternatively it's likely that sooner or later, someone will build
'ResEdit for Bento', an application that lets you tear OpenDoc documents
apart at a low level.  This means you'll be able to break any document up
into its component parts and hence edit them that way.

Let's face it, you face exactly the same problem today with non-compound
documents.  If WidgetWorks Inc goes down the tubes and, 3 years later,
WidgetWorks fails to run under Gerschwin, well you're screwed, aren't you?

Share and Enjoy.
--
Quinn "The Eskimo!"        "Scout in a can. Simple, cheap, easy
                            to use and it's expendable!"

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Thu, 08 Sep 1994 09:40:32 -0800
Organization: Integer Poet Software

In article <34m4t5$[e-mail]>, [e-mail]
(Dean Perry) wrote:

> : One concern I have about this technology is what it is going to do to
> : document portability.
>
> Like what do you do when you don't have all the parts to view
> something... I guess this will come about along the lines of what happens
> if you have a QuickTime clip in a document on a machine without it
> installed - you get a dead placeholder that may or may not represent the
> content.

Good answer. Gold star. :-) However, this is not a complete solution.

We all know what happens when an app fails to save font names in its
documents as opposed to font numbers. The font numbers will work as long
as (1) the doc stays on one machine, and (2) the user doesn't mess with
hir Fonts folder. Deprive the document of either one of those conditions,
though, and the page layout goes straight in the toilet, even if you're
able to find a similar font and apply it through some kind of global style
mechanism (because presumably there are too many changes to make
manually).

Now imagine what's missing is not just a font but a program. Presumably
the program is a bit more complex than a font. Don't get me wrong; it
might be as clean as a QuickTime PICT. But we can't really guess what
unfortunate portability issues will appear until they do appear, because
nobody has done this before.

> The whole idea of *distributed* parts freaks me a little - what
> do you do when your document relies on net connections to multiple remote
> servers and the net goes away?

It doesn't strike me that this is any worse than a part editor which is
missing when the doc is opened. One important difference is that the app
shell might be able to take a snap shot of the part's screen
representation before the part editor goes away.

--

 Pete Gontier // impudent ass // [e-mail]

 "The need to be (or appear to be) sophisticated pervades the very
 atmosphere in which we, the Magazine Reading Class, move."
                  -- Ellis Weiner, Spy Magazine, 9/94

+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Thu, 8 Sep 1994 18:40:11 GMT
Organization: Apple Computer

Dean Perry, [e-mail] writes:
> : One concern I have about this technology is what it is going to do to
document
> : portability.
> Like what do you do when you don't have all the parts to view
> something...

There are three levels of support for this:
* If you don't have the preferred editor for that part, but have another
editor that can edit one or more of the content types saved for that part,
that editor will be used. (Note that an editor can save a part in multiple
representations, kind of like writing to the Clipboard or drag mgr today.)
* If that fails, but there is a translator available that knows how to
translate one of the part's formats into something one of your available
editors can read, the translator will be used. (On the Mac, this uses the
translation system from Mac Easy Open. Other platforms will implement it
differently.)
* If all else fails, the part will display as a gray box that displays its
content type(s). Note that the document will still open, and all other parts
for which an editor could be found will appear.

Someone else mentioned a "Bento ResEdit" ... someone (not at Apple) has
written a tool like that. I'm not sure whether they're going to finish the
implementation or distribute it more widely. It'd be quite useful.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Fri, 09 Sep 1994 10:07:24 +0200
Organization: Royal Institute of Something or other

In article <34m4t5$[e-mail]>,
[e-mail] (Dean Perry) wrote:

>Like what do you do when you don't have all the parts to view
>something...

Part Viewers are encouraged to be free, while the editors would
cost money.

Also, a Part Editor is encouraged to store its info in one or
more standard formats (i e PICT) as well as its own format, so
you can use the "SimpleText" part to view but not edit it.

>content.  The whole idea of *distributed* parts freaks me a little - what
>do you do when your document relies on net connections to multiple remote
>servers and the net goes away?

What do you do when the power goes out? Oh, it doesn't go out
often, but it happens, right? Networks will have about the same
reliability. (And aside from having an UPS, I now am looking
for a V.24 adapter for my digital cellular phone :-)

Cheers,

                / h+


--
  Jon W‰tte ([e-mail]), 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 [e-mail] (John Nagle)
Date: Fri, 9 Sep 1994 16:36:15 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

[e-mail] (Pete Gontier) writes:
>In article <34m4t5$[e-mail]>, [e-mail]
>(Dean Perry) wrote:
>> : One concern I have about this technology is what it is going to do to
>> : document portability.
>>
>> Like what do you do when you don't have all the parts to view
>> something...
>We all know what happens when an app fails to save font names in its
>documents as opposed to font numbers. ...
>Now imagine what's missing is not just a font but a program. ...

     Yeah.  Supposedly the plan for OpenDoc is that a PICT representation
of the object is carried with the document, so it can be viewed without
the appropriate editor.

     One implication is that even simple documents will be big.  A more
subtle implication is that document editability may invisibly degrade over
time as the underlying applications change.  The document may look just
fine until you try to do something to it.

                    John Nagle

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Tue, 13 Sep 1994 22:57:58 GMT
Organization: Will hack for food

John Nagle ([e-mail]) wrote:

>      Yeah.  Supposedly the plan for OpenDoc is that a PICT representation
> of the object is carried with the document, so it can be viewed without
> the appropriate editor.

>      One implication is that even simple documents will be big.  A more
> subtle implication is that document editability may invisibly degrade over
> time as the underlying applications change.  The document may look just
> fine until you try to do something to it.

These are all concerns relating to OLE also.  In fact, Microsoft advocates
OLE as a superior technology because it includes a picture along with the
data whereas OpenDoc does not (according to this MicroSoft OLE comparison
paper I've been reading).  My favorite part is where they claim that because
the picture is included, the document may be printed without the editor
being involved.  They seem to have missed the whole resolution issue.

Personally, I like the OpenDoc approach better.  It takes a more functional
attitude, where parts can work the way they want instead of the way the
container wants, which is the OLE approach.  This paper says that OLE can do
OpenDoc's in place activation (normal OLE parts are inactive until clicked)
if the container app wants to.  It doesn't mention that no OLE apps want to.
I can see why.  If you activate an Excel graph in Word when it scrolls onto
the screen, you need to launch Excel.  That's a nontrivial operation.  The
real question is, will you be able to init all your parts fast enough.  The
OLE folks don't think so, which is why they advocate static pictures, no
implicit activation and printing from the pictures.

Jon

+++++++++++++++++++++++++++

>From [e-mail] (Philip Machanick)
Date: 14 Sep 1994 07:07:06 GMT
Organization: Computer Science Dept, U of Witwatersrand

In article <[e-mail]>, [e-mail] (Jon Pugh) wrote:

> Personally, I like the OpenDoc approach better.  It takes a more functional
> attitude, where parts can work the way they want instead of the way the
> container wants, which is the OLE approach.  This paper says that OLE can do
> OpenDoc's in place activation (normal OLE parts are inactive until clicked)
> if the container app wants to.  It doesn't mention that no OLE apps want to.
> I can see why.  If you activate an Excel graph in Word when it scrolls onto
> the screen, you need to launch Excel.  That's a nontrivial operation.  The
> real question is, will you be able to init all your parts fast enough.  The
> OLE folks don't think so, which is why they advocate static pictures, no
> implicit activation and printing from the pictures.

The OLE people think this way because they are trying to move dinosaurs
around with a fly whisk. OpenDoc breaks apps down into more manageable
chunks - or at least will if programmers use it the way it was intended.
Launching a spreadsheet part (viewer not editor is the minimum needed)
handler should be a much more lightweight operation than launching Excel.

Another strategy would be to make resolution in a more general sense the
deciding factor on whether you need a part handler - to print to higher
resolution device, to open the object to edit it, to display it on a
screen with more colours etc.
--
Philip Machanick                   [e-mail]
Department of Computer Science, University of the Witwatersrand
2050 Wits, South Africa        (at University of Cape Town 4 July-7 Nov)
phone [phone]  fax [phone]

---------------------------

>From [e-mail] (Alain Aslag Roy)
Subject: Linking with QuickTime.xcoff for the power pc
Date: Tue, 13 Sep 1994 03:44:44 GMT
Organization: It lurks in the night.

I've been working on an application that uses QuickTime 2.0 on the power
macintosh. I figured out how to link with the Import library for quicktime
(I got it from the Beta CD) and it works fine. Until I launch the program
in a low memory situation. Then I get a message about not being able to
find the QuickTime Libary or something like that. If I free up some memory,
I don't have that problem.

Now, I'd really like it if I could handle this error on my own instead of the
system handling it for me. My program doesn't require QuickTime, but can use
it if it's there. Is there a way for me to prevent the system from reporting
this error and for me to handle it myself?

I'm using MPW with PPCC (The RISC SDK), the most recent version, if that
matters.

Thanks in advance for any advice.

-alain

+++++++++++++++++++++++++++

>From [e-mail] (Zalman Stern)
Date: Tue, 13 Sep 1994 20:58:20 GMT
Organization: Adobe Systems Incorporated

Alain Aslag Roy writes
[Program fails to launch when QuickTime library cannot be loaded, say for
low memory reasons, or because it is not isntalled.]
> Now, I'd really like it if I could handle this error on my own instead of
the
> system handling it for me.
>
> I'm using MPW with PPCC (The RISC SDK), the most recent version, if that
> matters.

You want to make the linkage of the library "weak". This is done by adding a
tilde after the library name in the argument to the makepef command. Like
so:
    makepef <...> -l QuickTimeLib.xcoff=QuickTimeLib~

Figuring out if the library is actually there or not is another story. In
theory there is a gestalt selector to do this, but it doesn't work. Instead
you should test if a routine you use from the QuickTime library is NULL or
not. The whole mass of code I put in to MacApp to deal with this looks like
so:

/* Start with the Gestalt in as for a 68k. */
    theConfiguration.hasCompressionManager = Gestalt (gestaltCompressionMgr,
response) == noErr;

/* For PowerPC make sure we can actually call QuickTime if its there...
 * This piece of code is incredibly screwed up because we link to QuickTime
 * weakly. Meaning that if the library is not there, undefined externals
 * referencing that library do not keep us from running. However, there
 * seems to be a case where the library is there, but cannot be loaded due
 * to a lack of memory. In this case, the gestalt call says its there, but
 * the routines we call are still NULL. So what the hell, I just check one
 * of the routines that is supposed to be in that library.
 */
#ifdef __powerc
    theConfiguration.hasCompressionManager =
    (theConfiguration.hasCompressionManager &&
        (Gestalt(gestaltQuickTimeFeatures, response) == noErr) &&
        (response & (1 << gestaltPPCQuickTimeLibPresent)) &&
        &CustomGetFilePreview != NULL);
#endif
--
Zalman Stern           [e-mail]            [phone]
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
 Please do not change color while I am talking to you -- MC 900 Ft Jesus.

---------------------------

>From [e-mail] (Gary McGath)
Subject: Multiple monitors
Date: Sun, 4 Sep 1994 13:14:42 GMT
Organization: Conceptual Design

As a result of my unusual monitor configuration, I've developed an
awareness of problems that often crop up in applications whose
programmers fail to think about multiple monitors. Here are
my suggestions for good multiple monitor programming style; I
welcome additions and comments. Perhaps someone would care to throw
in some suggestions for Pivot monitors to go with these?

To figure the maximum window size, check the GrayRgn, not ScreenBits.
The user should be able to size a window across two monitors, or to
stretch it to the dimensions of a screen that may be bigger than the
main screen.

Don't assume that just because the main device is monochrome, the system
doesn't have color. Use GetMaxDevice.

If it's important that a new window be displayed in color, put it on the
screen with the greatest depth. This is especially important with
non-draggable dialogs. It's frustrating to have a color picker
window nailed to a monochrome monitor when there's a perfectly good
color monitor next to it.

If you have a graphic with both monochrome and color versions, check
which device it's being drawn to when deciding which version to use.
(Some calls, such as PlotCIcon, will do this automatically.)

Clicking on the zoom box of a window should position it in the screen
which it's currently occupying, rather than always hauling it to the
main device. (Defining which screen a window is occupying in the general
case is tricky, to be sure.)

Remember that if your window occupies the whole main screen, it doesn't
necessarily occupy all of the desktop. It's still possible for the
user to click outside the window.

When bringing up a window, be sure that at least its title bar is on the
screen. If the user plays with the Monitors control panel and then
reboots, a window which was on screen last time may be out of reach
this time. Some old DA's are especially bad about this, and can
permanently vanish into offscreen limbo.

--
          Gary McGath
          [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon W{tte)
Date: Mon, 05 Sep 1994 17:34:25 +0200
Organization: Royal Institute of Something or other

>To figure the maximum window size, check the GrayRgn, not ScreenBits.

Yes. Most apps that do this wrong, can be coerced by using the
command key when resizing the window.

>Don't assume that just because the main device is monochrome, the system
>doesn't have color. Use GetMaxDevice.

However, GetMaxDevice crashes on non-color machines, and if
those are a factor, you have to check some more. I recently did
an about box for someone else, which went pretty much like this:

depth = 1 ;

Is there color QD?
If yes, is there QuickTime?
If yes, depth = depth of GetMaxDevice()
If depth < 8, depth = 1

Load and draw pictures using b/w if depth = 1, else color. If
depth is 8, use the palette of the screen the window's on
(which is the deepest screen, to show off the colors :-)

QuickTime is required because of the JPEG about picture. Code
and images for 24-bit color and black/white come in at under 40k!

>If you have a graphic with both monochrome and color versions, check
>which device it's being drawn to when deciding which version to use.
>(Some calls, such as PlotCIcon, will do this automatically.)

Use DeviceLoop()

>Clicking on the zoom box of a window should position it in the screen
>which it's currently occupying, rather than always hauling it to the

Yes! The screen with the most pixels of the window on it. It
should also move the window as little as possible, i e first
grow it down/right until it can grow it no more; then keep
growing up-left 'til the screen is full.

>When bringing up a window, be sure that at least its title bar is on the
>screen. If the user plays with the Monitors control panel and then

Yeah, this is a killer. I have an FKEY that staggers all visible
app windows. Can do funky things to palettes, but saves the day
occasionally :-)

Cheers,

                / h+



--
  Jon W‰tte ([e-mail]), Hagagatan 1, 113 48 Stockholm, Sweden
   This signature is kept shorter than 4 lines in the interests of UseNet
   S/N ratio.


+++++++++++++++++++++++++++

>From [e-mail] (Neil Ticktin)
Date: Mon, 5 Sep 1994 17:54:25 GMT
Organization: MacTech Magazine/Xplain Corporation

In article <[e-mail]>, [e-mail]
(Gary McGath) wrote:

>> As a result of my unusual monitor configuration, I've developed an
>> awareness of problems that often crop up in applications whose
>> programmers fail to think about multiple monitors. Here are
>> my suggestions for good multiple monitor programming style; I
>> welcome additions and comments. Perhaps someone would care to throw
>> in some suggestions for Pivot monitors to go with these?


Gary,

We found the similar things.  We published an article about how to support
multiple monitors a couple issues back.  We hope, as you do, that people
will provide more support for multiple monitors -- it's annoying when they
don't.

Thanks,
Neil

- ---------------------------------------------------------------------
           Neil Ticktin, MacTech Magazine (formerly MacTutor)
PO Box 250055, Los Angeles, CA 90025 * 310-575-4343 * Fax: [phone]
 For more info, anonymous ftp to ftp.netcom.com and cd to /pub/xplain
  [e-mail] * [e-mail] * [e-mail]
[e-mail] * [e-mail] * [e-mail]
   [e-mail] * [e-mail] * [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Mon, 5 Sep 1994 20:02:00 GMT
Organization: Will hack for food

Gary McGath ([e-mail]) wrote:
> When bringing up a window, be sure that at least its title bar is on the
> screen. If the user plays with the Monitors control panel and then
> reboots, a window which was on screen last time may be out of reach
> this time. Some old DA's are especially bad about this, and can
> permanently vanish into offscreen limbo.

I only require that the 16 bits or so of the left or right end of the title
bar be on screen.  This allows you to slam a window offscreen into the bottom
corners of the screen and remain there after it is closed and reopened.  I
suppose it doesn't catch the big window with both ends off screen, but I
don't think anyone's managed to get that and not minded it being reset.

We regularly get into window wars at work via Projector.  My compatriot has
his menubar on the little color screen (for some of the reasons outlined
before) and edits on a large b&w monitor next to it.  Then he checks in
and I open the window half off my little color monitor and not on my 16"
color monitor.  Since the title bar is on screen, it doesn't move though.
I don't see a good way to fix this without saving the entire monitor setup.

Jon


+++++++++++++++++++++++++++

>From Charles B. Cranston <[e-mail]>
Date: 6 Sep 1994 19:55:23 GMT
Organization: Network Infrastructure U Maryland College Park

It may be worth mentioning that there is an Apple Human Interface
Note on the right things to do for multiple monitors, and this
information has also been integrated into the McGraw Hill
"Macintosh Human Interface Guidelines", mostly in chapter 5.

It is amazing how much software does NOT do the right things,
even MPW didn't zoom correctly until 3.3 came out...

+++++++++++++++++++++++++++

>From [e-mail] (Joseph "Moof-in'" Hall)
Date: Thu, 8 Sep 94 01:36:24 MST
Organization: comp.sys.mac.programmer.moof Advocacy


In article <[e-mail]> (comp.sys.mac.programmer), [e-mail] (Jon Pugh) writes:
) We regularly get into window wars at work via Projector.  My compatriot has
) his menubar on the little color screen (for some of the reasons outlined
) before) and edits on a large b&w monitor next to it.  [...]

I've wondered why apps don't save window position as an offset
relative to the nearest corner or something like that.  It would certainly
solve some window placement disputes.

=============== O Fortuna, velut Luna, statu variabilis ===============
uunet!joebloe!joseph   [phone] day   [e-mail]
1400 N Alma School                #163               Chandler, AZ 85224
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
           Be hip!  Support comp.sys.mac.programmer.moof!

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Sat, 10 Sep 1994 22:10:28 GMT
Organization: Will hack for food

Joseph "Moof-in'" Hall ([e-mail]) wrote:

> I've wondered why apps don't save window position as an offset
> relative to the nearest corner or something like that.  It would certainly
> solve some window placement disputes.

That doesn't save your window size.  It's simple to just store the rect.
Of course, it wouldn't be much harder to store the offset point and the
window height and width point either.  Sounds like it's time for some
experimentation to see if this would buy you anything.  It sounds identical
in most cases though.

Jon


+++++++++++++++++++++++++++

>From [e-mail]
Date: Thu, 15 Sep 1994 06:02:23 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <[e-mail]>,
Jon W{tte <[e-mail]> wrote:
>>If you have a graphic with both monochrome and color versions, check
>>which device it's being drawn to when deciding which version to use.
>>(Some calls, such as PlotCIcon, will do this automatically.)
>
>Use DeviceLoop()

While working on my popup CDEF, I ran into a problem drawing a color
image from an offscreen graphics world when the destination rectangle
spanned two monitors with different depths. The problem arose because
the offscreen gworld was created with the depth of the deepest
monitor. The portion of the image that was copied to the color monitor
was displayed perfectly. But the portion of the image that was copied
to the black and white monitor was real ugly, since all the color
pixels got mapped to black. The only solution I could find was to use
a DeviceLoop when drawing an image that spans monitors of different
depths. Unfortunately, this meant that I couldn't use the offscreen
gworld, and the image flickers if it spans monitors with different
depths.

--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

+++++++++++++++++++++++++++

>From [e-mail]
Date: Thu, 15 Sep 1994 06:08:21 GMT
Organization: The World Public Access UNIX, Brookline, MA

In article <34ihfb$[e-mail]>,
Charles B. Cranston  <[e-mail]> wrote:
>It is amazing how much software does NOT do the right things,
>even MPW didn't zoom correctly until 3.3 came out...

Well, I still think MPW misses the mark. And SADE and HyperCard are
*very* annoying. I put the Worksheet window in SADE on my small
monitor and put the source code window on my big monitor. Then, when I
hit command-F to search for something, the find dialog pops up
way-over-there on the little monitor; BLECH! HyperCard does similar
stupid things. And THINK C 7.0 even stuck my windows OFF SCREEN!!!
YES, I OPENED A WINDOW AND ITS TITLE BAR WAS HIDDEN BEHIND THE MENU
BAR! Fortunately, I've been using macs for far too long, and promptly
broke into MacsBug and set MBarHeight to 0 and dragged the windows
back to somewhere more accessable. (The alternative of editing the
menu record with MacsBug, with the associated structure and content
regions, etc. just was out of the question; I don't know what I would
have done with a PowerPC!)
--
Ari Halberstadt                                 [e-mail]
One generation passes away, and another generation comes: but the
earth abides for ever. -- Ecclesiastes, 1:4.

---------------------------

>From [e-mail] (Peter Kocourek)
Subject: The 'aete' resource and the Script Editor
Date: 07 Sep 94 01:24:16 +
Organization: Care Net Holland

Hi,

I just had strange problem with the Script Editor and the 'aete' resource. I
had already added a few events to the aete resource, and everything was
working fine. Then I added a simple event, with no required parameters or any
fancy stuff. That's when the weirdness began.

When I sent the event to myself, everything was fine. But when I tried to send
the event from the Script Editor, my event handler returned errAEParamMissed,
when I was making the routine check for missed parameters. Yet I had indicated
in the aete, that the event did not have any parameters...

So, trying to find out what kind of parameter the Script Editor was passing
along, I discovered that the type of the missed parameter was 'keyw', and the
type of keyword I'd missed was '----'. I merrily put in code to get the
parameter, but that call to AEGetParamPtr came back with errAEDescNotFound,
even though I had just extracted the relevant information about the missing
parameter from the AppleEvent!

I checked the Event Log in the Script Editor, and sure enough, when sending my
event "foo", the Log said it had sent "foo current application". And that
despite the fact that it said in the aete resource that I wanted no
parameters, direct or otherwise.

Ultimately, after a lot of frustration, I found the cause of the problem: in
the aete resource, I had specified a the direct parameter as being of type
typeNull, but I had the "is optional" flag off. Once I switched that on,
everything worked fine.

Is this the way the Script Editor is supposed to behave? I thought that a
typeNull type indicated that no parameter was to be included under any
circumstances. And the errAEDescNotFound still bothers me. If I find the type
of the missed parameter, surely I should be able to extract it from the
AppleEvent; in this case the AE Manager seemed to be telling me that there is
an additional parameter in there, but that it can't find it. What's going on?


YHS:QSI!

+++++++++++++++++++++++++++

>From [e-mail] (Jon Pugh)
Date: Sat, 10 Sep 1994 21:53:36 GMT
Organization: Will hack for food

Peter Kocourek ([e-mail]) wrote:

> I just had strange problem with the Script Editor and the 'aete' resource.

> [snip]

> Ultimately, after a lot of frustration, I found the cause of the problem: in
> the aete resource, I had specified a the direct parameter as being of type
> typeNull, but I had the "is optional" flag off. Once I switched that on,
> everything worked fine.

Ed Lai has been telling people to make sure they set the optional bit if
they used a direct parameter of typeNull (i.e. none) for quite some time.  I
guess now we know why.  ;)

Regardless of whether it is intential or not, it is the way it works, so be
sure to do this.

Jon

+++++++++++++++++++++++++++

>From [e-mail] (Ed Lai)
Date: 14 Sep 1994 16:16:31 GMT
Organization: Apple

In article <[e-mail]>, [e-mail] (Peter Kocourek)
wrote:

> Hi,
>
> I just had strange problem with the Script Editor and the 'aete' resource. I
> had already added a few events to the aete resource, and everything was
> working fine. Then I added a simple event, with no required parameters or any
> fancy stuff. That's when the weirdness began.
>
> When I sent the event to myself, everything was fine. But when I tried to send
> the event from the Script Editor, my event handler returned errAEParamMissed,
> when I was making the routine check for missed parameters. Yet I had indicated
> in the aete, that the event did not have any parameters...
>
> So, trying to find out what kind of parameter the Script Editor was passing
> along, I discovered that the type of the missed parameter was 'keyw', and the
> type of keyword I'd missed was '----'. I merrily put in code to get the
> parameter, but that call to AEGetParamPtr came back with errAEDescNotFound,
> even though I had just extracted the relevant information about the missing
> parameter from the AppleEvent!
>
> I checked the Event Log in the Script Editor, and sure enough, when sending my
> event "foo", the Log said it had sent "foo current application". And that
> despite the fact that it said in the aete resource that I wanted no
> parameters, direct or otherwise.
>
> Ultimately, after a lot of frustration, I found the cause of the problem: in
> the aete resource, I had specified a the direct parameter as being of type
> typeNull, but I had the "is optional" flag off. Once I switched that on,
> everything worked fine.
>
> Is this the way the Script Editor is supposed to behave? I thought that a
> typeNull type indicated that no parameter was to be included under any
> circumstances. And the errAEDescNotFound still bothers me. If I find the type
> of the missed parameter, surely I should be able to extract it from the
> AppleEvent; in this case the AE Manager seemed to be telling me that there is
> an additional parameter in there, but that it can't find it. What's going on?
>
>
> YHS:QSI!

This is not a problem with the script editor. I always consider this to
be a problem of AppleScript, although I was told there are reason to do
it that way so it can not be fixed. As you discoverd, if the direct
parameter is of type typeNull, then AppleScript would send a typeNull
as the direct parameter. The AppleEvent manager checks every parameter
you have accessed. If you ask for parameter missed, then it returns
the keyword '----'. When you try to get the direct parameter, AEM
found the type to be typeNull, which means no parameter, so
AEM got fooled has say errAEDescNotFound. The last part can be
considered to be an AEM bug, although it is almost excusable.
--
/* Disclaimer: All statments and opinions expressed are my own */
/* Edmund K. Lai                                               */
/* Apple Computer, MS303-3A                                    */
/* 20525 Mariani Ave,                                          */
/* Cupertino, CA 95014                                         */
/* [phone]                                               */
zW@h9cOi

---------------------------

>From [e-mail] (Art Eschenlauer)
Subject: can extensions send appleevents?
Date: Wed, 14 Sep 1994 13:07:32 GMT
Organization: University of Minnesota, Twin Cities

Last night I was plughing around in my System 7.0.1 software, looking at
SIZE resources. I found that the Finder has the HighLevelEventAware flag
set but that the System does not. The dogma is that to send AppleEvents success-
fully using AESend, an 'application' must have the HighLevelEventAware flag
set. I want to send appleevents from an extension that is called via patches
to drawmenubar, systemmenu, and menuselect from within ANY application (that
uses the menubar). How will I get in trouble here? 1. Will I be hosed if the
calling app is not HighLevelEventAware? 2. Will I be hosed all the time because
the system is not HighLevelEventAware? 3. By some bizarre quirk of fate, will
I be successful all the time because the Finder is HighLevelEventAware (I want
to send 'odoc' events) or because code resources aren't restricted by th
HighLevelEventAware bit? 4. Am I hosed all the time because code resources
cannot send appleevents?

Thanks!

-Art

--
[e-mail] (Art Eschenlauer, U of M Agronomy & Plant Genetics)
"The only things that you can take with you are those that you have given
away." - Sign under Peter Bailey's picture in "It's a Wonderful Life"

+++++++++++++++++++++++++++

>From [e-mail] (Leeuw van der TN)
Date: Wed, 14 Sep 1994 14:42:54 GMT
Organization: Fac. Wiskunde & Informatica, VU, Amsterdam

Maybe you could make your Control Panel communicate with a background
application, that sends the AppleEvents to the Finder?
I think you can use Gestalt for that.

Just a passing thought.

--Tim van der Leeuw
[e-mail]


+++++++++++++++++++++++++++

>From Jens Alfke <[e-mail]>
Date: Wed, 14 Sep 1994 20:52:09 GMT
Organization: Apple Computer

Art Eschenlauer, [e-mail] writes:
> I want to send appleevents from an extension that is called via patches
> to drawmenubar, systemmenu, and menuselect from within ANY application (that
> uses the menubar). How will I get in trouble here?

The Apple Event Manager doesn't care what _code_ is running, only what
_process_ is active. If your patch tries to send an AE, what happens depends
on what app (the Finder is an app) is currently active. If it's AE-aware (as
per the SIZE rsrc) you'll succeed. If not, you'll fail, probably with the
infamous -903 error.
These days most apps are AE-aware, but some still are not.
Extensions like QuicKeys and KeyQuencer get around this problem by having a
small faceless bg app that they can have send the event for them. Of course,
you have to have some way of telling the app to send an event; this probably
boils down to some shared memory that you access via a Gestalt selector.

--Jens Alfke                           [e-mail]
                   "A man, a plan, a yam, a can of Spam ... Bananama!"

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Thu, 15 Sep 1994 00:27:49 -0800
Organization: Integer Poet Software

In article <[e-mail]>, [e-mail] (Art
Eschenlauer) wrote:

> 1. Will I be hosed if the calling app is not HighLevelEventAware?

Yes.

> 2. Will I be hosed all the time because the system is not HighLevelEventAware?

No.

> 3. By some bizarre quirk of fate, will
> I be successful all the time because the Finder is HighLevelEventAware (I want
> to send 'odoc' events) or because code resources aren't restricted by th
> HighLevelEventAware bit?

No.

> 4. Am I hosed all the time because code resources cannot send appleevents?

No.

Your point #1 is the important one here. When you call the AppleEvent
Manager, everything it wants to know is based on the context of the
current application. So when your code resource calls the AEM, you can
pretend the AEM "thinks" that the current application is making the call.

Consequently, if you can arrange for the calling app to be AE-aware, you
win. Since Finder is guaranteed to be AE-aware, you might be able to defer
sending your AE until Finder becomes the curreent app. (You can call
WakeUpProcess against it to make sure this happens quickly.)

Receiving AppleEvents is another matter entirely, of course, because your
handlers could conflict with the handlers of the current application.
There is probably a way to deal with this, but I haven't had to
investigate it yet, so I don't know much more than this.

There are some folks who know about undocumented interfaces to the AEM
which ignore the AE-aware status of the current app. These people claim
that even though the interfaces are undocumented there is enough
third-party software which uses the interfaces that it's unlikely Apple
will be able to break these interfaces in the future. (Probably these
people have written some of that software.) I won't names names to protect
the innocent, but now that I have mentioned this, perhaps someone will
pipe up.

--

 Pete Gontier // CTO, Integer Poet Software // [e-mail]

 "Yeah, that's fucking bizarre. That's one I'd never heard before.
  Not even on the internet."
     -- Bob Mould, on rumors that he and Grant Hart were lovers
        when H¸sker D¸ broke up, _Spin_ magazine interview, 10/94

+++++++++++++++++++++++++++

>From [e-mail] (Chris Disavow Twinkies Tate)
Date: Thu, 15 Sep 1994 13:24:10 GMT
Organization: DCRT, NIH, Bethesda, MD

In article <[e-mail]>, [e-mail] (Pete Gontier) writes:
>
>Receiving AppleEvents is another matter entirely, of course, because your
>handlers could conflict with the handlers of the current application.
>There is probably a way to deal with this, but I haven't had to
>investigate it yet, so I don't know much more than this.

As I recall, there's sample code from DTS around called something like
"AEcdev," which uses an FBA as an AppleEvent "dispatcher."  When you
want to send an AE from your (non-application) code, you talk to the
FBA (presumably launched at system startup?), and away it goes.

Now: I'd have to dig into how the code resource and the FBA communicate.
Can standalone code use bare PPC?  Or does it have to go through something
like the Gestalt mechanism that INIT/cdev combinations frequently use to
communicate?

Either way, it seems that one could come up with a (small) FBA whose job
it is to handle two-way dispatch of AppleEvents, passing them along to
the proper standalone-code recipients.  The real problem, I think, is
tracking which chunk of standalone code is supposed to be receiving a
given AppleEvent.  Hmmmm....

__________
Christopher Tate                                   [e-mail]
GM/CS$ d(--) H s:- g+ p0 au a- w+ v+(-*) C++ U+(--) E++ N++ K W---(++)$ M++$
   V+ -po+ Y+ t+ 5-- j+ G? tv b+++ D+++ e++ u++(---) h--- f r+++ n+ y+++

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Thu, 15 Sep 1994 09:22:01 -0800
Organization: Integer Poet Software

In article <[e-mail]>, [e-mail] wrote:

> As I recall, there's sample code from DTS around called something like
> "AEcdev," which uses an FBA as an AppleEvent "dispatcher."  When you
> want to send an AE from your (non-application) code, you talk to the
> FBA (presumably launched at system startup?), and away it goes.
> Now: I'd have to dig into how the code resource and the FBA communicate.
> Can standalone code use bare PPC?

That, in fact, is how the DTS code sample you mention works. :-)

> Or does it have to go through something like the Gestalt mechanism that
> INIT/cdev combinations frequently use to communicate?

And this is how I have done it in the past. PPC is too much of a hassle if
you have no event loop.

> The real problem, I think, is
> tracking which chunk of standalone code is supposed to be receiving a
> given AppleEvent.

Well, if you have a one-to-one relation between FBA and code resource,
there isn't much confusion. However, the original poster was talking about
sending an AppleEvent from within a patch to Menu Manager traps. I don't
think he's going to succeed in receiving an AppleEvent in such a context
no matter how hard he tries. :-)

--

 Pete Gontier // CTO, Integer Poet Software // [e-mail]

 "Yeah, that's fucking bizarre. That's one I'd never heard before.
  Not even on the internet."
     -- Bob Mould, on rumors that he and Grant Hart were lovers
        when H¸sker D¸ broke up, _Spin_ magazine interview, 10/94

---------------------------

End of C.S.M.P. Digest
**********************