Feature request for SD7

Script Debugger Beta Testing
#1

Is it possible to add the position of the window when saving its default size and state?
In addition to this, when opening a script from Xcode, could the window honor these parameters?

#2

I’ll look into this, but the staggering of new windows would possibly be effected.

I suspect that scripts created by Xcode don’t retain the resource fork that stores this information. It may be outside Script Debugger’s control.

#3

It’s not a problem for me.
All my script windows have the same bounds and I use a shortcut to navigate from one to another.
But I know that my way of doing things is a bit special.

I thought the default size was stored in SD preferences file…

Don’t get bored with it: I now see how my request is specific.
I can continue with my few scripts…

#4

Hey Mark,

I’m with @ionah.

I don’t care about staggering. I always want new windows the same size and screen position.

I was able to do this with a template in Script Debugger 5.

-Chris

#5

For this specific case, there is an Expert Preference that accomplishes this: PrefIgnoreTemplateWindowState.

1 Like
#6

Is it better to use this thread as a general feature request thread, or should I create a different one?

#7

Just in case:

  1. when “code folding” comments, keep the 1st line visible
  2. provide a “memo” pane that can be used to write down ideas while developing the script in the main window
  3. I’d like easy access to the coding window without any of the extra panes and chrome (right now it’s 2 shortcuts: one for the Result area, one for the Toolbar), so that I can focus on the code on a 13" screen and when I run, or debug or whatever then everything comes back in place automatically (already the case for the Result area, not for the tool bar, so an extra shortcut). Maybe an option à la “distraction free” mode that is triggered as soon as I start typing in the Edit window
  4. Execute to Here should have a default shortcut
#8

This is the kind of thing you can do for yourself using scripting:

tell application "Script Debugger"
	tell first window
		set status bar visible to false
	end tell
	tell first document
		set tab display mode to none
		set navigation bar visible to false
		set toolbar visible to false
		set result bar visible to true
	end tell
end tell

Produces a window looking like this:

37 PM
Screen Shot 2017-12-28 at 5.29.37 PM.png1876Ă—1158 268 KB

Save this as a script in your SD Scripts folder, assign a command key and you are set. You can extend this script to operate as a toggle if you like so that you single command key takes you into and out of this mode.

1 Like
#9

I cannot assign keys to every command SD offers. If you want a key for this, we provide a means of assigning one.

#10

I’ll file feature requests for these.

1 Like
#11

I know, but not having a shortcut for it makes it look like something of less use, when it’s really a very powerful shortcut for the beginner when you debug something. Instead of having to step through all the things that work, just use that first and step through the problematic parts.

I read the Menu documentation today and I understood that it was setting a temporary “breakpoint”, but in all honesty, I had no idea what was a breakpoint and how I could use such things before that. But “Execute to Here” is pretty obvious for the beginner.

So I guess it is more a discoverability issue. If you assign a shortcut to it, it will be easier for beginners to use because the label describes clearly what it does, and when they grow up, then can check what those “breakpoints” are and make use of them, knowing that “Execute to Here” was one of their favorite feature…

I’m trying to convince you, but I understand we come from 2 very different perspectives, but with the Lite version in mind, that “Execute to Here” could definitely be something you advertise to new AS users. It saved me a good hour yesterday (and countless hours from now that I have set Shift+Command+H(ere) to it (I think that one conflicted with something I forgot, but I had less use for that function anyway).

#12

Thank you for the idea! I’ll see where I can go from there! :+1:

#13

1 more:

  • a PDF manual (Apple’s Help viewer is an awful waste os screen space for laptops). BBEdit’s manual is what taught me regular expressions 20 years ago. Script Debugger deserves something like this.
1 Like
#14

1 more: direct access to the ASObjC reference, it doesn’t matter if Xcode is a requirement.

#15

ASObjC references are ephemeral. They only live for the lifetime of a running process. They cannot be stored or transferred to other applications.

Whatever code you are using to obtain an ASObjC object reference needs to be ported to Objective-C in order for it to be used in Xcode, which is outside Script Debugger’s scope.

#16

Apologies, I fumbled again. I meant the Foundation reference. The docset that we download from Xcode and access there or in Dash.

#17

1 more: a function that highlights code that does not need to be in a given tell block.

#18

Could you expand on that? I presume you’re aware of option-clicking for Dash users?

#19

Yes, I am aware of that. But I like to reduce the number of third parties to the minimum, plus Dash is fine for docsets that don’t exist and are provided by the creator or users, but Apple gives us the documentation so I was thinking of something like the system-wide “Loop Up” function that gives you access to the dictionary definition of a selected word…

Which just reminds me that 10 years ago I wrote something on my blog about the Dictionary tool kit (or whatever it was called) so maybe it is just about hand converting the reference format to something that Dictionary understands…

#20

May I ask why you don’t like third party tools?

It seems to me that, for the most part, they make life much easier. We can choose to either take advantage of the work someone else has already done, and refined, or try to create each tool ourself.

Here are just a few I use very often:

  • Dash
  • FastScripts
  • Path Finder
  • Default Folder X
  • Evernote (way, way better than Apple’s Notes)
  • Keyboard Maestro (rather than trying to cobble together Automator workflows)
  • LaunchBar (much better than Spotlight)
  • DropBox (much, much better than iCloud)
  • BBEdit or Tex-Edit Plus (much, much better than TextEdit)
  • 1Password (much, much better than Apple’s keychain)
  • SnagIT (much, much better than Apple’s native screen capture)
  • Kindle (much better than Apple’s iBooks)
  • UI Browser (much, much better than Apple Xcode UIElementInspector)
  • . . . and many more

and then, of course, there’s the biggie: Script Debugger (much, much better than Apple’s Script Editor).

IMO, Apple rarely provides the best tools/apps. I almost always prefer third party tools/apps.

In the case of direct, Apple provided documentation, my experience is that it is almost always lacking, and is hard to use. Rarely is there a search tool to find exactly what you need.

This is what Dash excels at. I use it often for a wide variety of developer software, and find it excellent. I see no reason to not use it.