Dictionary views keyboard access, bug?

Script Debugger
#1

I’ve assigned keys to each Dictionary view through System Preferences.

F2 for "Show Dictionary"
F3 for "Show Object Model"
F4 for “Show Explorer”

  1. when I move from one view to the other, it takes a significant amount of time (like 1sec) to have the Tool Bar View buttons updated and display the actual state the Dictionary is at that moment

  2. When I move to “Show Explorer”, all of the view options are greyed out and the shortcuts won’t work anymore, so I have to go to the Tool Bar and actually click on a button to change of view

  3. I mentioned the access keys issue a while ago, but when I set the keys through System Preferences, I get F2/F3/F4 properly displayed as F2/F3/F4 in SD (even in the Key Bindings section of the preferences), but when I set the same key bindings directly in SD, they are displayed as F2/F3/F4 in that window, but as fn F2/fn F3/fn F4 in the actual menus.

#2

I’m seeing a “Open Explorer Window (Cmd+D)” that is always greyed out in the File menu. It sometimes changes to “Open (Application) Dictionary (Cmd+D)” when I’m in the tell block of a given application but otherwise seems not available as a selected item in any other case. Even when I have an Explorer window open… Is this related to what I’m describing above?

#3

Click in a use script statement and look again.

No.

1 Like
#4

What I’m seeing now is “Open Script Library …” which is expected, but when I’m not on such a line I still get a greyed out “Open Explorer Window”, which is not very useful and is also confusing since it begs the question “what is this Explorer Window, that is not the Explorer view in the Dictionary window?”

Unless I’m misunderstanding something, It seems to me this “Open Explorer Window (Cmd+D)” should always be available and either:

  1. opens the Dictionary of the app mentioned in the tell bloc
  2. opens whatever is called by “use”
  3. activates an existing Dictionary window (ie acts as Window > Dictionary) if 1) and 2) are not possible
  4. displays a dialog that opens an application Dictionary (ie acts as File > Open Dictionary > Application… if 1), 2) 3) are not available

But maybe I am missing something obvious.

#5

You’re not misunderstanding – you’re simply expecting something other than what happens (and what’s documented to happen).

#6

So, what is that “Explorer Window” ?

#7

Click on a value in the Variables list in the Result & Variables pane, and choose Open Explorer Window. Or, um, look it up in Script Debugger Help?

#8

Interesting. So depending on the context that item opens vastly different things, right?

So, why keep it disabled when there is no context (or rather, why not create a “general” context, when there is no specific context)?

#9

You run the risk of overloading. (You could argue that’s already the case.)

I’m not sure why you’re so opposed to the idea of a command being disabled in some contexts. Commands as basic as Cut/Copy/Paste have been like that forever.

#10

I’m actually fine with the current behavior. Opening different things depending on the action target is actually smart, and because it is contextual it is not really “overloading” (at least not with the negative connotation).

I just found the label confusing since the only Explorer window I knew was the one I was struggling with (see the beginning of the thread).