It’s like some of my other skills – use it or lose it.
Uh, that’s not the only difference. The other macro produces results that make sense to me. This, as @JMichaelTX said, takes me back to reading HEX dumps. No, that’s not right - reading assembly language. I’ll bet there’s some NOP and HCF codes in there somewhere!
I’m not offering an alternative – more like a litmus test (although there is potential for more than that).
99.9% of people won’t use the UI Browser utility, because it’s too expensive and/or too intimidating.
This macro gives me a diagnostic tool that anyone can use by pressing a keyboard shortcut.
By looking at the report I can immediately have a pretty good idea of whether or not GUI-Scripting is possible for the given window in the given app.
That’s because there’s a big difference between the -f and -t options in the shell’s
-t looks at Launch Services to figure out what editor is set for text files “in the Finder”.
It also takes input from STDIN, which is why I used it in this instance.
-f looks at the default editor in the shell’s setup files. By default that’s TextEdit.
You change it you need to add a line to your
~/.profile (or other shell configuration file).
open -f "/posix/path/to/the file.txt" # Input is a posix-path *not* STDIN.
Chris, I’m glad you can, but I’m not sure the rest of us could.
Any chance you could work your RegEx magic and produce a simple statement at the top as to whether or not the window is GUI-scritable?
If so, a report like the one UI Browser produces would be really helpful.
Here’s an example:
EN Mac 6.6 UI Elements.txt
Here’s a related script from MacScripters.net that I have used a few times.
The output is readable.
Updated to version 1.01.
Now requires Yosemite or greater.
It's faster and many of the chevron-codes are now replaced with human-readable names. (There are a lot of codes, so I certain to have missed some.)
I've added a property at the top of the script that allows switching the output between TextEdit and the default text editor set in the Finder's Get-Info dialog. (If you haven't changed it on your system then the default is TextEdit.)
Window Analysis Tool for System Events v1.01.kmmacros (7.3 KB)
Sow how long before it can generate AppleScript or JXA code to manipulate these things?
Just kidding. Well, kind of, anyway. Welcome to Peter’s world of “it’s never enough”.
«class splr» 1 of splitter group 1
is one of this in Path Finder
Chris, do you look for such feedback?
Changes to this version (1.50):
- No more chevron-codes to worry about.
- Hierarchical view.
In my opinion BBEdit (or its freeware sibling TextWrangler) is a better vehicle for viewing this output than TextEdit. One reason for this is the ability to turn on “Show Tab Stops”, which makes the view of the hierarchy clearer (some other programming editors also have this feature).
Window Analysis Tool for System Events v1.50.kmmacros (7.6 KB)
But that version is obsolete now.
I cannot stop me to show an example of use of this so nice tool (I have needed) for UI players:
Here's what it looks like with “Show Tab Stops” turned on instead of “Show Invisibles”.
You know, it's funny you posted this. I was wondering today if there's any sort of native way to display hierarchical data on the Mac. For example, here's the plist view from Xcode:
Another possibility would be to output XML. Most browsers support reading XML and collapsing nodes, etc. I could probably shake the dust off my XML skills if you needed help.
In any case, great work!
Scratch that. Atom has a decent collapsible view. Good enough.
Here's how it looks in Script Debugger.
tell application "System Events" tell application process "TextEdit" front window end tell end tell
I'm not going to fiddle with transforming it to XML at the moment, but I have an osax that might make that easy – so I'll think about it.
I'm not aware of any freeware hierarchical viewers for the Mac other than Xcode. I have a great utility called PlistEdit Pro that's much lighter weight than Xcode (but also more expensive).
Well, yeah - Xcode is free, isn’t it?
I’ll keep thinking on this. Seems to me there’s got to be a way to create a good view, in HTML. I’m not an HTML wiz by any means, but if I come up with something I’ll let you know.
You just focus on giving us good results. We’ll focus on everything else.
Are you talking about normal code-folding?
Or is there something better?
With Atom, you can collapse each node and level. I don’t think you can collapse all or expand all, but at least it helps hide the stuff you’re not interest in.
I pasted you output into it, and it works fine.
Atom > Edit > Folding > Fold All | Unfold All