On 2006-10-14, at 16:11:14, Walter Ian Kaye wrote:

>> I don't know anything about Eudora. I saw it on a friend's Mac in  
>> the  mid-90s and decided it wasn't for me.

> It's the bee's knees, man! I've been using it since the early days  
> (v1.5?). Totally configurable (except for one thing*), and even  
> lets me edit *incoming* messages, which is great for fixing  
> people's ghastly misspellings. :D

I'm more or less happy with my pine/Mail combo. I just have to figure  
out how to coordinate pine's INBOX with Mail's. At the time I found  
Eudora's UI to be kinda backwards to the way I worked so just let it  
slide. I don't have any comment about whether or not it's good software.


>> However, as a workaround type of solution, I think what you can  
>> reasonably ask is if the product will meet accessibility  
>> requirements  (i.e. be scriptable with "System Events").

> Uh, you're joking, right? "Puppeting" a UI does not count as  
> scripting. If there are no "accessor functions" available, then  
> it's not scriptable. You have to be able to "get" and "count" and  
> so on. You know that.

No I'm not joking (unfortunately as I mentioned in a previous post,  
I'm currently bereft of jokes). If it's the only thing that users can  
count on then deal with it. To be basically UI scriptable, both  
Carbon and Cocoa apps don't have to do anything for any controls  
available in Interface Builder (or creating the same with system  
APIs). It's only custom widgets that should supply the needed  
information with the predefined AXxxx set of APIs (less than a dozen).

UI scripting isn't perfect but normally all menu items, clickable  
items, and widget contents are available. What is needed after that  
is a set of convenience wrappers around SE calls to do the counting  
and reformatting of raw data etc. Another thing that's quite easy for  
the developer to provide is a decent preference file and application  
files in a known format. Like the .emlx files that Mail has so that  
some things can be addressed by shell tools such as 'defaults' and  
'xsltproc'.


>> These days, it's very easy to create a scripting dictionary  
>> because .sdef files are xml files.

> I don't think the data structure was ever the hard part. It's the  
> figuring out what to put in it, and implementing the functionality  
> which take all the work.

JD's approach is fundamentally correct. It's recommended in the  
documentation that the AS dictionary be designed first and then cast  
in code. You can get a vague C++ outline with xsltproc if you work at  
it. What I'm suggesting for JD is to scan the dictionaries of all  
mail apps, and perhaps some other apps that he enjoys, cut 'n' paste,  
and then play senior editor and when he's done, post it for comments.  
He's certainly good enough a scriptor to know what he wants. The  
watch point is not to put in too much at first and leave each major  
element an opportunity to grow. For instance, one thing that can grow  
easily are enumerations such as those available for "path to ..." or  
saving options.

Then comes the time when people who've done implementations can make  
suggestions for making the functionality easier to implement.

It's also possible for the developer to let plugins implement  
scripting facilities. There are required AE calls and then there are  
all the rest. He could provide access to selected structures through  
a few APIs for plugins -- let them fight it out for top AE dog ("Best  
In Show" and all of that :-).


Philip Aker
[log in to unmask]