Resize Columns in the Finder's List View -- Macro

Hey Folks,

Trying to automate this is very problematic and depends upon a variety of factors including how many columns you have visible in Finder windows.

Nevertheless this works reliably for me in list-view on macOS 10.12.6 Sierra.


Window ⇢ Resize Name Column ⇢ Text Script.kmmacros (7.6 KB)

Hey Chris, this throws error:

System Events got an error: Can’t get static text 2 of scroll area 1 of splitter group 1 of splitter group 1 of window 1 of application process "Finder" whose subrole = "AXStandardWindow". Invalid index.

Num: -1719

In this window:

Running 10.14.3 NOT 10.12.6 as you tested for.

My skills are too poor to understand what this is trying to do to begin to fix it AND then translate it to work with column view which I use almost exclusively.

I get the first part checks for being in list view.

Then there some defining an element so some aspect of the element is set to a position of -10 and +5, what that does I do not know.

Then there is setting a variable in KM to X and Y (does it matter that the x is lowercase and the Y capitalized?)

Next comes an error report setup.

That's all I can make of it.


Thanks for taking the time. No-one owes anyone their time so it is always a gift. Thank you.

Hey Bern,

Evidently something is different with Mojave in general, OR your set-up differs from mine sufficiently to hinder System Events -- System Events is very finicky...

I figured out how to make resizing columns in column-view work on my system, but I'll be pleasantly surprised if it works on Mojave without some adjustments.

I'll post a vid showing how to find the widget to click for LIST view when I have a little more time.


Finder -- Resize Columns -- Right-Size All.kmmacros (7.6 KB)

1 Like

Well, as The Godfather of Soul said "Sometimes I feels so nice, good god I jump back, I wanna kiss myself", it works!

All it needed was for the Move Cursor action to be set for clickX + 15 clickY - 10 and it works in column view. Wow, thank you!

I'll report back if I run into anything and for now with just a few tests it seems to be ok.

Maybe link back to the " TUTORIAL VIDEO: Using UI Browser and Keyboard Maeastro" conversation where this query began and/or Finder: Resize Name-Column To-Fit.

Now to learn some AppleScripting so as to reveal and understand the inner working of this AS magic...

And here's an icon for my Finder Palette. Yes!

icon (50.6 KB)

Soooo cool! :partying_face: :partying_face: :partying_face:

That is AWESOME! I totally celebrate with you, and I know exactly how you feel. It's quite the rush, isn't it?

I hope this doesn't sound condescending, but I'm proud of you. So few people are willing to put in the effort to learn this kind of stuff. High five!

