[Sal]

you mentioned facespan earlier... any idea whether DTI plans to carbonize it? (i helped design it for another --now sadly defunct-- company.)

Last I heard they were planning to Carbonize.

That wasn't a company in North Carolina which had somebody's "uncle" involved? ;-)

[Sal]

As the net and scripting becomes more pervasive (e.g. Outlook running VBX scripts under Windows), I think sandboxes and apps/scripts signing are becoming vital.

So, can a given AppleScript be run in a sandbox (like the option the JavaVM offers), e.g. with file/network access disabled? If not, is it a planned feature?

Here's a political answer: We've examined this issue thoroughly and are aware of the concerns you raised. ;-)

Please note, however, that unlike the VB scripts problem on Windows, AppleScript scripts aren't run automatically when received and unpacked by a mail application or as AppleScript code in an email.

If you send someone a compiled script it must be loaded and executed by another application or process. If you send someone an applet, it must be launched by double-clicking it, telling the Finder to open it, or sending it a run event.

This is not to say that AppleScript scripts cannot be disguised as other items, but much of the responsibility here must lie with the user acting responsibly with what they download or receive in emails.

For example, reading and writing to files is a very common and legitimate task that AppleScript performs (such as working with prefs and stored data) and it would be difficult to determine which events should be boxed, etc.

[This message has been edited by Sal (edited 09-22-2000).]

[edgewise]

Originally posted by Sal:
Last I heard they were planning to Carbonize.

That wasn't a company in North Carolina which had somebody's "uncle" involved? ;-)

yep. i'm not Uncle D, though; i'm one of the other, less memorable guys.

it's great to see that applescript has weathered all the changes in cupertino, and is being supported so aggressively in the new OS. good luck to you and your team!

[This message has been edited by edgewise (edited 09-22-2000).]

Sal,

We can't go on meeting this way ;-)

I notice a lot of the new X apps have dictionaries, but many of them seem to contain a lot of repetition -- the application class might appear twice, in too different suites, and so on.

Is this just the state of things in beta apps, or due to something somewhere else making them *appear* to be repeated?

[Sal]

I notice a lot of the new X apps have dictionaries, but many of them seem to contain a lot of repetition -- the application class might appear twice, in too different suites, and so on.

Is this just the state of things in beta apps, or due to something somewhere else making them *appear* to be repeated?

Shane! We just had a group from down under in the Briefing Center the other day and your name was bantered about often. I'll bet you can expect some calls from them soon!

Having been focusing on core issues, we haven't yet begone the process of spreading scriptability throughout the OS, re-working dictionaries, etc. It's still early in the game and as you know, may take a couple releases to get things right.

It's been a long road since 1993--thanks for your continued support.

[This message has been edited by Sal (edited 09-22-2000).]

[Sal]

yep. i'm not Uncle D, though; i'm one of the other, less memorable guys. it's great to see that applescript has weathered all the changes in cupertino, and is being supported so aggressively in the new OS. good luck to you and your team!

Thanks. And thank you for giving the world a great application that has lasted nearly a decade and has done much for so many.

heya Sal,

I was at the apple expo paris's webobjects conference featuring Eric Noyau (who is french btw). While talking about perspectives for webobjects 5 and beyond, he mentioned a possible bridging between Webobjects and standalone Applescripts on the mac desktop. To what extent is this true and how are you planning to implement this feature that poses as a serious security threat if implemented improperly.

yours,

thomas from paris

[Jaddie]

Dear Friends

It's very exciting to see Sal Soghoian posting here! Sal is a real somebody at Apple. (I refer to him as "Sal" because he told a group of us seminar attendees at Macworld New York in '99 that he preferred "Sal" to "Mr Soghoian".)

I wrote my first useful AppleScript earlier this year. It's awfully simple by the standards of some of you, but some of you might find a modified version of the script useful. The script opens my email, checks select email accounts, then opens two windows in Internet Explorer: MacNN and Version Tracker. Here it is:

tell application "Outlook Express 5.02"
activate
connect to POP account "[email protected]"
connect to POP account "[email protected]"
connect to POP account "[email protected]"
connect to POP account "[email protected]"
end tell

tell application "Internet Explorer 5"
Activate
OpenURL "http://www.macnn.com/"
get window = 0
OpenURL "http://www.versiontracker.com/" toWindow "0"
end tell

Another simple AppleScript I use opens SoundJam and my music folder at the same time. Here it is:

tell application "SoundJam 2.5.1"
activate
end tell
tell application "Finder"
activate
open folder "Music" of disk "Scooby"
end tell

