site_archiver@lists.apple.com Delivered-To: cocoa-dev@lists.apple.com User-agent: Microsoft-Entourage/11.1.0.040913 on 2005-03-31 8:56 AM, M. Uli Kusterer at Witness.of.TeachText@gmx.net wrote:
could you give us some more information about what tasks your app actually performs.
It is the UI Actions Setup utility, which comes with our PreFab UI Actions product. We are substantially enhancing the utility's UI for the next version of the product, for release when Tiger is released. <http://www.prefab.com/uiactions/> The Setup utility provides UI to "attach" an AppleScript script to any application, so that the script will be triggered every time the user performs a specified user action in the target application's interface (for example, when you choose a menu item in Mail, open a window in iCal, or edit some text in TextEdit). One of our enhancements is the ability to "export" sets of scripts for later "import," to facilitate project-oriented use of UI Actions. The problem I've been discussing here relates to one feature of an attached script, namely, that it can be filtered or unfiltered. For example, the user can arrange that the attached script be launched only if the menu item that triggered it has a specified title (filtered), or instead that it be triggered in response to every menu item (unfiltered). The problem I've been discussing comes up when the user already has one or more attached scripts with specific filters. If he then imports a saved set which includes the same script to be attached to the same target application for the same user action but with no filter, there is a conflict. It isn't necessarily obvious to the user that importing a no-filter script means that existing attached scripts that do have filters must be removed (i.e., that the script should now be triggered at all times, with no filtering). The mirror-image issue arises when a filtered script is imported and a no-filter script is already attached to the same target application for the same user action. A script is either filtered or unfiltered; logically, it can't be both. The accessory view suggestion seems to me to be the best way to deal with this. I could include a short phrase describing the issue and a radio button group that defaults to telling the utility to always honor the imported set in the event of conflict (I think of this as the "I meant what I said" default), with alternate radio buttons to prefer filter or to prefer no filter in the event of conflict either way (for example, preferring filter will resolve the conflict in favor of the filtered script, whether it's the one being imported or the one that is already attached). What I haven't yet decided is how to draw the user's attention to the presence of a conflict when one arises, beyond just enabling the radio buttons only when they're relevant. The accessory view will probably also provide a minimum of information about the currently selected set. For example, how many scripts it contains, and perhaps a list of the target applications, as a bit of a reality check for the user who may have forgotten what he stored in that set previously. This is an exploratory feature, useful even apart from the filtering conflict issue. If I had anticipated an export/import feature originally, I might have designed the filter feature a little differently. But the product's market doesn't justify a complete rewrite. There remains the possibility, however, that my mind is still too tightly bound to my existing data structure, and that a simple conceptual shift with changed wording might clarify all this for the user without requiring a lot of reprogramming. -- Bill Cheeseman - wjcheeseman@adelphia.net Quechee Software, Quechee, Vermont, USA http://www.quecheesoftware.com PreFab Software - http://www.prefab.com/scripting.html The AppleScript Sourcebook - http://www.AppleScriptSourcebook.com Vermont Recipes - http://www.stepwise.com/Articles/VermontRecipes _______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/site_archiver%40lists.apple... This email sent to site_archiver@lists.apple.com