Jump to content

luckman212

Member
  • Content Count

    81
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks @vitor Will do. I'll post to AskDifferent and link back here with any news. I agree that 10.15 is one of the worst (buggiest) releases ever. It truly is Apple's "Vista"...
  2. Catalina 10.15.1 Alfred 4.0.6 b1124 Something weird is going on with Icons for a few of the built-in System Preference prefPanes. For example, "Bluetooth" or "Internet Accounts". When I search Spotlight for these, the proper icon is displayed. But, in Alfred, only a generic icon is shown: vs and vs I notice even in Finder, the generic icons are shown: Only Spotlight and the System Preferences.app itself seem capable of showing the right icon. I opened the Contents folder of the prefPane bundle to investigate. It seems like Info.plist contained within specifies icons via keys such as "NSPrefPaneIconFile" and "CFBundleIconFile" but even in that case, the file referenced doesn't seem to exist on the filesystem anywhere that I can find. E.g. for Bluetooth, NSPrefPaneIconFile = "BluetoothAqua.png" —but that file doesn't exist. Similarly, Internet Accounts specifies "InternetAccountsIcons.icns" and "InternetAccountsIcon40.png" as icons, but these are nowhere to be found: What's going on here? I know this isn't really a bug in Alfred but it started with 10.15 and I wonder if anyone knows about these generic icons or where the resources are coming from...
  3. So, I noticed this was only happening on 1 of my Macs, not the other. I couldn't figure it out so I threw the sledgehammer at it: blew out the Spotlight index and rebuilt it. I also trashed the contents of ~/Library/Application Support/AddressBook/ and let that rebuild. After all that, Contact metadata are working normally again. Did not have to reboot (or even log out for that matter). Sorry for the false alarm on Alfred! 🙃
  4. Sure I can try a restart, but since a quit / relaunch of Alfred "solves" the issue (at least until the Contact metadata is updated again) it seems like (bug or not) something the Alfred could work around triggering whatever function is called during its startup.
  5. macOS Catalina 10.15.1 (19B88) Alfred 4.0.6 b1124 I just noticed that Alfred doesn't seem to ever update metadata (phone numbers, labels, etc) as I am updating them in Contacts.app. The only way I can get Alfred to refresh is to completely quit & relaunch it. I tried both with and without the "Use Spotlight metadata for searching contacts" option — same results. I don't remember this being a problem before, but maybe I just never paid attention to it.
  6. Wow, I didn't even know Alfred was listed on the App Store. Why is this version even still published there? Seems like a recipe for disaster.
  7. Alfred 4.0.6 b1124 macOS 10.15.1 This one happens on both my Macs (a Mini 2018 and a MacBook Air 2015) Could be a Catalina bug (highly likely) but when I open Workflows and double click on List Filter objects, the icons all show up blank, like this: Once I click on them, the icon appears. I have to do this for each item... or, if I cancel the object editor, and then re-open it, the icons all magically appear the 2nd time. After that, they are somehow cached, and will remain visible until the workflow editor is closed and re-opened, at which point they are blank again.
  8. The page linked from this SuperUser post is gone now, but according to that (and my own tests) it doesn't accept kMDItemPath. Nice! that will speed things up a bit for sure. How did you know that by the way? It doesn't seem to be documented anywhere.
  9. Man I really went down a rabbit hole on this one. But, thanks for the guidance @deanishe ! I finally got this working the way I want with a Script Filter (as you suggested) and some help from jq. There were some rough spots, because mdfind -onlyin does not accept multiple folders, nor a complex query using kMDItemPath. So I had to string together 2 commands into a variable. It was also "fun" wrestling with jq's syntax to parse the tab separated input, filter out nulls etc. This is most certainly better done in Python but I wasn't sure how to get the Spotlight results and was in a bit of a hurry. So yeah I'm sure there are better ways to do this... In case anyone is curious, here's how I did it: /bin/bash tab=$'\t' query='kMDItemContentTypeTree == "public.image"d && kMDItemContentModificationDate >= $time.today(-3d)' results=$({ mdfind -onlyin ~/Desktop $query; mdfind -onlyin ~/Downloads $query; }) if [ -z "$results" ]; then cat <<-EOJ { "items": [{ "title": "No recent images found", "valid": false, "subtitle": "no recent images found in Desktop or Downloads", "icon": { "path": "error.png" } }]} EOJ exit fi tsv=$(while IFS= read -r FILE; do fname="${FILE##*/}" fullpath="$FILE" dirname="$(dirname "$FILE")" fdate="$(date -r "$FILE" +'%a %-m-%-d-%Y %-l:%M%p')" echo "$fname${tab}$fullpath${tab}$dirname${tab}$fdate" done <<<"$results") /usr/local/bin/jq --slurp --raw-input '{ items: [ split("\n")[] | split("\t") | select(.[0] != null) | { title: .[0], arg: .[1], subtitle: .[2], mods: { shift: { valid: true, arg: .[1], subtitle: .[3] } }, text: { copy: .[1], largetype: .[1] }, icon: { type: "fileicon", path: .[1] } }]}' <<<"$tsv"
  10. Thanks @vitor ... Without activate in there, the choose file dialog opens in without focusing itself, so an extra click is required to bring it to the front before it will accept input (at least on my system). I also have a File Action trigger in my workflow, but that forces me to remember not to press [ENTER] when selecting the file and remember to use [CTRL] instead to trigger the File Actions. It's definitely faster when I can remember these sequences -- but...I often don't 😩 ...exactly why I try to avoid using it ! Anyway, for now it seems to be an ok tool for the job.
  11. I've got a workflow where at some point I want the user to select an image file from the disk. Right now, I'm using Run NSAppleScript (cached) for this. on alfred_script(q) activate set p to "Select an image to process:" set theImage to choose file with prompt p of type {"public.image"} return (POSIX path of theImage) as text end alfred_script Is this "right" ? Is there a faster, better or more efficient way? I ask because it feels "slow" when this step is triggered—much slower than native Alfred objects and File Navigation windows, not to mention that AppleScript seems to be going the way of the dodo. So if there's a way to avoid it or speed it up I'd love to know.
  12. I've got a workflow where at some point I want to present a File List showing 10 most recently created images from the last 3 days, from my Desktop and Downloads folders combined. The File Filter object is set like this: This only works if I pass something in via {query}. If {query} is blank, nothing is shown until I either type a * or a [space] or something. So my kludgy workaround is to set {query} to "*" right before before this step. It seems to work fine but feels hacky and wrong. Is there a better way to do this?
  13. @deanishe I finally got around to updating this workflow so it queries the sqlite3 db directly. It's a big improvement! Thanks for your help on this. I posted the workflow below ... would love any feedback on things I've done wrong or inefficiently... Type (github)
  14. @Andrew Thank you heartily for trying to work around this (silly) bug! After updating to 1124, I tested again and found a few rough spots where the clicks weren't registering, even with the workaround. It was basically the bottom 2 pixels of the color boxes (clicking on the 3rd px up from the bottom always worked). I had a nice screencapture video recorded and annotated with details—but then of course my capture program (Capto) crashed and I lost it all. And lo and behold, now I can't reproduce the problem. So it's all for the best. Thank you again! 😃
  15. Good idea @vitor — here is the text for copy & pasting: Menu item click area is not aligned correctly / does not respond to clicks properly Since updating to 10.15.1 (19B88) popup menu items in Alfred 4.0 and possibly other applications are not responding to clicks correctly. It seems like the UI element / bounding box that receives the click event is not aligned properly, so that clicks in the lower 50% of the UI element do not trigger the item - only clicks on the UPPER portion of the menu item are working. I posted a bit of detail + some screenshots on the Alfred forum: https://www.alfredforum.com/topic/13957-weird-click-behavior-in-workflow-editor-406-b1123/
×
×
  • Create New...