Hi
Just wondering what peoples thoughts are on this! I have quite a bit of my workflow scripted up and already a few bits don’t work anymore after updates of Applications!
Best
Hello.
It may be a nuisance, but it is the price for progress!
What more is there to say, it isn’t cheap to create applications, and people may have enough to do, by making the scripting work for the current app, and not keeping the model for the old one. For, if the scripting dictionary was to dictate the development of an app, then you’d add seriously to the cost, since this perspective would be a very unnatural one. Keeping the dictionary working as it should, now that is a different story. If it is there, it should work!
But then again, testing the dictionary fully out, that may also be considered, understandably a periphal activity during testing. It has at least second priority.
If you mean you have reason to be dissatisifed with a product, take contact, and explain your problems, or file a bug!
Thanks, that all makes sense but I was just wondering generally what peoples thoughts are in the longish term for applescript - a bit just out of interest I guess but not completely as I use it!
Hello.
It has been around a while, it started on the previous os platform. IMHO this is Apple’s competetive edge, molded into Mac Os X applications; from the moment you write the first few lines of Objective-C, a script model is there, parallelling the data-model of your app. I am not a psychic, but I guess Applescript will be around as long as there is Os X, and maybe longer.
Although generally there have been a lot of “disruptions” lately I think Applescript and automation are here to stay. That said, I think it would behoove everyone who writes Applescript to definitely learn ASOC and as much Cocoa/Objective-C as they can muster. OBJC is clearly creeping its way into scripting. In a way this is good as using more native calls for high performance functions is a good thing. But it does add to the complexity of Applescript. It has also added to it’s ability to create useful apps with UI.
My personal feeling, based only on 14 years experience of the evolution but no insider knowledge, is that Applescript may morph into being “more” objective-C and “less” of old style (easy/simple) scripting. Knowing Obj-C will be a requirement to Applescript. Maybe the end game of all this nonsense of GateKeeper (aside from simply stopping virii) is that Applescript could directly call ObjC calls of the applications they are trying to control, bypassing the byzantine structures required to support Applescript and the calls it makes to 3rd party apps.
I started in Mac OS 8 and started to do everything with applications. Using file management with the finder etc… Through the years I was spending much time keeping the scripts compatible with newer version of OS X and Software. Today I’m writing scripts more application independent. Which means I never use the finder and avoid using other applications. Besides that most of my scripts are today XML-RPC driven and not locally anymore.
Not really.
When you’ve enabled scriptability in Info.plist, you get the free Standard Suite, which is not very much (see Preview.app).
For a custom data model you have to specify the sdef file including all custom four-character event codes.
Then Cocoa provides the scripting bridge from and to defined properties automatically, but the programmer is completely responsible for the error and coercion handling and some other things. That’s the main reason why AppleScript is not consistent in its behavior
Hello.
I didn’t mean that everything would automgically work, but I feel I stand on solid ground when I say that it is molded into a Cocoa, if not Objective-C app.
I know it requires a substantial amount of work to make it work satisfactorily, which I get to work with real soon now!
If all that it takes to enable it, is to specify a property, then it is pretty much molded in my book. 
Preview isn’t much to brag about. You even have to hijack it after you have turned on the script-ability that is latent, as I have understood.
As for the differences in the Applescript dictionaries:
Not specific to Preview.
It’s supposed to be the case for every signed application.
If one edit the plist file, the piece of code checking that the file is in its original state returns false and we can’t execute the application.
I was able to create a local signature for Preview under 10.7 but I failed under 10.8.
It would be fine if many of us ask Apple to enable scriptability in all their applications.
It would cost nothing and would allow us to get some informations before applying GuiScripting.
Yvan KOENIG (VALLAURIS, France) mercredi 27 février 2013 17:59:43
Like if we all filed a separate bug? A DRADAR attack?
I guess they guess that they won’t get complaints about the lacking in the scriptability, if they turn it off.
It is still rather unheard of, Apple applications, that aren’t scriptable.
And gui scripting, is not a competetive edge, you can GUI script Windows applications… Maybe you can it with Linux and KDE too. Because those are features needed in order to be used/bought by the U.S Government.
I forgot to mention above, that there are at least two GNU/Linux projects (or similar), that seeks to provide binary compatibility with Mac Os X, that is, they want to be able to run Mac Os X apps on other platform, if they succeed in this, both technically, and legally, then AppleScript might widen its horizon.