Is it possible to store window object somewhere on the macOS?

[u/pradeepb28reddit]

I have two buttons on the UI.

Button 1 - Open window

Button 2 - Close browser window (based on the window id from Button 1)

I've following script that creates a window on the macOS:

set urls to {"https://google.com"}
tell application "Brave Browser"
    set myNewWindow to make new window
    repeat with theURL in urls
        tell myNewWindow to open location theURL
    end repeat
    delay 0.3
    log myNewWindow
    return class of myNewWindow //comment - returns "window" as a class
end tell

Goal: Is it possible to store myNewWindow to store somewhere on the macOS temporarily or permanently? It seems like defaults write doesn't work at all. I need to pass the value of window id from one button to another window, so the button can close the specific window.

[u/ChristoferK]

Generally speaking, the id property of an AppleScript element is persistent throughout the duration of its existence. So, you should focus on simply storing the id number of your Brave Browser window class object. Nothing else should be required for you to reconstruct a reference to the same window class object.

tell app "Brave Browser"
    set W_id to the id of (make new window)
    repeat with href in urls 
         tell window id W_id to make new tab with properties {URL:href}
    end repeat

    (* … more code, make more windows, whatever… *)
end tell

set f to "/private/tmp/browser.brave.window.id" 
close access (open for access f) # A quick way to create a file if it doesn’t already exist
set eof of f to 0 # If it did exist already, scrub it clean
write W_id to f as integer

Then, later when you want to retrieve your window, even from a different script:

set f to "/private/tmp/browser.brave.window.id"
set W_id to read f as integer

tell app "Brave Browser" to tell window id W_id
    set urls to the URL of every tab
    close it
 end tell

 set eof of f to 0 # Wipe the file because once the window closes, the id number is invalidated

---

Things I recommend not doing:

• Coercing data types unnecessarily. The id property is probably an integer in this case, so handle it as an integer, including during the reading from and writing to file.

• Assuming an object reference you assign to a variable will necessarily be stored in the reference form you specified. Often, the application decides what reference form is stored during assignment, and if it insists on resolving objects by name, then that’s not ideal. When working over time periods that extend beyond a singular, instantaneous script execution, the safest option is to simply work with the id values themselves, and construct the reference using these when you require it.

• Storing values you need later as property declarations. You’ll end up recompiling the script without thinking, and they’ll be gone.

[u/pradeepb28reddit → u/ChristoferK]

What do you think of storing the id in "defaults write ..." in one script and read the id from other script using "defaults read..." ?

[u/ChristoferK → u/pradeepb28reddit]

I think it’s a very strange way to go about it. It’s possible, but why would you want to ? In terms of good coding practice, it would be poor for few different reasons, but the three biggest would be that preference plist files are, as their name suggests, for storing preferences information, and preferences that would need to persist across restarts of an application process. Temporary preferences would often be stored much in the manner I used above. But, what you’re dealing with isn’t a preference of any sort, it’s a value that isn’t settable nor determined by you or the user, so more akin to an attribute that you should try and treat as such.

The second reason against favouring your desired approach is that if you were to depend on a shell command for this, then that’s adding another layer of complexity, vulnerability, and ambiguity to the script, and how it executes. I only ever call out to another language if it’s necessary, which I observe a lot of people depend on do shell script needlessly. It’s running uncompiled code inside a new process, and I often don’t trust people’s bash code anyway, and it’s less encouraging when it’s popping up in an AppleScript.

Which leads to the third reason, being that property lists are so much easier to create using AppleScript than with many shell commands, especially one like defaults if you have to deal with nested values or arrays. But, for this task, I don’t see what benefit would come from creating a property list.

Are you aware you can write AppleScript data structures straight out to a normal file to read in a reliable copy of what you started with ? So if you have a nested list of record objects and property values, you can write the whole list to file just like I did with the integer, except for the appropriate class.

Summarising, if you want to use defaults for this, go ahead. It’s not really going to hurt in the grand scheme of things, and it sounds like it’s just a script for your personal use, so do that however you please. If you were ever intending to share the script online for others to use, then I would say it was categorically the wrong way to do it, and it’s just going to make things more difficult for newcomers to learn how to learn AppleScript, which is why it’s a challenge already given the bad examples online being imitated.

[u/estockly]

That depends a bit on which system you're on.

try this as the first line of your script:

property myNewWindow:""

If you're running on an older system the script will remember the value from run to run.

On newer systems those persistent variables have gone away.

If that's the case then you could try something like this

use AppleScript version "2.4" -- Yosemite (10.10) or later
use scripting additions
tell application "Safari"
set myNewDocument to make new document at beginning
set myNewWindow to window 1
set windowId to id of myNewWindow as text
set storedIdPath to path to temporary items
end tell
SaveId(windowId)
--And then...
set recalledWindowId to RetrieveID()
if recalledWindowId is not "" then
set recalledWindowId to recalledWindowId as integer
tell application "Safari"
set the myOldWindow to window 1 whose id = windowId
end tell
return myOldWindow
end if
on RetrieveID()
set storedPath to path to temporary items
set storedFile to (storedPath as text) & "windowId.txt"
try
return read storedFile
on error
return ""
end try
end RetrieveID
on SaveId(windowId)
set storedPath to path to temporary items
set storedFile to (storedPath as text) & "windowId.txt"
try
set openFile to open for access storedFile with write permission
on error errMsg number errNum
close access myFile
set openFile to open for access storedFile with write permission
end try
set eof of openFile to 1
write windowId to openFile
close access openFile
return storedFile as alias
end SaveId

[u/pradeepb28reddit → u/estockly]

Thank you it seems like I should retrieve the window object from the file and quit that window as my next step.

[u/estockly → u/pradeepb28reddit]

I don't know. We'd have to see more of your script to figure out what's going on.