These scripts are a little embarrassing to post before Sal and other advanced Mac users, but surely there are a few readers who could benefit from using such simple scripts, or by seeing how easy and simple AppleScript can be.

Again, it's absolutely wonderful to have Sal here. Thank you very much, Sal, for taking time to contribute. Thank you also for your work with AppleScript.

Sincerely
Jaddie
Proud MDJ Reader

[This message has been edited by Jaddie (edited 09-22-2000).]

Originally posted by edgewise:

yep. i'm not Uncle D, though; i'm one of the other, less memorable guys.

it's great to see that applescript has weathered all the changes in cupertino, and is being supported so aggressively in the new OS. good luck to you and your team!

[This message has been edited by edgewise (edited 09-22-2000).]

Hi, Sal!

I'm a longtime Facespan fan and will use it happily if they bring it to OSX, but I've also glimpsed OS X's developer tools, including their interface builder. What are the odds of that Apple-made tool producing interfaces that are scriptable?

BTW - At a developer's conference (and crab-fest) for Page Planet Software's MGI software, I heard you've put together a new promotional CD for AppleScript on OS 9. I'm going to be teaching AS to a group of people soon. Is there any way I can get ahold of a dozen or so disks?

Tim Stiles
[email protected]
CargoGods, Inc.
Dallas, TX

In MacOS X Desktop has replaced Finder so there is no more Finder Dictonary. While Standard Additions contains many file/folder related commands certian things can only be done by the Finder under MacOS 9. How should I replicate Finder based scripts under MacOS X?

[eyost]

Sal,

Good to see you here! I gotta tell you I'm excited about OS X and can't wait to get my copy; just waiting to get some more memory to be able to run it. It's good to see Apple utilize the stability of Unix as a core to the OS. I've been a Mac user since the Plus. While there are some things I'd like to see Apple do, I have to tell you I prefer to use the Mac over anything else. I support software that is written for Windows and can tell you that Windows has far more problems then the Mac OS does; all the other support members at my company get tired of hearing me say "With a Mac, we just plug it in and it works!".

Since you're the AppleScript guy, got one question for you. I'm trying to learn AppleScript but am just not grasping it. I respect the power and flexibility it has and am sure I can do more with it. Can you suggest a good resource or book that could help a beginner along?

Thanks for the help,

Ed

Hate to bring conversation back to CGI....

I am in the process of starting up a web hosting operation, and one of the things that really scares me is the potential for user uploaded scripts to do BAD THINGS, even inadvertently. Will OS X limit Applescript CGI's in the same way that *nix limits CGI scripts?

And as an aside... I have really started to like Python, while not english-like, it has to be the most coherent, well designed language I have used.

The power of AS and OSA (as far as I am concerned) lies in being able to maniulate the objects in compiled applications. This ought to be extended to scripting languagers like Python, TCL, and Perl, so that the objects in non-compiled programs could be used in AS...


-Ross

[Sal]

In MacOS X Desktop has replaced Finder so there is no more Finder Dictonary. While Standard Additions contains many file/folder related commands certian things can only be done by the Finder under MacOS 9. How should I replicate Finder based scripts under MacOS X?

To AppleScript, the Desktop app in Mac OS X is the Finder app from Mac OS 9. Open the Desktop app's dictionary and you'll see the Finder dictionary.

Note that much of the dictionary is still not connected at this point but will be for the release. We ship some sample scripts demonstrating Desktop scriptability in the GrabBag - AppleScript folder with the Script Runner application.

BTW, your scripts written for the Finder will automatically switch to the Desktop. Open one in the Script Editor and you'll see the name change.

Originally posted by Sal:
[snip] take some time to implement such behavior though. Mark Aldritt (Latenight Software) has already written a JavaScript OSAX which gives a user the ability to write OSA scripts in JavaScript, though I'm not sure about the status of its porting to Mac OS X.

Hi Sal, long time since we've talked.

If I'm not mistaken, Mark's JavaScript work is not an osax but an OSA component, thus, when in Script Debugger or Script Editor you can select JavaScript instead of AppleScript in the OSA Component popup menu.

best,
-wayne

[Sal]

I am in the process of starting up a web hosting operation, and one of the things that really scares me is the potential for user uploaded scripts to do BAD THINGS, even inadvertently. Will OS X limit Applescript CGI's in the same way that *nix limits CGI scripts?

And as an aside... I have really started to like Python, while not english-like, it has to be the most coherent, well designed language I have used.

The power of AS and OSA (as far as I am concerned) lies in being able to maniulate the objects in compiled applications. This ought to be extended to scripting languagers like Python, TCL, and Perl, so that the objects in non-compiled programs could be used in AS...

