Re: A bit more UI capabilities? (was: Re : on blocking target applications' GUIs)
Re: A bit more UI capabilities? (was: Re : on blocking target applications' GUIs)
- Subject: Re: A bit more UI capabilities? (was: Re : on blocking target applications' GUIs)
- From: Axel Luttgens <email@hidden>
- Date: Sun, 21 Dec 2008 05:05:46 +0100
Le 20 déc. 08 à 02:38, Chris Page a écrit :
On Dec 20, 2008, at 12:48 AM, Axel Luttgens wrote:
For example, should one need more than three choices (hence, more
than three buttons), it is required to nest multiple dialogs ... or
to devise some more or less clever (naughty?) tricks with the help
of "choose from list".
That is exactly what ‘choose from list’ is for: choosing from
several items. Can you provide an example where using a list would
be "naughty"?
Using it as a collection of pseudo-buttons, as described hereafter.
Do you mean you need nested controls? Like:
() Choice A
[] an option for A
[] another option for A
() Choice B
[] an option for B
[] another option for B
() is a radio button, [] is a checkbox.
Wow, that would be luxurious. :-)
But this sure would be overlapping with Studio...
No, I was considering the rather frequent case of needing to ask the
user which action to undertake during a script's execution.
One often end with something like this:
try
set {T, B} to {text returned, button returned} of (display
dialog "Please enter a string:" default answer "example" buttons
{"Cancel", "Uppercase", "Other..."})
if B is "Uppercase" then
set R to Uppercase(T)
else
set {T, B} to {text returned, button returned} of
(display dialog "Please enter a string:" default answer T buttons
{"Cancel", "Lowercase", "Capitalize"})
if B is "Lowercase" then
set R to Lowercase(T)
else
set R to Capitalize(T)
end if
end if
on error
set R to false
end try
This may impose up to two steps to the user; and anyway, this is not
really satisfactory, as the user hasn't the opportunity to review the
previous available choices anymore once he has clicked the "Other..."
button.
One may thus be tempted to make use of "choose from list":
try
set T to text returned of (display dialog "Please enter a
string to act upon:" default answer "example" buttons {"Cancel", "OK"})
set B to first item of (choose from list {"Uppercase",
"Lowercase", "Capitalize"} with prompt "What do you want to do with
\"" & T & "\"?")
if B is "Uppercase" then
set R to Uppercase(T)
else if B is "Lowercase" then
set R to Lowercase(T)
else
set R to Capitalize(T)
end if
on error
set R to false
end try
Again, this imposes two steps to the user; moreover, this may appear
slightly disturbing, as an interface intended for the selection of
items in a list is used as a dialog with 5 buttons, 3 of them being
fake ones.
On the other hand, shouldn't we be restricted to three buttons with
"display dialog" anymore, things would be much simpler, for both the
user and the scripter:
try
set {T, B} to {text returned, button returned} of (display
dialog "Please enter a string:" default answer "example" buttons
{"Cancel", "Uppercase", "Lowercase", "Capitalize"})
if B is "Uppercase" then
set R to Uppercase(T)
else if B is "Lowercase" then
set R to Lowercase(T)
else
set R to Capitalize(T)
end if
on error
set R to false
end try
This is not to say that "display dialog" should allow for an infinity
of buttons... but three buttons only often appear too limiting.
They are also a bit too limited in their scope. For example, native
progress bars and keyboard sensing would certainly delight more
than one scripter.
Perhaps would it be a good idea to integrate such capabilities into
AppleScript, while preserving its current KISS approach for such
matters (I mean, no need to incorporate a full-fledged say,
AppleScript-Studio into the language, just small incremental
changes such as allowing more than three buttons in a dialog).
This is why AppleScript Studio was created. This enables people to
use Interface Builder and Cocoa without us having to do a lot of
work to duplicate that functionality. It was created so that we
wouldn't have to turn ‘display dialog’ into something like Dialog
Director.
Obviously, finding the right place to draw the line between using a
plain AppleScript and using Studio is challenging.
Agreed. ;-)
Perhaps a reasoning like this one may help to draw that line: a
computer has a disk, a screen, a loudspeaker, a keyboard, and runs
programs over time. AppleScript (with its standard additions) can read
and write files, display dialogs on the screen, pronounce some text
and emit beeps; but it can't read the keyboard nor symbolize the flow
of the time.
Axel _______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden