|
On 15/06/2014 00:38, Christian Boyce
wrote:
There are three View buttons in
the dictionary window's toolbar:
[...]
Caveats: it's not very good (it only shows one-to-many
relationships, i.e. elements, not one-to-one, i.e.
properties that contain application objects/references), and
both it and the inheritance hierarchy views are rather buggy
so don't always show everything/anything.
This was--
embarrassingly--
news to me. I
tried it
immediately
and had a look
at the
Finder's
dictionary. I
opened the
dictionary and
clicked the
middle button
and was
immediately
confused.
Confusion
Number 1: At
the far left
there are TWO
items that say
"[c]
Application."
One has a
triangle
pointing to
the right and
the other
doesn't.
Clicking these
two "[c]
Application"
things shows
entirely
different
stuff. I would
have expected
only one "[c]
Application."
See above. I did say it wasn't very good. SE's containment and
inheritance views have no actual understanding of how real-world
dictionaries actually get structured; they just make naive/unfounded
assumptions that are frequently wrong.
Confusion
Number 2: When
I click the
"[c]
Application"
with the
triangle, I
see a whole
bunch of other
things. Some
of them have
triangles
indicating
that they
contain other
things. That
looks handy.
But, if I
click on
"Folder>"
it shows me
ANOTHER list
of things…
with another
"Folder>"…
and if I click
THAT… (repeat
forever).
That's normal. Folder objects can contain folder objects as well as
file objects, with [in theory] no end to how deep that nesting can
go. As you say, those 'folder' entries should have 'E' icons (since
they're elements), and should also be accompanied by 'P' (property)
entries for stuff like 'home' and 'desktop' as well. The most
confusing thing about it is that all this information is being shown
in a cheap, cramped column view control, rather than in a real
expandable graph view like the one Script Debugger provides.[1]
Ultimately, you'd be better using SD, which is not only vastly
better at displaying application dictionaries, but also allows you
to explore interactively the application's object model as it's
running. SD has so many features to assist both novices and experts,
it puts SE to total shame. (Honestly, I wish Apple'd just buy SD,
add an 'Easy' switch to hide its more esoteric controls from casual
users, and call the thing "Script Editor 3.0"; it already does half
their job as it is.)
Am I
misunderstanding
this? It looks
like a big
mess that
somehow got
through QA.
I don't think AppleScript stuff gets very much QA. Certainly, nobody
in Apple - AS team included - seems to use it seriously themselves,
otherwise they'd realize themselves how flawed, incomplete, and/or
broken a lot of it is. Personally I could spend a month filing
endless bug reports on every Cocoa-based AppleScript application and
API, but there's no way I'm going to do so as I already know most of
its flawed right down to the bones. TBH, the only way the
AppleScript stack would ever get straightened out is if the AS
engineers spent the next couple years actually eating their own
dogfood every day, as that's the only way to truly comprehend the
AppleScript world's myriad real-world complexities and problems, and
how to deal with them[2]. But alas, there's no Radar button for
saying that. :(
HTH
has
[1] FWIW, Python/Ruby appscript also included a nice built-in help()
command for exploring applications' dictionaries, including
displaying their inheritance and relationship graphs as text.
(Nasty, knotty code, mind, but it worked.) I was going to paste the
graphs here FYI, but the Finder's 'ascrgdte' (Get Dynamic
Terminology) event handler is broken in 10.9 so appscript couldn't
retrieve its dictionary. :(
[2] And also (especially) how *not* to deal with them.
|