At this time, AppleScript support for CGI's in Mac OS X is still under development. Security is always a prime concern and proper precautions will be taken.

As far as adding other languages to OSA, etc.: Once we've completed the intial development of AppleScript in Mac OS X, we can start to address the ideas you listed. We're very interested in extending the power of AppleScript and other languages, but for the present, we do have our hands full with building a robust framework and implementation of AppleScript in our new OS.

Isn't great having a new future with Mac OS X? Lots of possibilities.

[Sal]

I was at the apple expo paris's webobjects conference featuring Eric Noyau (who is french btw). While talking about perspectives for webobjects 5 and beyond, he mentioned a possible bridging between Webobjects and standalone Applescripts on the mac desktop. To what extent is this true and how are you planning to implement this feature that poses as a serious security threat if implemented improperly.

Sounds very interesting, but at this time, I don't have anything to discuss or announce regarding that topic.

Howdy. It's kinda funny: I already do all of my Mac OS scripting with Perl. I will continue to do that in Mac OS X (if Mac OS X becomes usable). There are things to be done to make MacPerl more usable as a replacement for AppleScript, but it is already easier to use (for me) and just as fast or faster (on a modern machine, for most things) than AppleScript.

$nscp = new Mac::Glue 'Netscape';
$ncsp->activate;
$nscp->make(new => 'window');
$nscp->GetURL('http://pudge.net/macperl/');

The MacPerl toolbox (that makes the Apple Event manager, etc. available to Mac OS) is going to be ported to Mac OS X, and then this stuff will be available under Mac OS X, too.

[Sal]

If I'm not mistaken, Mark's JavaScript work is not an osax but an OSA component, thus, when in Script Debugger or Script Editor you can select JavaScript instead of AppleScript in the OSA Component popup menu.

Thanks for the correction Wayne. At 3 AM, my fingers just type OSAX automatically. ;-)

As an "old-timer" in the world of AppleScript you must be pleased with its progress and inclusion into Mac OS X. Thank you for your valuable contributions to the AppleScript community over the years.

[Sal]

These scripts are a little embarrassing to post before Sal and other advanced Mac users, but surely there are a few readers who could benefit from using such simple scripts, or by seeing how easy and simple AppleScript can be.

Why don't you post the ones for making coffee? ;-) It seems that you've got the automation idea under control. Keep up the good work and thanks for the kind words.

I too would like to thank Sal for hanging out here. The dedication of many Apple employees like Sal offsets the company's arrogance and hands-over-ears approach, to some extent. (Unfortunately, it doesn't make the "new Finder" or Aqua any less detestable to yours truly... Too bad, cuz I wanted to get working on a Cocoa app that took advantage of its newfound scripting support...)

