deanishe

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.