cory@three.MV.COM (Cory Kempf) (07/23/90)
I have read the docs in IM VI and the New Apple Events Chapter, and I am still a bit confused about how to set up an application with AppleEvents. Especially after reading the article about User Agents (really a bad name for what they are... consider, the normal use of an agent: they take 10% off of the top, and do not really do much of anything.) Anyway, say I am building an application. To reasonably enable voice control and "Agents", I need to have all of the controlable units accessable via Appleevents. How does this hypothetical Agent know which events do what? How do I know what events to assign to which actions? What if my application needs more data to do something than another similar application? or different data? For that matter, what is the advantage of using the event dispatch system call? Is it planned to do something other than just be an additional step between application modules? Should I use it for internal communication? *CAN* I use it for internal communication without a significant overhead? +C -- Cory Kempf I do speak for the company (sometimes). The Enigami Co. 603 883 2474 email: cory@three.mv.com, harvard!zinn!three!cory
chewy@apple.com (Paul Snively) (07/31/90)
In article <395@three.MV.COM> cory@three.MV.COM (Cory Kempf) writes: > I have read the docs in IM VI and the New Apple Events Chapter, > and I am still a bit confused about how to set up an application > with AppleEvents. Especially after reading the article about > User Agents (really a bad name for what they are... consider, > the normal use of an agent: they take 10% off of the top, and > do not really do much of anything.) Heh, heh... I _love_ this one! > Anyway, say I am building an application. To reasonably enable > voice control and "Agents", I need to have all of the controlable > units accessable via Appleevents. How does this hypothetical > Agent know which events do what? I'm not sure where the concept of "agents" enters into this. You don't have to attempt to implement agents in order to take advantage of AppleEvents. > How do I know what events to assign to which actions? Ultimately there will be a widely-publicly-available document called the "AppleEvents Registry" which will be kept up-to-date with all of the existing standard AppleEvents, their parameters, semantics, sample code, etc. If your application supports the semantics, then it should also support the standard AppleEvent. If you have semantics that aren't covered but seem to need an AppleEvent (especially if the semantics are invoked as the direct consequence of a particular user action), then you should consider submitting a proposal for a new AppleEvent to the appropriate organization. (The details of this organization and the process by which someone defines AppleEvents are very nearly worked out. Stay tuned.) > What if my application needs more data to do something than another similar application? That's one of the reasons that AppleEvents support optional parameters. > or different data? Again, you might have to play some semantic games, or use a completely different AppleEvent. Try not to worry too much--it's not like you won't be able to roll your own and register them (or not, depending). > For that matter, what is the advantage of using the event dispatch system call? As opposed to what? In answer to the question, the advantages are: being able to take advantage of AppleEvent recording/playback mechanisms, and ultimately to support AppleScript. > Is it planned to do something other than just be an additional step between application modules? See the above. > Should I use it for internal communication? *CAN* I use it for internal communication > without a significant overhead? Yes and yes. You should for the reasons mentioned above--recording and scripting. And no; the overhead won't kill you. The case of sending to yourself is being heavily optimized (read: you won't even hit the network). __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________
cory@three.MV.COM (Cory Kempf) (08/06/90)
chewy@apple.com (Paul Snively) writes: > I write: >> Anyway, say I am building an application. To reasonably enable >> voice control and "Agents", I need to have all of the controlable >> units accessable via Appleevents. How does this hypothetical >> Agent know which events do what? >I'm not sure where the concept of "agents" enters into this. You don't >have to attempt to implement agents in order to take advantage of >AppleEvents. No, *I* don't. But it is pretty easy to see that Apple is trying to design the low level support into the system for voice activation and agents via the Apple Event mechanism. Assume that some company decides to impliment a voice powered macro system that uses Apple Events to cause the other applications (word processors, etc) to perform the actions that the user desires. I would like to be able to design my application today in such that this hypothetical Agent can manipulate my application. I don't expect that the Agent will be able to understand all of the messages that each application uses internally. The result would be an increadibly huge application (e.g. the space required to store all of the events that it would have to generate, as well as the code to know when to generate it.) I can see one of three results: The Agent supports only the Major Players (e.g. Adobe, Aldus, Microsoft, Informix, etc.) events, which would leave smaller companies (e.g. the two that I work for) out in the cold, or somebody has to come up with (and Apple would need to promote) a scheme for a user to painlessly inform the agent what messages to send to the Application. (perhaps a set of User Interface Events corresponding to the things the user sees on the screen? Hmmm, expect a strawman) The third is that the Agent can only access about 30% of the applications' functionality: that covered by existing standard events at the time of the products release (actually, development). Personally, I see the addition of Apple Events as one of the most significant additions to System 7. I also see it as one of the biggest headaches that I will have to face in designing my software in the next year. If it is handled properly, it will be a big win. I want to be able to cash is on it. +C -- Cory Kempf I do speak for the company (sometimes). The Enigami Co. 603 883 2474 email: cory@three.mv.com, harvard!zinn!three!cory
chewy@apple.com (Paul Snively) (08/08/90)
In article <402@three.MV.COM> cory@three.MV.COM (Cory Kempf) writes: > >> Anyway, say I am building an application. To reasonably enable > >> voice control and "Agents", I need to have all of the controlable > >> units accessable via Appleevents. How does this hypothetical > >> Agent know which events do what? > > >I'm not sure where the concept of "agents" enters into this. You don't > >have to attempt to implement agents in order to take advantage of > >AppleEvents. > > No, *I* don't. But it is pretty easy to see that Apple is trying to > design the low level support into the system for voice activation and > agents via the Apple Event mechanism. Oh, is that what we're doing? I thought we were doing component software and laying the groundwork for globally-accessible scripting. ;-) > Assume that some company decides > to impliment a voice powered macro system that uses Apple Events to > cause the other applications (word processors, etc) to perform the actions > that the user desires. Fair enough. > I would like to be able to design my application > today in such that this hypothetical Agent can manipulate my application. Ok. If you're writing a word processor, then you'd certainly want to support as many of the standard text-manipulation AppleEvents as your application can, plus whatever other things it might wish to support--say, a certain level of drawing AppleEvents if you're programming another FullWrite. :-) > I don't expect that the Agent will be able to understand all of the messages > that each application uses internally. The result would be an increadibly > huge application (e.g. the space required to store all of the events that > it would have to generate, as well as the code to know when to generate it.) The way we're addressing this is by making it possible for a piece of software to ask another piece of software what it can do (that is, what AppleEvents it supports, what data types, etc.) > I can see one of three results: The Agent supports only the Major Players (e.g. > Adobe, Aldus, Microsoft, Informix, etc.) events, which would leave smaller > companies (e.g. the two that I work for) out in the cold Obviously unacceptable. > somebody has to > come up with (and Apple would need to promote) a scheme for a user to > painlessly inform the agent what messages to send to the Application. (perhaps > a set of User Interface Events corresponding to the things the user sees on > the screen? Hmmm, expect a strawman) We love strawmen here. :-) And yes, you need to be able to specify how to send messages--this is what AppleScript is all about. > The third is that the Agent can only > access about 30% of the applications' functionality: that covered by existing > standard events at the time of the products release (actually, development). Given an extensible agent (e.g. via AppleScript) that can pick up new verbs and nouns on the fly, this shouldn't pose a problem. > Personally, I see the addition of Apple Events as one of the most significant > additions to System 7. I also see it as one of the biggest headaches that I > will have to face in designing my software in the next year. If it is handled > properly, it will be a big win. I want to be able to cash is on it. You will be able to--I promise. :-) __________________________________________________________________________ Paul Snively Macintosh Developer Technical Support Apple Computer, Inc. chewy@apple.com Just because I work for Apple Computer, Inc. doesn't mean that I believe what they believe, or vice-versa. __________________________________________________________________________