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
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
