Jasondm007

Thanks, @vitor!! I didn't realize that first screenshot was from the menu bar / status menu. That's pretty neat! Is it possible to view the remaining time from Alfred, too - or is it status bar only? Thanks. Cool project, too!

@vitor I was thinking about replacing my current pomodoro timer with another tool that was a little more Alfred-friendly, when I came across your workflow. This looks fantastic! Thanks for sharing. One quick question: Does your workflow tell you how much time is left on the timer? It doesn't look like it does, but I just wanted to make sure. From what I can tell from the app's GitHub page, it doesn't look like it's possible to either. Thanks for your help!

@dfay Thanks for giving it a try! I really appreciate it. I'm not sure what the deal is with Mojave's tags features. Even the old tags shortcut doesn't work without removing favorites or other odd workarounds. Let's keep our fingers crossed they address some of this in Catalina. ... I won't hold my breath.

Great idea, @vitor!! @Andrew - Any chance we can get this butler on steroids? 😜 I'd love to start using Alfred's buffer more. Thanks for your consideration!!

I would love to start using Alfred’s file buffer more often, especially with some of the nice additions made in Alfred 4. However, Alfred is in dire need of better Finder-Buffer integration. Either of the following would solve this: a File Action that adds files to the Buffer, or a Hotkey that can be used to add files directly from Finder to the Buffer (i.e., in Preferences → Features → File Search → Buffer). Under the current setup, the ability to use a hotkey to file action files from Finder is great (Preferences → Features → Actions → Selection Hotkey), but it doesn’t help with situations where you want to action the file more than once. Several people have created workflows that effectively mimic Allred’s keystrokes, but they’re all pretty fragile (example). In addition, I still haven’t found any that work with multiple files. This feels like something that ought to be addressed on a system-wide basis. Alfred’s a great butler, but I think he can carry even more things! 😉 Thanks for your consideration.

@dfay By chance, do you know how to target Finder's "All Tags.." view (accessible most easily through the sidebar, when enabled)? I tried to create a simple workflow that opened Finder to this view, and have not had any luck. It seems to behave quite differently from most. Thanks

+1👍

@dfay Unfortunately, my previous suggestion had the unintended side-effect of retaining the page info from Preview - which takes up a ton of space in the output (e.g., page 1 of 350, etc.). To fix this, I just added an IF/THEN statement to use the original code for Preview's windows, and the abbreviated version for other things. I don't have Skim on my machine, so I didn't add anything special for it. I suspect that you'll want to treat it like Preview (i.e., the original code)? Here's the relevant portion of the "active_window" script: set theWindows to {} set appsForWindows to {} repeat with theApp in appList tell application theApp set itsWindows to every window repeat with w in itsWindows if ((theApp as string) is equal to "Preview") then -- Added by Jason set theWindows to theWindows & {{theApp as string, name of document of w, id of w}} else -- Added by Jason set theWindows to theWindows & {{theApp as string, name of w, id of w}} -- Added by Jason end if -- Added by Jason end repeat end tell end repeat Yeah, you're definitely right about PDF Expert. I asked them about a different script-related question previously, and got brushed off. I don't think they'll ever add it. That issue seemed like it was a little more complicated than grabbing a document/window's name, however. I'm a little surprised that it doesn't work here. Isn't that limited amount required? In any case, maybe I'll have to switch to another PDF reader/annotater some day. For the most part, I use Preview. However, I've always liked the simplicity and aesthetic of PDF Expert better - so I use it when I'm reading for longer periods. Its layout for annotations and bookmarks is a lot cleaner than Preview's. I also have Adobe Acrobat Pro DC and Abby FineReader, but I'm not a big fan of these apps when just reading or taking notes. I assume from the script that you're a Skim user, right? Out of curiosity, what do you do about the embedded annotations issue (assuming it's still an issue)? I never tried Skim because I hated the idea of having to remember to export each PDF after adding something to it. It's GUI always struck me as a little dated, too (but functional, nonetheless). Unrelated, but were you thinking about displaying each supported app's icons in the workflow's output? I ask because I noticed the images in the workflow's folder (and think it's a good idea, too). However, they've never shown up on my computer - even before I started screwing around with it. My output just shows the generic orange four squared icon from Alfred for all windows/apps.