I'd also like to counter some of the IMO offensive and shortsighted remarks made here about AppleScript syntax. I'm a programming veteran of 20+ years with some extensive experience with all mainstream languages and also some other scripting languages, including baroque hacker messes like Perl (whose only real virtue IMO is somewhat improved regular expressions), and I find AppleScript to be far clearer, about a zillion times more productive, and generally more capable (and I've built thousand+ line tools using it). Few languages allow you to reach into any well-designed, object oriented application, and control its guts the way AppleScript does (definitely not Unix scripting, in spite of what its advocates claim). And AppleScript's syntax accommodates personal style, while remaining about as comprehensible as any programming language is ever going to get. It purposely eschews cutesy, syntactic sugar for clarity. Bravo.

It's a certainty that along the path to full AppleScript mastery, there will be some hiccups - I taught myself, and have been through that. However, one should not conclude that AppleScript is therefore "not inuitive" or impossibly difficult. It's not. There are a few basic concepts that are used fairly uniformly throughout AppleScript, and you should master them early in your learning of AppleScript (the much ignored AppleScript reference is in fact a great document, though non-programmers will find the terminology a bit confusing in certain places). If you find yourself getting stuck, realize that you've probably encountered something significant; a nontrivial misunderstanding that, if resolved, will help you understand a lot more about the language. Find someone who really understands AppleScript, and ask why it is that something that you think should work doesn't; you'll quickly learn that most of those cases are similar, and that there is usually another, not-so-tricky and fairly obvious way to get what you want. Mind you, there are a few genuine quirks; so be it.

One great and underappreciated thing about AppleScript is that it is very logical and clean considering it's power. It's darn near minimal; you couldn't design a language with a lot less features that does what it does. This lends it a refreshing clarity and simplicty, and it tends to be free from lots of confusion and "similar but different and none quite good enough" ways to do things, like horrible, sprawling minefields of committee-designed-mess languages such as C++. (AppleScript absolutely serves a different audience, and turning it into C++ would be the ultimate tragedy; don't cave to the C++ people - if that's what they want, have them use C++, eh?) Also, as Sal has at least partly pointed out, OSA (the underpinnings upon which AppleScript is built) allows other languages - with sufficient support of the OO concepts it embodies - to plug into the system, and be treated as equal citizens. This has been true for about seven years; those programmer types who just have to have some other language with messy syntax should stop complaining and do something about it.

Also, the analogy to English was poor: you do not need to understand all or even most of English's quirks - which are quite different in both concept and detail - to use AppleScript. It is true that some things like noun / verb / modifier order are similar, but even that could change if the engineers decide to extend the localization support (to support other terminology orders for AppleScript).

Anyway, I hope the beginners here will persist in learning AppleScript. As I say, there will be rough spots, but understand that programming is still a complex job and no programming language with real power will be completely simple. *For what it does* AppleScript is about as simple and "intuitive" as programming is going to be. Give it a chance and keep trying. There are a few hurdles to overcome up front - but there is a reason for them, and a payoff. Ask questions when you get stuck. And you too will discover one of the Mac's great stengths: system-wide scripting and integration of unprecedented power, lucidity, and productivity.

-jar

[Sal]

Since you're the AppleScript guy, got one question for you. I'm trying to learn AppleScript but am just not grasping it. I respect the power and flexibility it has and am sure I can do more with it. Can you suggest a good resource or book that could help a beginner along?

Bill Briggs has an excellent set of tutorials for the "common man" posted on MacCentral. Here's the link.

[Sal]

Anyway, I hope the beginners here will persist in learning AppleScript. As I say, there will be rough spots, but understand that programming is still a complex job and no programming language with real power will be completely simple. *For what it does* AppleScript is about as simple and "intuitive" as programming is going to be. Give it a chance and keep trying. There are a few hurdles to overcome up front - but there is a reason for them, and a payoff. Ask questions when you get stuck. And you too will discover one of the Mac's great stengths: system-wide scripting and integration of unprecedented power, lucidity, and productivity.

Well said. Thank you.

Originally posted by jar:

Also, the analogy to English was poor: you do not need to understand all or even most of English's quirks - which are quite different in both concept and detail - to use AppleScript. It is true that some things like noun / verb / modifier order are similar, but even that could change if the engineers decide to extend the localization support (to support other terminology orders for AppleScript).

-jar

Many people feel that the "english like" syntax is a step backwards.
It sounds nice, but its niceness is stuck at a very superficial level.
In reality it makes it more difficult to deal with the deeper aspects
of your algorithm.
No doubt this argument has gone round and round
at Apple.

[p]
Maybe now is a perfect time to run an experiment. Have some reasonable
task, like say doing something to certain files or doing something to all
your email. I'd love to see the results where typical mac users tried
to accomplish the task in
applesscript vs. javascript. Javascript seems like the no-brainer choice,
since so many HTML people are already know it and it's a reasonable implementation
of the very-simple-language-with-traditional-syntax sweet spot.

[phowson]

Originally posted by Sal:
Why don't you post the ones for making coffee? ;-) It seems that you've got the automation idea under control. Keep up the good work and thanks for the kind words.

Be careful, you may get what you asked for. I do have scripts for activating my coffee maker, turning on the stereo, turning on and off the lights, responding to messages from motion detectors, and monitoring the thermostat. They use a combination of Extension (www.shed.com) and The ZephIR (www.thezephir.com). 8-)

Hi Sal!

Have you looked at F-script? It's a scripting language tightly integrated with the Cocoa framework, and it has an insanely great feature: it can instantiate Cocoa objects on the fly. Will AppleScript eventually support this as well? I want to be able to write scripts that can dynamically create a whole graphical user interface, and it would be even cooler if this could be accomplished using InterfaceBuilder.

Think VisualBasic, only much, MUCH more powerful.

Sal! I watched your videos from the AppleScript site. Most excellent.

Do you know of any plans to allow AppleScript-based CGIs to interact with iTools, specifically HomePage? I tried creating a CGI script from the tutorial and placed it on my HomePage, but when it tries to execute I receive this error:

This server has encountered an internal error which prevents it from fulfilling your request. The most likely cause is a misconfiguration. Please ask the administrator to look for messages in the server's error log.

I would love to create simple CGIs and stick them on my HomePage. Is this even possible?