(By the way, your icon didn't come across).

Thanks, yes it IS a rush! Some inconsistencies have shown up and I'll have to play with it for awhile to see what's up.

Strange as the icon shows for me:

Also, I can't bow too deeply as I just tweaked a setting that Chris left available. That's some fancy footwork that Chris pulled off :man_dancing:

Yes, you can bow deeply. One of my tenants of programming is, why write it myself when I can "borrow" it from someone else? It doesn't matter how you did it. It matters that you did it.

And cool icon. Icons are something I'll steal if I can. I'm really good at modifying existing icons. I totally suck at creating them from scratch. :smile:

1 Like

Hey Guys,

That's because Bern is using Safari and Dan is using Chrome – right?

Web-Kit-Based Browsers are the only ones I know of that will display TIFFs. Bern's icon is a .tiff file.

I've changed this to a .png and included the .tiff as a zipped archive.

My macro in post #3 identifies the focused column and uses it to change the column-widths.

Without this you'll have problems depending upon how many columns deep you are into a directory structure.


Yes, the notion of stealing is over blown. Once we learn to play together nicely it will likely go away. I just needed to acknowledge that I'm riding on Chris' coattails.

I've made (and really enjoyed the process) a bunch of icons for my KM palettes and have had a similar conversation about my artistic abilities, good at modifying someone else work but not dealing with a blank canvas. It seems your artistic conversation mirrors my coding conversation in that you aren't giving yourself credit due. 99% of my creations are inspired by what I see on the web which I then run with. Do that enough and you will trust your own sense of art, own it, enjoy it, and run with it.

Here's to your Artist and my Engineer :clinking_glasses:

Would using .png be considered a best practice in this forum?

How does the macro select the focused column? Is it the one where an item is selected within? How does the number of columns play into it?

Oh, don't get me wrong. I'm seriously proud of the programming work I've done. Give me a minute to talk about it, and an hour later you'll still be waiting to get your first word in.

Yep, great questions. Use UI Browser or Script Debugger to see what kind of properties are available. One of them will probably have the answer. Looks like in UI Browser, the property "AXFocused" might be the property to look at.

I’d like to spend that hour.

What’s your take on UIB vs SD7 for generating AS as in your UIB tutorial and to use while learning AS?


It seems to me that UIB is more for accessing the UI elements themselves - like list boxes and stuff like that, whereas SD is more for accessing the data objects exposed by the program through the automation interface - like the collection of data elements that are used to populate the UI elements.

For example, you could ask a text editor what text is selected, via automation. The UI doesn't know what text is selected, even if it is displayed differently. (I may be wrong about this specific example, but I think it conveys the point. Or at least I hope it does.)

Also, the UI doesn't know that the thing it's displaying is actually part of document "xyz" (for example). That relationship is something you can only know for sure via Automation. I mean, you can guess that since this container holds that container, etc., but that's really only how it's displayed.

I'm sure @ccstone could explain it a lot better. And probably tell me how wrong I am also, and if I am wrong, then I definitely want him to set me straight, please. :smile:

Hey Bern,

Read the code in the first AppleScript in my macro and see if you can answer your own question.

Let me know if you still have questions.

You can go many columns deep left to right into a directory with column-view.

If you statically talk to column 1 and try to change the column-width but column 1 is hidden in the UI because of the depth your script will fail.

This is because the widget you need to click to reveal the proper contextual menu is hidden.

You can't always know what will work and what won't work either – you have to test.

With UI-Scripting if you can't accomplish it by hand you very often can't by scripting – it's like Keyboard Maestro in that respect.


PNGs tend to be better quality, but JPGs will also work.


I pretty much agree with what @DanThomas said, but I'd add this:

  • UIB and SD7 are complementary tools, but I would always start with SD7.
  • UIB makes it easy to identify UI elements, but does not know anything about application data objects.
  • SD7 is full-blown IDE (Integrated Development Environment), that lets you easily work with UI elements and app data objects, easily develop scripts, debug scripts, and easily explore both UI elements and app data objects.
  • But it is harder to identify UI elements in SD7 than in UIB.
  • In lieu of UIB, you can use a macro/script by @ccstone to identify all of the UI elements in the front most window. See Front Window Analysis Tool for System Events

Unable to check a checkbox in an Affinity Designer sheet (setting the document to have a transparent background). UIB could see it and check it but the AS code generated didn't work in KM macro. Downloaded SD7 to see if there was something I could glean but Affinity Designer doesn't show in the SD7 "Inspectors Tab" list. That SD7 doesn't "see" it mean it's not scriptable? The Affinity Designer forum chatter seems to be saying that scripting is coming but no one says flat out that it can't be scripted. Just looking for certainty one way or the other and thereby learn a bit more about AS availability.


Got suspicious when another AS (to autosize the columns in Finder Window) stopped working and rebooted iMac. Both it AND this Affinity AS started working BUT this AS only worked once then stopped working while the Finder column AS worked and continues working. Something wonky for sure. Anyone seeing anything similar?

Hey Bern,

Rule-of-the-thumb – never test UI-Scripting code in Keyboard Maestro. Always use a proper Script Editor.

Chances are pretty good that the code can be made to work with the proper tweaks.

Drop Affinity Designer (or any other app) directly onto either the Apple Script Editor or Script Debugger to see if it has an AppleScript dictionary.


Thanks Chris. Neither Editor opened with Affinity Designer. Thanks for a test for scriptability and guidance on testing.

Obvious question, why is KM not a reliable test platform for code? I’ll follow the rule without explanation, just curious.


7 posts were split to a new topic: Learning and Developing AppleScripts