@dfay I was tinkering around with the Active Windows workflow, and I noticed that a small tweak to the "active_window.scpt" helped it start working with the OmniOutliner app. Namely, if you remove the "document" reference when you're grabbing the app/name/id, it seem to work. I've copied the relevant version of the script below, commented out the original line, and added a notation to the new line in screenshot below. set theWindows to {} set appsForWindows to {} repeat with theApp in appList tell application theApp set itsWindows to every window repeat with w in itsWindows #set theWindows to theWindows & {{theApp as string, name of document of w, id of w}} set theWindows to theWindows & {{theApp as string, name of w, id of w}} -- Added by Jason end repeat end tell end repeat I still haven't had any luck getting it to work with PDF Expert, but I'll keep toying with it. Do you ever use this app? Unfortunately, I suspect that it's not scriptable. All the best!

@Andrew I noticed this morning! Thanks a ton!! This is great.

I'd love to see each file's tags listed in the information provided by File Navigation's Preview Panel. Tags seem more important than most of the info that is currently listed (e.g., app the file opens in, date created, etc.). Why not list the file's tags there? At the moment, Alfred doesn't have an easy way for viewing or modifying tags, and this seems like a good first step that won't demand a complete overhaul of anything. Ideally, I'd love to see Alfred have its own file action for tags, too, which allowed users to view the file's current tags and modify them as needed (without requiring users to remember their list of tags, etc.). Relying on Finder's "get info" feature is a little clunky, as it requires leaving Alfred, etc. I have some workflows for adding or removing tags that I often use, but they're not very flexible (e.g., they don't tell me which tags are already on the file, they don't dynamically tell me which tags are in use on my system, etc.). Lastly, I'd love to see tags visually incorporated into Alfred's main search results (favorite suggestion here), but I guess that's for another day! Thanks for listening!

Please ignore this file filter bug report, as it appears to be working with contacts now. I have no idea why it wasn't working yesterday. I restarted my computer a few times before posting to this forum. The only difference between yesterday and today, that I can think of, is that I did a full shut down. My apologies for the false alarm (though the sidebar still stands). Thanks again for all of your help!

Sidebar: This is completely unrelated, so please feel free to ignore this or file it away in feature suggestions for Alfred 4. It just popped into my head when working on this particular file filter. Namely, I was wondering if was possible to relax Alfred 4's new preference searching abilities for workflows (e.g., so that it splits words)? For example, on my system the workflow for this particular file filter is named "Search - Contacts" (see additional screenshot below). When searching for it, Alfred finds the workflow perfectly when I use its exact name: "?Search - Contacts" (or some truncated version of this, as long as it starts out correctly - e.g., "?Search", "?Search - ", etc.). However, Alfred can't find the workflow when I search for the second word in its name: "?Contacts". It also won't find it when using a wildcard: "?*Contacts". My memory is pretty good, but this is rough (especially when the workflows' names revert to their originals after being updated by their creators, etc.). In addition, Alfred's Web Searches already appear to search in the more forgiving manner described above. In any event, I started using @Acidham's great workflow to get around this limitation, but I'd prefer to use Alfred's search to open these in preferences (and his workflow for other stuff, like running or revealing them in Finder, etc.). Thanks for your consideration!

It looks like there might be a bug impacting file filter searches for AddressBook files in Alfred 4. I’ve used this file filter since I started using Alfred, and just noticed that it no longer works in Alfred 4. In the screenshot below, you’ll find its settings: Side Note: I’ve always preferred using a file filter (keyword, more specifically) when searching for contacts because I don’t like seeing them in Alfred’s default or file search modes. To be clear, if I go back to Alfred 4’s settings - either its default or file search settings - and add “contacts”, they will show up in those searches. However, these files will not show up in the file filter (i.e., it appears to be a file filter and not a permissions problem). Thanks for your help!

@dfay I used the workflow quite a bit today with Preview, and it's great!! Thanks a ton. I'm not sure if I introduced this problem with the code above, but the workflow doesn't always activate the appropriate pdf window in Preview. Instead, it brings it to the front, while keeping the previous one active. Have you noticed this, too? Any ideas what to change in the code above? Thanks!

@Andrew By chance, did this make it into Alfred 4 (re: original query from file filter)? Thanks!!

@dfay This is amazing!! 🤯 Thank you so much! You were right about Skim. I had to exclude it from the environment variable because it was prompting my computer to select an app for opening Skim files. I also made one small change to the "launch.scpt" file. I noticed when switching to a PDF in Preview from another desktop/space that my computer was activating Preview, but not the correct window, so I added two small lines (marked below with "NEW"). They just activate the app and add a small delay prior to opening the window. Hopefully this won't break anything, but it seems to be working just fine now. Thanks again for all of your work on this workflow! I really can't thank you enough. set theApp to (system attribute "app") set windowID to (system attribute "windowID") as integer set theDocument to (system attribute "document") set appList to words of (system attribute "appList") as list if theApp is not in appList then display alert theApp & " not configured" else -- if theApp is "Preview" then tell application theApp activate -- NEW delay 0.50 -- NEW set itsWindows to every window repeat with w in itsWindows if windowID is id of w then set index of w to 0 activate end if end repeat end tell -- end if end if

Awesome! Thanks a ton, @Andrew!!

I’m not sure if this is an Alfred 4-related bug, or if it’s something that I’ve just now noticed. In any case, I was wondering whether Alfred's file browser's sorting should behave like Finder's, specifically when it comes to sorting by names (its default)? For files that begin with numbers, for example, Alfred doesn’t appear to treat them as numbers - at least numbers that may be more than one digit long. Consider the following example of a folder containing sequentially numbered PDFs. In the screenshot from Alfred’s browser, you’ll notice that a file beginning with the number 10 comes directly after a file beginning with the number 1. However, when you view the same folder in Finder - as show in the screenshot below - you’ll notice that it places the file that starts with the number 2 directly after the file beginning with number 1, when sorted by name. If this isn’t an Alfred 4 bug, is there any way to get Alfred’s file browser to behave in a similar fashion - and recognize that numbers may be more than one digit long? As always, thanks for your help!!

@dfay I can only imagine! Do the stock MacOS apps at least use them similarly? I'm going to guess that I know the answer to that one ... 😉 If it's any consolation, selfishly, I was only hoping to use it when opening Preview windows, like Finder. However it turns out, thanks for all of your efforts!

Thanks @dfay! That sounds amazing!! If there's anything I can do to help test etc., please let me know.

@dfay By chance, do you know if your workflow for searching open Finder tabs and windows is generalizable to other apps whose menus also list their open windows or tabs? The reason I ask is because I was hoping to apply your approach to the Preview app, too. When I’m writing/researching I often have several different PDFs open in Preview - and often across more than one space/desktop and monitor (similar to the way I leave several Finder tabs open to folders that I’m working on). As a result, it’s often difficult to find the one that I’m looking for. To date, I’ve tried several different app and window switching applications (e.g., Witch, Contexts, etc.). However, they all have certain problems or quirks in this work environment. Most often, they fail to register Preview and Finder windows, which is why I reached out about Finder in the first place. I’m sure there’s no perfect solution, but since your Finder tabs workflow doesn’t seem to have any of these problems, I was hoping to do the same thing in Preview (i.e., as a separate workflow) - which has a similar approach to Finder when it comes to listing windows in its own menu. However, after duplicating your Finder Tabs workflow and slightly amending its scripts for Preview, I haven’t had any luck getting it to work. Initially, when it didn’t work, I did a little digging and found blogs complaining about Preview’s lack of AppleScript support. However, these posts were all quite old. In fact, when testing, I noticed that some of the things that they complained about actually worked just fine now (e.g., like the ability to simply close a window, etc.). Before I spend a ton more time trying research why my changes to your workflow don’t work, I was just curious if you thought your approach to Finder would also work for Preview? Thanks!

@dfay After using your "Finder active tabs" script in the office for a few hours this morning, this workflow has made things so much easier for me. I just wanted to say thanks again! The script is amazing, and I really appreciate you taking the time out to create it.

@dfay You are a Finder wizard! You have saved me so much time staring at Finder windows!! I can't thank you enough. Honestly, this is great!!

@dfay Since you have a ton of great Finder workflows, I figured you'd be the right person to ask: Do you have a workflow - or know of another's workflow - that displays and searches for open Finder tabs? I often have several tabs open in the same Finder window, and am just looking for an easier way to get to the right one quickly (i.e., without having to squint to read the small print when they're smashed together). I was hoping it would operate like the many Chrome and Safari tab searching workflows that people have created. As a novice, this seems like it would be easier to accomplish in Finder than it is in Chrome or Safari - since, among other things, Finder's tabs are actually listed at the bottom of the Window menu - but what do I know! I haven't been able to find any posted to this forum or elsewhere, so perhaps it's a bit more complicated. Ha Thanks for any help you can lend!