How to Open an App or File at a Specific Position and Size

I want to open a file with its default app (for instance, open an RTF file with TextEdit) and have the window appear at a specific location and at a specific size (for instance, in the lower left corner of the screen, 270px high, at whatever width is default).

So far, all I've been able to do is open the file and then, as a separate step, move it to the location and set the size (or set the bounds to set size and position together). When I Google for info on doing this, or search in Stack Exchange / Ask Different, etc., the common wisdom seems to be to open the file first and then set the size and location and I have not found other answers. Unfortunately, that results in the image of the file flashing at some somewhat random location in the center area of the screen before it reappears in the corner where I want it. It's the annoying flash that I want to eliminate.

Is it possible to preset the location and size before opening the file? Can the parameters be attached to the open command somehow? Could the file be opened minimized and then unminimized directly to the desired location?

I am open to solutions in KBM, AppleScript, JavaScript, Bourne Shell, third-party apps, whatever.

Have you considered creating a different "Space" in MacOS, starting the app on the invisible "Space" then moving it to the user's active space, resulting in an "instant" appearance?

I don't know if that will work, but that's what I would investigate.

Thanks. That could be a great approach, if only Apple supported it. I have been using Spaces for years and I have never been able to figure out how to open an app in a Space that is not the active Space. Jumping between spaces would be even more annoying than having the window flash momentarily in the wrong position.

Okay, I didn't know Apple didn't have an API to allow KM to work with Spaces. Spaces are one feature I have never used, so it was just an idea for investigation. Let me pause to think if I can come up with other ideas.

Have you considered running this command on the macOS "open" binary:

strings <path> | grep '^--'

What this command can do in some situations is find the names of all undocumented parameters to a command. I recall a time when the macOS command "screencapture" had undocumented parameters. If I had known that, I could have used this commend to uncover that it had an undocumented "-R" parameter which can be used to specify the Rectangle that the app should use to perform a screen capture. The chance may be only 10% that this will find what you want, but the time it takes to check is under a minute.

The "open" command already uses "-R" for something else, however.

When Apple introduced Spaces, it had several useful APIs for working with them, including being able to get the Space number of an open window. But around OS 10.6 nearly all of them were deprecated and by 10.9 removed (I'm not sure of the exact version chronology). That broke a lot of apps that made working with Spaces easier.

There is only one public API left, NSWorkspaceActiveSpaceDidChangeNotification which only tells you after the fact that a change has occurred, but not from what to what.

KBM v11 now uses that API notification as a macro trigger.

I'm sure everything you are saying there is true, but it's always important to remember that you don't always need an API, because sometimes user keystrokes act as a satisfactory method to indirectly access the API. For my purposes, I really don't mind such indirect approaches, because my only customer is myself.

I've never dug into that level of things. I've only looked at how open is listed in the AppleScript Library for various apps. What is the path to it?

Probably in one of the locations set in your PATH variable which you can view using the "env" command but I would make an educated guess that the location for you is /usr/bin which means your path would be /usr/bin/open

I'm trying it for you myself right now. To my surprise, a window popped up saying it needed to download something from Xcode at Apple. I've never seen that happen before. I'll tell you what the result is. It's taking several minutes. I'm not worried - I think it's an Apple download.

RESULT: Here are all the strings it found in the open binary. I see no undocumented qualifiers. It was worth a shot. Searching for strings in a binary like this can sometimes give you insight into what the binary can do.

--args
Open the file %s
Open the URL %s
Which did you mean?
http://
.com
.org
.net
Perhaps you meant '%@'?
The file%s %@ do%s not exist.%@
file://
file:///
The URL%s %@ do%s not refer to a file.%@
cancel

I have a fresh idea. It is possible using AppleScript to tell the Dock app to do things. The dock app has a way to move apps between Spaces. I have a hunch that it should be possible to take advantage of that to switch an app between spaces. You can see some AppleScript code to manipulate the Dock on this page.

I rarely use AppleScript, and I've never used Spaces, and I've never even thought of using the Dock for any reason with KM. However I have a good feeling that this may contain a viable way to solve your problem. You should do some research in this direction, and probably someone on these forums can help.

I just found a tutorial on doing what I tried to describe in the OQ (original question) of this thread.

The idea in this tutorial is that, for AppleScript-able apps, you can make use of the difference between activate, launch, and run to get the app started, invisibly, and then tell it what size and position it should be while you bring it to the foreground.

The tutorial by @CJK is on Ask Different, answering a question about opening QuickTime this way.

CJK's script, in the above post, has several useful tricks in it and his explanation of how and why it works is very thorough. One trick in particular is worth pointing out. To find a property to use to tell what state QuickTime is in, he gets the properties immediately and again after five seconds and looks for differences. He uses that property in its earlier state to determine when the app has opened "enough" to then be able to set the size and position without the app's opening sequence automatically overwriting them.

I hope to explore this idea soon to eliminate the kludge I've been using instead (tolerating the app flicking around on the screen), but unfortunately it's not my most pressing problem at the moment, so I'll just drop this hint for now, so I (and others) can find it.

One thing I know I'm going to have to research, experiment with, and/or ask for help on is that in the above tutorial, he ensures that run starts the app in the state that he wants by closing it first. I can't do that in my case; there are other windows in the same app that I need to keep open.

1 Like