On 04/05/15 3:41 PM, "Paul Berkowitz" <[EMAIL PROTECTED]> wrote:
> On 5/15/04 1:48 PM, "Frederico" <[EMAIL PROTECTED]> wrote: > >> Things to accomplish: [...] > >> � Find and generate a list of folders to choose from, on which to set focus >> on and apply the scheduled Rule (easy) > Not all rules have anything to do with folders, of course. No, but on first glance, it seems appropriate and necessary to focus the UI on the folder that contains the items on which the rule is to be applied, so that said items can be visibly selected by AS in order to apply the desired rule. Make sense? > >> � Build a generic Apply Rule ->[Rule]-script generator (fairly easy); best >> done with GUI elements and not keystrokes (to avoid inevitable conflicts) > > Huh? Not sure which part of the above you're huh-ing. Part one refers to building a script generator, much like the one I posted a few days ago that makes individual Play Sound scripts; this one would generate the required base code and assign the given variables; i.e., what items do I perform the Rule on, and what Rule do I use; what reporting and error handling do I use, etc.. I'd like to explore using more background apps (Terminal/bash, Finder's write-to-file, etc.) to actually create executable scripts without involving Script Editor, if possible, but Script Editor should be a default install, anyway, so other than the GUI noise it creates while auto-building the target scripts, it's not entirely a bad thing. Part two is simply trying to decide whether or not it will be more reliable to use GUI scripting elements (sub menu of menu of menubar etc.), or defined keystrokes, as I outlined in the proof of concept in my previous post. The latter adds considerable complexity, as it requires manually assigning non-conflicting keystroke combos to Rules prior to generating scripts, and the further tedious step of Quitting and relaunching MSE for said keystrokes to take effect. More reliable, yes, but more difficult (read: tedious; conflict-prone) to implement, even though much of that can still be scripted through AS and shell (e.g., defaults write [keyboard prefs]<key><variable>). I'd just like to see as few elements and layers as possible. > >> � Devise a method or application outline to avoid interference with the user >> when timed Rules must be applied (given that application/window/message >> focus seems to be required to execute the Rule) [...] > > It might be a mistake to try to do this by GUI methods, although you might > have luck. You should be aware that GUI scripting only works in Entourage > using menus, not buttons or any other controls, but since the submenu for > Message/Apply Rule/[List of Rules] _should_ be available you just might be > able to do it that way. Both the posted and a non-posted proof of concept works here. The question is how reliable will GUI scripting be across deployments. I'm sure I don't have to tell you how generally goofy this stuff can get at times. It's just impossible to predict what kind of delays you need to add to make it work for every user environment and CPU speed and haxie overload, etc., but, luckily, there is a minimal number of menu elements to navigate, and they remain reasonably static. Only testing will tell. > You might even be able to get the list of rules this > way too. and have the user 'choose from list' using this list. I'm hoping this is true. I'm just worried about element orders changing and messing up the target Rule. Not sure how MSE reports moveable/re-order-able/ rename-able menu elements RE: Rules in regards to AS yet. > > The main problem will be that in order for the Message/Apply Rule/ menu to > be available, a folder first has to be selected in the UI and then every > message in the folder selected. This -has_ to happen every time the schedule > runs. Although this can be done by AppleScript, it would always interfere > with whatever else you are doing at the time, and could create a mess. I > don't think this is a smart way to do it, because most of the time it will > interrupt you in whatever you're doing, or maybe fail. Agreed, and I thought I said pretty much just that in the original paragraph above. (: Not quite sure how best to deal with this yet. The most obvious solution is to avoid the problem and hope the user times the schedules to run at times when the computer is awake but the user is not present. Yeah, right. Off the top of my head, the next idea is to run a preflight dialog warning (tell [frontmost app] display dialog), telling the user what's about to happen, and give them the option to delay the actions to later or cancel to the next cycle; if the user isn't there to see the warning, it will time out and go ahead. It could optionally be combined with spoken word or soundbyte alerts to forewarn the preflight, too. It should also be possible to determine the current focus app/window of the user, and if the user opts to allow the Rule/script to execute, return the user to the state they were in prior to the run. Awkward, yes, but I'm not sure how we can do much better, given the limitations of MSE. Unless, of course, the user is content to only schedule such scripts to run on Startup or Quit. Wouldn't that be loverly? > The best way would be what Dan proposed, and I will look into this. I must have dropped Dan's post; can you reiterate his suggestion, please? > But it > will be quite a big project and won't get done too quickly. However, it's > something I am genuinely interested in doing. The biggest hurdle, IMHO, will be getting the list of Rules and determining the variable element position; the rest, I think, is cake. If it takes more than six to eight hours of dedicated scripting and debugging between us to have a viable public beta, I'll be surprised -- very surprised -- and that's not counting for repurposing any number of script elements and handlers we've already written. Not that any of us have six or eight hours of dedicated scripting time to just toss about, but I think this is useful enough to be of help to a large enough number of people. If you want to get me access to the list of rules and help work out the element structure ( I still cringe and have trouble with a lot of the GUI stuff; just not enough docs or samples for my addled brain to decipher), I'll be happy to tackle the autogen and UI issues. Cheers Mr. B. (: Frederico -- To unsubscribe: <mailto:[EMAIL PROTECTED]> archives: <http://www.mail-archive.com/entourage-talk%40lists.letterrip.com/> old-archive: <http://www.mail-archive.com/entourage-talk%40lists.boingo.com/>
