Re: Giving Smile a test run
Re: Giving Smile a test run
- Subject: Re: Giving Smile a test run
- From: "Gary (Lists)" <email@hidden>
- Date: Thu, 18 Aug 2005 22:25:19 -0400
"Jeff Porten" wrote:
> So I'm messing around with Smile for what I think is the first time,
> and I'm not entirely grokking it. So I thought I'd toss around a few
> questions for other folks who went from Ye Olde Script Editor to this
> thingamajig.
'thingamajig' is about right...Swiss Army AppleScripting.
> 1) I'm gathering that the script windows are what I'm used to to SE.
> Workspaces are for code testing. When you're banging out code, where
> do you usually go?
Script windows...as you describe.
'Worksheet', I think you mean, is a text window. It just happens to be
Preference-able and can be opened at launch or not. It's just a store
place. For example, if you are always using a handler for testing, you can
put it there and set the window to open at launch. Then, select all, press
Enter, and your handler is in the global Smile scope now.
Text windows (plain white bg) are "AppleScript Terminal" windows...they can
run one or more lines of AS code. You can have many. They are not different
from the 'Worksheet'.
I usually use a plain text window for development. You can lock a 'tell'
target to a window, then you do not need to 'tell app "Blah"...' because
everything you type will be "told" to the app you target. You can log out
from the "tell lock" as needed.
> 2) If you use the custom Smile commands, what happens if you open a
> saved script in SE? Do you have to manually strip out the commands
> that won't work, or is there some voodoo that takes care of this?
Manually. The voodoo is to use AppleScript to find those handlers and
replace as needed -- or include a same-named handler of your own.
dd(s) is an example. It's easy to search for, and easy to replace with a
universal "display dialog" handler.
> 3) Does anyone have any suggestions for when to use one editor over
> the other (if you switch back and forth)?
I use SE only for looking at dictionaries and for testing to make sure
scripts are running as I expect, outside of the Smile.
> 4) For all those nifty UI commands, what exactly does one have to
> ship? Does a self-contained app store all the code it needs? And
> for someone who hasn't learned either yet, how does the learning
> curve for Smile compare to AppleScript Studio?
UI tools, like custom Dialogs (UI'ed apps), require Smile if you do nothing
special. One need only your tiny dialog if they have Smile installed.
If you wish all users to be able to use the tool, then you can build a _very
large_ (it contains all of Smile) stand-alone app that is exactly Smile.
Or, you can strip down the stand-alone to a very slim couple of dozen KB,
which is still Smile, but not with all the extras (the scripts menu, etc.)
[There are even examples for download from Satimage which show you how to
"strip down" your UI app.]
You can also turn on/off any individual menu or menu item in the menu bar.
The learning curve is debatable, or personal, I should say. I find it much
faster to build a basic tool in Smile than in the Studio. (Although I have
only built a couple of small test tools in Studio, for my own learning.) I
used to use Dialog Director and Smile is about the same in terms of the
process. You simply plop UI elements onto the your dialog from a palette
and you put scripts either in the element or in the element's parent.
Smile does not provide, natively, the same kind of general HIG support that
Studio does, but I simply made a HIG-compliant dialog template that I start
from, to try to comply with those guidelines.
Not every Aqua element is available, so the range is much more narrow than
Studio. You don't have access to cool 'preference flip down screens' (or
whatever), for example (which I do wish would be added, and that would, to
my mind, complete the set of UI widgets that I would use the most.)
> Note: not trying to start any kind of flames against either app; just
> trying to figure out the tools.
Absolutely. This list is Smile-friendly. So is the Smile-Users List (SUL),
of course.
Some unsolicited other opinion...
Smile is a complex beast. Because of that, there are some documentation
gaps which can be frustrating at times. The SUL then becomes very important.
This is entirely forgivable, and the documentation has grown to a very
respectable depth and is well-integrated into the working environment.
Smile has two flavors -- free and paid. The paid version is called
"SmileLab" and is intended for graphics-heavy applications. I don't even
really mean graphics like GIF's. I mean hard-core scientific mapping and
plotting, like "industrial" graphics. It's got quite an impressive PDF and
native drawing engine and could be used to map MRI results, for example.
Smile can also, if you did not read in the dictionary, cook a wonderful
omelette du fromage, without any human intervention!
> Best,
> Jeff
--
Gary
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden