Is it possible to make a Cocoa app scriptable using Ruby instead of AppleScript? Any reasons why I shouldn't?
Even if one has to use AppleScript, there are still the following alternatives:
The AppleScript dictionary only contains one "function": "sendRubyScriptToApp". What this "function" (not sure what they're called in AppleScript) does is to simply pass a string containing the entire Ruby script that the app accepts.
Use AppleScript in the regular way.
What would be some advantages and drawbacks?
I think there are many disadvantages of going against the grain with AppleScript. Mainly because you have to then embed a ruby runtime in your application to get your idea to work. I suggest using AppleScript the regular way and then using rb-appscript to script your app. Rb-Appscript will allow you to create ruby code that interfaces with your application via AppleScript.
Related
I am developing an Applescript application using X-Code and I'm having the hardest time finding answers to questions. It's tough because I'm struggling to understand how the UI elements work, etc., and most answers to those questions are written in Objective C. I have learned a little bit about how to convert Objective C code into Applescript, but in most cases I'm still not sure.
For example, this answer shows some ObjC code, but I don't know how to make use of it in my Applescript application.
Is there a resource or guide that can help me to a) understand how to use Objective C code in my Applescript app, and/or b) how to rewrite Objective C code in Applescript?
In general, Applescript can be used to automate tasks (especially repetitive ones) for any MacOS application that exposes an Applescript dictionary.
One can compile and execute Applescript from within MacOS applications written in Objective-C (via the NSApplescript class, but the other way around, one would use Applescript to call into an already existing app (or one that you created yourself) that was written in Objective-C.
It sounds like you should write the lowest level stuff natively in Objective-C and see if you can automate that from within Obj-C, or expose an Applescript dictionary (via an sdef file that gets included in the Xcode project) and then you can use Applescript to do things via your native app.
Makes sense?
Is there any way to add additional AppleScript command, other than those listed in its documentation, to a scriptable application in mac os?
There are many events that application has but the script command for them is not listed. Is there any other way to send those commands to scriptable application?
I found ScriptingBridge framework, but it seems framework is only an objc wrapper to apple script.
No, to do this you would have to change the code of the application and of course you can't do that. How an application responds to applescript commands is hard-coded into the program. However there is another approach. You could use gui scripting which means you can simulate mouse clicks and stuff on menu items, buttons etc. which may give you the ability to applescript what you need. Without more info about your specific task it's hard to give a solid suggestion though.
I want to create an Objective-C application which lets you specify a class implementation at runtime.
I want the user to type some code (correctness of the code is out of scope for now).
When the user is done i want to create a class of the typed code and use it in the application.
So i want to dynamically add code in runtime of the application. Is this possible?
If so, how can i achieve this? If not, why not and are there any alternatives to create the same effect which i want to create?
Thanks.
You can dynamically load classes at runtime, but to get there you'd first need to handle distributing a compiler, its compilation dependencies (headers, ...), setup its enviroment, etc.
Usually applications use scripting languages that are painlessly embeddable (Lua, Python, ...) or already available on the platform (JavaScript, AppleScript, ...).
I'd check out F-Script. It's closer to smalltalk than Obj-C, but IMO it's closer to Obj-C than JavaScript or Lua :-)
On iOS devices, this isn't possible. On a Mac you could link against the clang+llvm libraries and use them to generate code into a buffer, then mprotect() the buffer to be executable, I believe.
I don't want to go the full rubyobjc, how would I be able to use a few ruby-terms in my cocoa/objective-c code?
The reason I want to switch is because I really like ruby's syntax. It's awesome!
If it's not possible, then I'm wondering if rubyobjc is good...
Unfortunately I've heard that when using rubyobjc there isn't a nib/interface builder.
Check out MacRuby, I was just watching a screencast on it the other day and he was able to use Interface Builder and call objective-c methods and ruby methods together to build a simple osx desktop app.
And now that Apple has lifted restrictions on iOS software, it might be possible to use it for iPhone/iPad development.
You can't mix Ruby terms or syntax into Objective-C source files. You may be able to make some classes in Ruby (with MacRuby) and other classes in Objective-C, though.
The issue is that I've written a Safari plug-in (Growler) that allows web applications to send Growl notifications by calling Javascript functions. However, at the moment the way it is written, people need to use <embed> to initialise the plug-in so that Javascript can begin using it (something I picked up from Apple's examples).
I was wondering if there was a way I could define something like window.<pluginName> so that they didn't have to embed it everytime? That'll allow a lot of sites to begin using it without changing any code.
I've looked at a lot of examples and documentation, and two things came up — 'WebView' and 'WebScriptObject'. I'm pretty new to this, so I'm not really sure what to do.
There's no way to write a WebKit plug-in that doesn't handle a content type. That's why so many Safari “plug-ins” or “extensions” (including GrowlSafari) are implemented as input manager hacks.
The way you've done it is the only reliable, safe, supported, and not doomed way to do it.