I hear you. Despite appearances to the contrary, AppleScript is not the right tool for developing real applications. I have already promised myself that I will learn PyObjC and use Python+Cocoa after I finished this project, then use AppleScript only for mom and pap stuff as clearly this is what it was intended for.
Studio seems to be an absolute overload – so utterly out of line with what AppleScipt is meant for. It feels like you’re driving a Bentley powered by a mountain bike. It’s a really great mountain bike, but it wasn’t meant to power a Bentley, never will be.
At the time it seemed a good idea to use AS Studio because it seemed an easy way to get into building Cocoa apps and back then I didn’t know about PyObjC. In hindsight, the time I spent on finding my way around AppleScript’s bazillion bugs, quirks and inconveniences, I may as well have become proficient in PyObjC but I digress.
For now, I have to stick with it at least until this project is done (approaching 3500 lines of code now, probably ending up way above 5000).
Python is not a shell script language, it is a genuine OO programming language along the lines of Java and it performs a lot better than AppleScript.
If you are talking about a server application that runs standalone to be called from outside (a so called Library Server), this is a very bad idea for a Studio project.
The library server can only serve handlers which do not access any Studio objects. It won’t interact with the Studio supplied handlers such as “on clicked”, “will open”, “will close” etc etc etc, or if you need to address values of buttons, text fields, steppers, progress bars, etc etc etc.
Xcode links all scripts within a Studio project into a single application. So even if you have scripts in your project that don’t even know about each other, they will still end up being part of the same application, just that neither AppleScript nor Studio provide you with any means of letting them talk to each other. That really really sucks and it shows that Studio is a bolt on to AppleScript which wasn’t meant to be.
Consider the following example …
Main.applescript
property DataForManipulationbyInspectorWindow : { whatever }
...
on choose menu theObject
if the name of theObject is "InspectorWindow" then
set visible of window "InspectorWindow" to true
else if ...
...
end if
end choose menu
...
InspectorWindow.applescript
...
on clicked theObject
if the name of theObject is "SomeDataItem" then
set SomeDataItem of DataForManipulationByInspectorWindow to (state of button "SomeDataItem")
(* the above won't work because we have no visibility of DataForManipulationByInspectorWindow *)
else if ...
....
end if
end on clicked
I have tried to declare DataForManipulationByInspectorWindow as global, but this won’t work because InspectorWindow.applescript is not a script object of Main.applescript.
Of course I can load InspectorWindow.appescript into Main.applescript by using load script in Main’s will finish launching handler, but that will not work either because Interface Builder targets the automatically linked by Xcode copy of InspectorWindow.applescript not the second instance created by the load script command. In any event, even if it worked, it would be rather wasteful to have two instances of the same script in one application where only one of them is used.
This only shows that Apple designers haven’t thought their implementation of Studio through very well. Their attitude would seem to be “This is only for Mom and Pap programming anyway, so let’s not get too fancy here”, but following that philosophy they shouldn’t have developed Studio in the first place.
If Xcode links all the scripts in your Studio project into one single Application anyway, then there should clearly be a mechanism to make those scripts communicate with each other. Data encapsulation is a great thing, but it only makes sense if there is a means to import and export encapsulated objects otherwise it isn’t data encapsulation, it becomes data orphanisation which serves no purpose at all.
The solution would be a Studio-only addition to AppleScript that lets you declare data objects in one script of your Studio project to be visible to other scripts in your Studio project in a similar way as the “global” keyword does for script objects. For example …
Main.applescript
property DataForInspector : { whatever }
Inspector.applescript
use property DataForInspector of Main
This would be very simple to use and fit perfectly into the AppleScript philosophy. Since both Main and Inspector scripts are part of the same Studio Xcode project it is easy for the compiler to resolve and initialise references such as “DataForInspector of Main”, after all they are just pointers.
Any of them AppleScript Studio folks reading this forum??? How about implementing this and ship it with Tiger???
but anyway, as you said, AppleScript is really just a glue-between-applications tool and I have probably outgrown the tool. The future will have to be PyObjC.
thanks
rgds
benjk