Oh, and could we get a link to this forum from the main MacNN page? I think lots of people would be interested in knowing that Apple really is reading the forums...

Thanks in advance.

All,

Just as an FYI. Starting mid-October, Apple will post on the ADC web site The Mac OS X Beta Developer Tools. That includes apps like Interface Builder, Project Builder etc...
All you have to do I become a *free* online Apple ADC member and you will be able to download those tools that will allow you to build awseome apps under OS X for free !!!
For more info: http://developer.apple.com/membership/macosx.html


Hi Sal, just wanted to welcome you to the forum and say that I'm really glad you decided to show yourself as an apple employee. I think it would be terrific if apple had more employees showing a visible presence in the online Mac community.

Now to my comment, I'm one of those weekend developers that messes around with the new technologies and occasionally releases a bit of freeware, but I haven't brought myself to join the adc except as an online member. I think it would be great if apple could release some code examples to get us going on this new OS.

Don't hide documents and code examples from us weekend developers. We write some cool stuff once in a while and are some of apple's biggest supporters.

Originally posted by abner:
Hi Sal, just wanted to welcome you to the forum and say that I'm really glad you decided to show yourself as an apple employee. I think it would be terrific if apple had more employees showing a visible presence in the online Mac community.

Now to my comment, I'm one of those weekend developers that messes around with the new technologies and occasionally releases a bit of freeware, but I haven't brought myself to join the adc except as an online member. I think it would be great if apple could release some code examples to get us going on this new OS.

Don't hide documents and code examples from us weekend developers. We write some cool stuff once in a while and are some of apple's biggest supporters.

[Sal]

Maybe now is a perfect time to run an experiment. Have some reasonable task, like say doing something to certain files or doing something to all your email. I'd love to see the results where typical mac users tried to accomplish the task in applesscript vs. javascript. Javascript seems like the no-brainer choice, since so many HTML people are already know it and it's a reasonable implementation of the very-simple-language-with-traditional-syntax sweet spot.

NickNick,

Interesting. How would you phrase the following script in JavaScript? This script will search the entire hierarchy of a folder on the startup disk for files matching specific requirements. If they are found, they will be copied to a backup disk:

tell application "Finder" to duplicate every file of the entire contents of the folder named "SMITH PROJECT" of the startup disk whose file type is "TIFF" and name contains "PROJECT X" to the disk named "BACKUP"

Sal,

I haven't used AppleScript for ages, but now that MacOS X is coming, there are, as many people have noticed, some interesting possibilities.

I'm wondering if you've had a chance to look at SWIG - http://wwww.swig.org/ - the Simple Wrapper Interface Generator.

SWIG enables C and C++ coders to make their
functions available in a variety of scripting languages, including Perl, Python, TCL, etc. with minimal pain.

It would be interesting if AppleScript could be added to this list.

The flip side is that it would be even more interesting if there were a generic interface into applications that a number of scripting languages could hook into; this could be done by putting an shim between the (perl|python|etc) layers and the applescript calls.

Is any of this being considered, etc.?

[bashyal]

Are you suppose to be able to click on the big graphic somewhere at apple's OS X applescript page. Or will it be up someday ?
http://www.apple.com/applescript/MacOSX/OSXBeta.01.html

for those who are interested in other languages having access to the interapplication capabilities of AppleScript, i feel it's necessary to mention UserLand Frontier. as i understand it, Frontier was the first OSA scripting environment, predating AppleScript. UserLand is in the process of Carbonizing Frontier. this MacNN thread even got a mention today on scripting.com (the weblog of UserLand's founder, Dave Winer).

Frontier provides full access to Apple Events within a familiar structured syntax, and can also run AppleScript or any other OSA compliant scripts. this is despite the fact that the recent focus of Frontier development has emphasized its web application framework and cross-platform capabilities.

i used AppleScript and FaceSpan to develop complex publishing automation tools. i found that AppleScript had some serious problems as complexity grew. now that i've rewritten the entire suite in Frontier, i feel i can handle an order of magnitude greater complexity. the Frontier IDE has some limitations, but i love the built-in database, the fact that scripts are data objects, and the outliner that automatically indicates program structure. in particular, the database greatly simplifies the persistent storage problem (which also tends to bog down many other scripting languages).

for the cost-conscious, Frontier 5 is still free, but will never be Carbonized. on the other hand, Radio Userland is in beta, and seems to contain enough of Frontier that one might use it as a scripting platform.

[Sal]

Are you suppose to be able to click on the big graphic somewhere at apple's OS X applescript page. Or will it be up someday ?
http://www.apple.com/applescript/MacOSX/OSXBeta.01.html

]http://www.apple.com/applescript/MacOSX/OSXBeta.01.html[/QUOTE]

