Dictionary possibilities [Re: Interesting... AppleScript X ??]
Dictionary possibilities [Re: Interesting... AppleScript X ??]
- Subject: Dictionary possibilities [Re: Interesting... AppleScript X ??]
- From: has <email@hidden>
- Date: Fri, 27 Sep 2002 12:02:12 +0100
Timothy Bates wrote:
>
> but AS then completely drops the
>
> ball by failing to tell you in the documentation [dictionaries] which
>
> commands work on what objects: the user is generally left to work this out
>
> for themselves (yuk).
>
>
What a lovely (latent?) idea: create a viewer for the dictionary which turns
>
this on its head. That is the one weakness of the cal-model: you see "make"
>
but you have no idea what can be made.
I am curious about this "Cal" you Earthlings seem to speak of. Whereabout
might I learn more about the history and influence of this strange and
magical creature?
(You're right about the weakness though: this is one of the [many] things
that perplexed me when I started learning AS via Finder scripting.)
>
If the dictionary automagically generated examples of how (and which) verbs
>
apply, that would be great.
Working on the assumption that AS objects do have conventional methods, but
just that they don't tell anybody about it, it wouldn't seem unreasonable
to demand that future dictionaries include a list of methods alongside the
existing parent/properties/elements information [1]. What viewers
subsequently do with that data is entirely up to them, but the more
information provided, the more options there are for doing interesting
stuff with it.
Other things that viewers should be able to do is resolve inheritance
relationships, so that a user looking at the 'file object' entry in the
Finder dictionary sees a list of all inherited properties [in this case
from 'item'] as well as those unique to the file object [which is currently
all you see].The viewer could also subtly distinguish between inherited and
unique properties, and provide a link back to the parent object so that
users may browse/explore these structures easily.
The upshot here would be that novice users won't have to learn about
inheritance before they are able to use a scriptable app/read its
dictionary. That sort of non-essential knowledge can be deferred till
later, reducing the amount of initial information overload and making it
easier to get a toehold in IAC. And once they are underway, the viewer will
also help in establishing their understanding of the interrelationships
between objects and how these may be exploited; for example, filtering a
folder's contents by document file, by file or by item, depending on how
specific they want to be.
-------
Further possibilites:
1. A really, really smart viewer might use a _spatial_ graphical display,
rather than a linear text -based display: the user could zoom around the
thing, Raskin-style [2], getting close up to examine the details of a
particular object, and zooming back to get an overall view of the
relationships between the many different objects (which, given that there
are two sorts of relationships to consider, inheritance and containment,
will be an interesting one to model clearly, but potentially valuable if
done well).
2. The dictionary viewer/source editor distinction might be lessened, or
even removed altogether, through integration. Once your dictionary
effectively becomes a supercharged DTD/schema, your editing tools can also
exploit the information encoded within. One possibility is that you can do
away with dumb text-based source code and its associated
parse->complain|parse->compile cycle, and have an intelligent object editor
able to pipe the appropriate item to you [object reference/control
block/variable/literal/etc] almost before you type it. Sort of the
difference between a text editor and a word processor; and would relegate
your pleasantly pretty-printing but otherwise completely dumb AS editor to
dinosaur status overnight.
(As a mental exercise, here's how this might work for an AS user. The user
might begin a line by typing "make". The editor would then pop up a list at
side of the screen, showing the names of all possible objects that can be
made in the current context. The user could click on any of those items to
insert it/find out more about it. Or the could just keep typing, and the
system would narrow that list down as the user types via a sort of dynamic
search/autocomplete, and warning them immediately if they go wrong. The
system would dynamically provide the user with as much support as they
could wish for without any need for additional interaction [e.g. the
frustrating "constantly jumping between keyboard and mouse" that WPs can
make an unfortunate habit of], while keeping both your Cal syntax and your
traditional "source code-centric" developmental approach.)
3. Or what the heck, why pretend to be text at all? Why not program in an
Illustrator-like tool: drawing objects and linking them together,
controlled either by keyboard or by mouse/tablet? Really, I think
programming could get _far_ more interesting once language syntax and
semantics expressed in open form, compilers are broken apart, and the whole
"punched tape and terminal was good enough for my granddaddy and my daddy
and is good enough for me" with faint smear of "modern" veneer [visual
GUI-building tools] shifts to the side to allow other approaches and
systems to take a fair crack at the bat.
-------
Food for thought... Cheers,
has
[1] An "automagic" system would probably have to hook right into the AS
guts, using [e.g.] introspection to get a list of methods supported by each
object, cross-reference those names against existing dictionary verbs, then
generate a new dictionary listing based on the results of all that. Urgh.
Horribly complicated.
[2] e.g. Jef Raskin describes a "ZoomWorld" interface in chapter 6 of 'The
Humane Interface'.
--
http://www.barple.pwp.blueyonder.co.uk -- The Little Page of AppleScripts
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.