On 2006-06-29, at 15:24:13, John Stiles wrote:
GetApplicationEventTarget(), GetWindowEventTarget(), and
GetControlEventTarget() exist today. I don't see any difference
if there was to be a GetResourceManagerEventTarget(),
GetFileManagerEventTarget(), or a GetNavManagerEventTarget(). I
see usefulness.
In what way have you improved upon the existing APIs?
Just because two APIs use 32-bit IDs doesn't mean they should
necessarily share a dispatch mechanism.
An excellent question John,
And thanks very much for bringing a main criteria into focus. It
prompted me to a lot of thinking as how best to describe what I
sketched previously. However my aim, as Eric quickly observed, is
not necessarily to improve existing APIs but to scope CarbonEvents
to a larger context. After due consideration, I think that I
synopsize that larger context as a merge of AppleScript into Carbon.
I will now try to illustrate further and outline major
considerations by playing head honcho of Development Division at
Apple for a moment. As such, I would certainly bear in mind the
classic phrase: "less is more" and would often ask: "How can the
situation for developers be improved by fusing technologies and
presenting a unified interface while cleaning out some dross at the
same time?".
Let's look at all the technologies using typed events and data and
see if an advantage can be had.
Hmmm, CarbonEvents, AppleEvents, OSA, and OSL have commonalites.
CoreFoundation classes have types, let's modernize Resource Manager
to handle them easily.
For our purpose then:
1. Merge AppleEvents with CarbonEvents so folks can just snag
incoming events directly from their handlers.
2. Automatic but over-ridable OSL handling for application
properties and all HIToolbox objects.
3. 1 and 2 above imply that a subset of the relevant CarbonEvents
may be parceled off into an OSA component.
4. OSA component description also available from it's plist,
selectors expanded to 32 bits with mnemonics.
5. The counterpart of AppleScript Studio, i.e. Carbon Studio is
realized.
6. CoreFoundation classes pack their types with them for auto-
coercion into typed formats.
7. Resource file format upgraded to larger capacity and limits,
CFTypes read/write as well as handles.
8. All pertinent enums in AERegistry.h, FinderRegistry.h,
AEDataModel, etc. cleaned up to match the excellent naming
conventions in CarbonEvents.h.
9. Check into some mechanism to make all these types accessible as
UTTypes (kUTTypeType) and see if it can be a part of CF on Darwin.
Their description includes the struct/class they pertain to.
Thanks again, I enjoy a thought-provoking question immensely,
Philip Aker
email@hidden