Dang. Apparently my cool image map idea doesn't work on some versions of Navigator. I reved the page but it may take a day or two to be posted. Until then just go to this link for the Mac OS update info:

www.apple.com/applescript/MacOSX/OSXBeta.02.html]http://www.apple.com/applescript/MacOSX/OSXBeta.02.html]www.apple.com/ applescript/MacOSX/OSXBeta.02.html

[This message has been edited by Sal (edited 09-23-2000).]

Completely off the topic but hey

Parev, Inch beses?

cool to see some more armenians around as always

my last name - Tashjian

Double post

[This message has been edited by corvette (edited 09-22-2000).]

[Ununnilium]

Sal-

Will folder actions be extended to operate more independently of the Finder (or Desktop)?

According to Technote 1142, "Using contextual menus, AppleScript scripts triggered by various Finder actions can be attached to any folder."

I've found that Folder Actions for adding or removing files to a folder will only happen in limited cases: if done directly by the Finder, or if done by a different application, the window for the folder needs to be open in the Finder. Otherwise, the script won't be executed.

Will the Folder Actions in Mac OS X be able to independently monitor the contents of a folder for addition or removal? It would be great if Folder Actions would respond to changes made by the shell or Perl scripts or remote users using the disk with FTP, NFS, AFS, etc.

Thanks.

-Colin

[Sal]

Will folder actions be extended to operate more independently of the Finder (or Desktop)?

According to Technote 1142, "Using contextual menus, AppleScript scripts triggered by various Finder actions can be attached to any folder."

I've found that Folder Actions for adding or removing files to a folder will only happen in limited cases: if done directly by the Finder, or if done by a different application, the window for the folder needs to be open in the Finder. Otherwise, the script won't be executed.

Will the Folder Actions in Mac OS X be able to independently monitor the contents of a folder for addition or removal? It would be great if Folder Actions would respond to changes made by the shell or Perl scripts or remote users using the disk with FTP, NFS, AFS, etc.

Folder Actions has an interesting history. It was one of those situations where the time and effort required to implement the ability to work on closed folders may have kept the feature from being included with the OS. We felt that Folder Actions was such a valuable and necessary tool that we decided to implement the feature reliant on the folder window being open for the added items event. It turns out that it's not too bad as popup windows or windows that are colapsed are considered to be open by the Finder.

Folder Actions are still in the developmental stages in Mac OS X. Naturally the goal is to deliver a mechanism that works as you indicated -- on closed or open folders. There'll be more to report on this issue later.

[Sal]

Have you looked at F-script? It's a scripting language tightly integrated with the Cocoa framework, and it has an insanely great feature: it can instantiate Cocoa objects on the fly. Will AppleScript eventually support this as well? I want to be able to write scripts that can dynamically create a whole graphical user interface, and it would be even cooler if this could be accomplished using InterfaceBuilder.

Think VisualBasic, only much, MUCH more powerful.

We're currently focusing on delivering the fundamental structures and a robust implementation. Your suggestionn is interesting to be sure. We're examining various options for growth and integration but I have nothing to discuss to announce at this time.

Thanks.

[Sal]

Do you know of any plans to allow AppleScript-based CGIs to interact with iTools, specifically HomePage? I tried creating a CGI script from the tutorial and placed it on my HomePage, but when it tries to execute I receive this error:

This server has encountered an internal error which prevents it from fulfilling your request. The most likely cause is a misconfiguration. Please ask the administrator to look for messages in the server's error log.

I would love to create simple CGIs and stick them on my HomePage. Is this even possible?

I don't believe that iTools and iDisk support user CGI's.

[Sal]

I haven't used AppleScript for ages, but now that MacOS X is coming, there are, as many people have noticed, some interesting possibilities.

I'm wondering if you've had a chance to look at SWIG - http://wwww.swig.org/ - the Simple Wrapper Interface Generator.

SWIG enables C and C++ coders to make their functions available in a variety of scripting languages, including Perl, Python, TCL, etc. with minimal pain.

It would be interesting if AppleScript could be added to this list.

The flip side is that it would be even more interesting if there were a generic interface into applications that a number of scripting languages could hook into; this could be done by putting an shim between the (perl|python|etc) layers and the applescript calls.

Is any of this being considered, etc.?

There are many possibilities for the integration and expansion of AppleScript with the new tools and abilities of Mac OS X. We've examined many closely and are activly exploring some areas. At this time, I have nothing to announce regarding this issue.

Thanks.

