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]