deanishe

It only took a few minutes. There's no script per se. It's just Alfred's built-in File Filter function. I just went to ~/Library/Caches/Metadata/Safari/Bookmarks (where Safari exports its bookmarks, and history), dragged one of the .webbookmark files to the File Types field, dragged the directory itself to the Search Scope, and—here's the trick—added kMDItemURL to the Fields list in the Advanced tab. (I ran the mdls command on one of the bookmark files to find the metadata field I needed.)

Javascript the language isn't so terrible (although its community is pretty demented), but Apple's JXA API is in many ways worse than the AppleScript one. @jaladuvar If I were you, I'd strongly consider doing the absolute minimum in AppleScript, and passing the data to a Ruby/Python/anything-but-AppleScript program as soon as possible.

I'm not sure I follow you. If you've got the frontmost process, you can script that object. What I haven't been able to figure out is how to get an Application object from a Process one.

If you found my unpublished Safari Assistant workflow, that isn't the same thing. The workflow I just posted was made especially for you. The other one doesn't search URLs.

You mean the URL? You can't search the URL via Alfred's default results, but you can with a File Filter by also specifying the kMDItemURL metadata field. Here's a workflow.

You'll have to be more specific if you want concrete help (i.e. post your workflow). Here's how to set variables: Fundamentally, it's not super-easy in AppleScript because you have to emit JSON. Using JavaScript (or basically any other language) would make it easier.

Ignore any processes with 0 windows?

You have a non-printing character in there. It doesn't say "LA check", it says "\x16LA check". Why didn't you post the workflow straight away? You've been told at least 10 times that screenshots are no help and you need to post the broken workflow.

I've been playing with this and found some weirdness: AppleScript calls go to the newer instance of the app, but JXA calls go to the older one: #!/bin/bash open -a 'Safari' 'https://www.google.com' sleep 10 # give app and page time to load osascript -l JavaScript -e "Application('Safari').windows[0].currentTab.name()" # Google osascript -e 'tell application "Safari" to return the name of the current tab of the first window as text' # Google # Open a new instance open -n -a 'Safari' 'https://www.yahoo.com' sleep 10 # give app and page time to load osascript -l JavaScript -e "Application('Safari').windows[0].currentTab.name()" # Google osascript -e 'tell application "Safari" to return the name of the current tab of the first window as text' # Yahoo

Compare PIDs. The lowest PID is the "original" app instance, the highest is the one you just created: // Compare PIDs function sortByPid(proc1, proc2) { var pid1 = proc1.unixId() var pid2 = proc2.unixId() if (pid1 < pid2) return -1 if (pid2 < pid1) return 1 return 0 } // Return array of processes, sorted by PID function namedProcesses(name) { var results = [] var procs = Application('System Events').processes.whose({name: name}) for (i=0; i<procs.length;i++) { results.push(procs[i]) } results.sort(sortByPid) return results } function run() { var procs = namedProcesses('Safari') console.log('oldest proc (' + procs[0].unixId() + ')', procs[0]) console.log('newest proc (' + procs[procs.length-1].unixId() + ')', procs[procs.length-1]) }

Very nice, but what is that icon?

Perhaps start a new topic there? It seems 99% certain that Adobe has broken things, not Alfred.

This is trivial to do with a File Filter. You can also assign a much shorter keyword than open. Mine is f.

Yeah. As @Vero says, Alfred deletes the playlist, then adds a new one with the same name. This doubtless happens more quickly than iTunes Match can sync the changes, so it gets confused, and you end up with duplicates. The likely solution is for Alfred to be a bit smarter about playlist manipulation, and alter the existing playlist—if there is one—rather than simply deleting it and creating a new one with the same name. It's quite likely that there'll be similar issues syncing the contents of the playlist, though. Might be best for Alfred to create machine-specific playlists, e.g. Alfred (Earl) and Alfred (McLovin) for my machines.

I've also had the issue and I subscribe to iTunes Match. That also syncs your playlists between devices. It's quite possible that Alfred's deleting-and-recreating the playlist is conflicting with the sync.

Tried what? Vero's workflow? It doesn't work with BusyCal because it isn't BusyCal's data the workflow is searching. With Calendar.app, not BusyCal. Frankly, I think you can forget about connecting Alfred to BusyCal in any meaningful way. BusyCal offers only extremely rudimentary integration options. This is a problem with BusyCal, not Alfred. You can add things to BusyCal via its URL scheme, but there's no way to get any data out of BusyCal.

Hadn't noticed the PLUS had gone. I guess it is rather non-obvious now. Right-click on a blank spot on the "canvas" to add a new element. It will show a list of all the things you can add. You can also copy and paste existing elements. To connect elements, hover your mouse over one, then drag the "nub" to the element you want to connect it to. Alternatively, right-click on and element and choose from the Insert Before and Insert After menus.

That isn't how you search by file type in Finder. It's not a shell. Try kind:PDF instead.

It's not your end that's not working. It's the ropey WiFi network I'm currently on. Alfred itself gives up very quickly (looks to be about 10 seconds). If there's a normal link, I can grab the update with my browser, which has a much more relaxed timeout. I've tried tethering to my phone, but that's also too high latency for Alfred's tastes.

@Andrew, is there somewhere else I can download betas from other than Alfred's built-in updater? It just keeps timing out for me.

Can't update atm. I'm on a crappy WiFi and Alfred's updater times out too quickly

I've posted a corresponding bug report.

Alfred 3.4 (847). Alfred's clipboard history doesn't respect the org.nspasteboard.ConcealedType UTI. When the pasteboard has data set for the above UTI, clipboard history managers should not record the pasteboard data.

That's an Alfred bug, tbh. The workflow marks the copied password as concealed data, so Alfred should NOT record them. I've tested it with other clipboard history managers, and they respect the concealed marker.

I changed the behaviour of Fixum from only updating workflows affected by the Sierra bug to updating all workflows with a version of Alfred-Workflow older than its own. As I also released a new version of the library, it will probably have updated all your AW-based workflows.