Will there be any changes to the syntax of AppleScript in Mac OS X vs Mac OS 9? What about the syntax for the System Applications (i.e.-Finder-Desktop app) or Standard Scripting Additions?

Basically what I would like to know is whether, due to changes in syntax, some scripts which run fine in Mac OS 8.6-9.x may be broken when they are ported to the carbon version of Applescript OS X.

If this is or may be a possibility then those commands whose syntax will/may change can be wrapped into sub-routines and/or put into libraries in order to make the transition of those scripts to OS X easier.

Some suggestions on what commands one might want to encapsulate would be very helpful. This would help save some of the grief in tracking down changed syntax in calls to System Applications such as the Finder (Desktop app in OS X I believe), Standard Additions osax, or the AppleScript language.

If you can�t say what syntax will or has changed is if possible if you can at least indicate what won�t change.

Thanks

[sam]

A few people have mentioned that Applescript is difficult to learn & use. I would agree, although I love it (and I am a c++ programmer, not a "normal" user).

One of the problems here is tools. The tools shipped by Apple only scratch the surface of what you can do with Applescript.

Unfortunately Applescript originated in Apple at a time when the company was trying hard to avoid competing with third party companies - it might even be fair to say that it was actively ham-stringing some of its own products in the interests of competition (anyone remember the powertalk mailer?).

There are good arguments for leaving gaps for 3rd parties, but the problem with this strategy is that it can create a chicken-and-egg situation. Without effective tools the uptake of technologies like Applescript is very slow, and commercial concerns are not encouraged to produce their own tools (or even add scripting support to their applications) because they don't see a big market for them.

That aside, the point of this mailing is not to berate Apple, but to evangelise a couple of really cool tools that are out there.

FaceSpan has already been mentioned. For those that don't know, it allows you to add a full mac user interface to your scripts - with windows, menus and all the normal trappings of an application. It's cool, check it out (http://www.facespan.com)

The tool that I would strongly recommend to anyone interested in writing Applescripts is Script Debugger, by Late Night Software (http://www.latenightsw.com/). It is a replacement for Script Editor, is much more powerful, and once you've used it you will never want to go back to anything else!

At the moment I don't think either of these tools have been carbonised, but I am sure they will be (especially if they are supported with a few more registrations, followed by a bit of customer feedback!).

Sam Deane
Elegant Chaos

[This message has been edited by sam (edited 09-23-2000).]

[This message has been edited by sam (edited 09-23-2000).]

[sam]

Originally posted by Sal:
The Script Editor is included in the Applications - Utilities folder. We've also included a new app called Script Runner in the GrabBag - AppleScript folder along with some example scripts.

Hey Sal, I already have a little known (and even less registered!) product called Script Runner. It is a CodeWarrior plugin which runs Applescripts at the link stage (it's on the CWPro 5 & 6 cds if anyone is interested).

Since Elegant Chaos is a bit of a David to Apple's Goliath, I guess it may end up being me who has to change names - but I though I'd at least let you know about it...

[Person Man]

Hi Sal.

I wonder if you can comment on the following (missing) aspects of OS X, and whether these features have a chance of showing up in the final release.

1. The ability to turn off anti-aliased text (doesn't look as good on an LCD display as on a CRT).
2. The ability to move the dock to the left or right-hand side of the screen as well as hide it when necessary. (Currently, auto show/hide doesn't cut it-- with the dock being the only way to switch between applications, I forget it's there when it's hidden, and it gets in the way when it's visible)
3. The ability to turn off the genie effect.

#2 is the most important to me... You need to be able to hide the dock as well as being able to reposition it to the sides of the screen... I could hide it when running classic apps/games, and show it on the right-hand side of the screen when doing "serious work"

Thanks,

Person Man

Okay Sal, here's a stumper problem I've been having...

Is it possible for a running script to tell whether it's running in "native" Mac OS 9 as opposed to the Classic environment? I haven't managed to come up with anything that doesn't break after a couple of opens--it switches to targeting "Desktop" and then breaks the next time it's run under "native" OS 9.

Since I distribute applets that need to use features of the Finder/Desktop that don't (yet) exist in OS X, it'd be nice to be able to return an appropriate error message or use an alternate functionality.

Hi,

In the classic Mac OS its possible to launch compiled Applescripts from a variety of utilities - OSA menu, QuicKeys, Finderpop or OneClick come to mind plus some applications have script menus. I have lots of scripts, I cannnot see me filling up the Dock with scripts and switching back to the Desktop/Finder does not seem a great way of running application specific scripts. Will OSX provide a scripts menu such as, for example, OSA menu?

Thanks.

AppleScript Q:

How do I find the 'where' of a mounted disk (the information one sees in the Get Info window under 'Where:")?

The class information window doesn't have it in the dictionary, but I'd assume that there would be a way to look up:

• what server a drive came from
• whether it is connected AppleTalk or TCP/IP
• if AppleTalk, what zone; if TCP/IP, what IP address

A followup email to [email protected] would be greatly appreciated!

[Sal]

Will there be any changes to the syntax of AppleScript in Mac OS X vs Mac OS 9? What about the syntax for the System Applications (i.e.-Finder-Desktop app) or Standard Scripting Additions?

Basically what I would like to know is whether, due to changes in syntax, some scripts which run fine in Mac OS 8.6-9.x may be broken when they are ported to the carbon version of Applescript OS X.

If this is or may be a possibility then those commands whose syntax will/may change can be wrapped into sub-routines and/or put into libraries in order to make the transition of those scripts to OS X easier.

Some suggestions on what commands one might want to encapsulate would be very helpful. This would help save some of the grief in tracking down changed syntax in calls to System Applications such as the Finder (Desktop app in OS X I believe), Standard Additions osax, or the AppleScript language.

If you can�t say what syntax will or has changed is if possible if you can at least indicate what won�t change.

Naturally, there will be some changes in syntax as you'll be working with an entirely new OS. There will be some new features which didn't exist before and perhaps some familiar ones will change or will go away. But overall, scripting is essentially the way it always has been.

For example, the Desktop application replaces the Mac OS 9 Finder application and even assumes much of its dictionary. There are some new terms like "home," which refers to your home directory, that weren't there before. The "path to' command now has optional parameter for determine whether you want to use the root, current user, network user, or remote user as the source of the path.

Scripts that were written for the Mac OS 9 Finder will work for the Mac OS X Desktop app if they address the same commands or objects, like the startup disk or making a folder. If you open a Mac OS 9 Finder script in the Script Editor, you will see that the word "Finder" has been replaced with "Desktop".

Scripting Control Panels will be somewhat different as they will no longer be individual applications but will be panels in the System Preferences app. This is not implemented in the Beta.

The AppleScript implementation in Mac OS X is still under development. When Mac OS X is released, we'll have a detailed document addressing the major changes between Mac OS 9 and Mac OS X.

[Sal]

Hey Sal, I already have a little known (and even less registered!) product called Script Runner. It is a CodeWarrior plugin which runs Applescripts at the link stage (it's on the CWPro 5 & 6 cds if anyone is interested).

Ooops. How did they miss that? They must have done a registery search and found nothing?

Since Elegant Chaos is a bit of a David to Apple's Goliath, I guess it may end up being me who has to change names - but I thought I'd at least let you know about it...

Thank you for offering, it sure would be easier than trying to change it on our end! LOL!Let me know the new information and I'll feature it on the AppleScript homepage.

[Sal]

In the classic Mac OS its possible to launch compiled Applescripts from a variety of utilities - OSA menu, QuicKeys, Finderpop or OneClick come to mind plus some applications have script menus. I have lots of scripts, I cannnot see me filling up the Dock with scripts and switching back to the Desktop/Finder does not seem a great way of running application specific scripts. Will OSX provide a scripts menu such as, for example, OSA menu?

Look in the GrabBag > AppleScript folder and you'll find a small application called Script Runner. It presents a floating palette from which you can launch your scripts. We included this in the Mac OS X Beta to provide you with a way to launch your scripts. The final release may well have some other method implemeted instead.

[Sal]

I wonder if you can comment on the following (missing) aspects of OS X, and whether these features have a chance of showing up in the final release.

1. The ability to turn off anti-aliased text (doesn't look as good on an LCD display as on a CRT).

2. The ability to move the dock to the left or right-hand side of the screen as well as hide it when necessary. (Currently, auto show/hide doesn't cut it-- with the dock being the only way to switch between applications, I forget it's there when it's hidden, and it gets in the way when it's visible)

3. The ability to turn off the genie effect.

#2 is the most important to me... You need to be able to hide the dock as well as being able to reposition it to the sides of the screen... I could hide it when running classic apps/games, and show it on the right-hand side of the screen when doing "serious work"

There have been numerous requests to have the Dock be able to shift to the left or right of the screen. The fact that monitors are normally wider than they are tall lends credence to the argument that there is more horizontal space to use than vertical space.

Honestly, I don't know what the final plans are for the Dock. I do suggest that you post your ideas and comments on the Apple Mac OS X response page. Your vote can make a difference. Do it soon though.