Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Andrew

  1. @onewheelskyward are you on the general release of 3.8 (build 959)? If not, update to this and things should work. If still not working, and if Finder and Terminal are selected in the Automation settings, then try restarting your Mac. In one of the 3.8 pre-releases, I had updated to Xcode 10 without adding the required NSAppleEventsUsageDescription for automation, so if you updated through that pre-release, it may have confused your Mac. Cheers, Andrew
  2. @deanishe I think my original reasoning is following the behaviour of Finder, but I can absolutely appreciate that Alfred has grown way beyond the original vision. And now workflows are a significant part of Alfred, the paradigm has shifted and modifier alternatives are normal. I had already thought about when Alfred is configured for Spotlight provide contact data, and I'm going to leave that to be treated as a file for now, otherwise it would need a "fudge" outside of Alfred's framework (to treat it differently to the Contacts system workflow where I can just wire in an alternative action). This view may change though.
  3. @deanishe It's a fair point - I'll add a note
  4. This is the default configured shortcut for the default results too (in Alfred's Advanced preferences) - Reveal in Finder.
  5. I've just pre-released 3.8 b958. If you're on the pre-release channel, update now!
  6. cmd+o is a standard shortcut throughout macOS, for example, cmd+o on a file in Finder will open it. Alfred adopts cmd+o to "Open" any file which may otherwise have an action. These actions include: - Showing contacts in Alfred, cmd+o will open the contact in macOS. - If the File Search > Navigation shortcut has been set so that return navigates into a folder, cmd+o will open that folder in Finder. etc. Cheers, Andrew
  7. @Rebecca if you could update to the latest 3.8 pre-release and let me know how you get on. Note: macOS will request access when Alfred needs access to these things. Alfred should be in the "Accessibility" section for Snippet Expansion. Cheers, Andrew
  8. @TheJesusFish @Rebecca If you could update to the latest Alfred 3.8 b958 pre-release from Alfred's update preferences and let me know how you get on. In the latest version of Google Chrome, when Alfred used the Apple Accessibility API to get information about the currently active text field, Chrome was returning different / random process identifiers for each keystroke. I've made a tweak which should work around this apparent Chrome bug. Cheers, Andrew
  9. @gta91 which build of Alfred 3.8 are you using? I did a tweak in b957 with relation to automation and Apple Events which should fix these types of issues. Cheers, Andrew
  10. Hi All, Just to let you know, I've just pre-released 3.8 which has been configured with a hardened runtime, which is a prerequisite for Apple's Notarisation process. I'd appreciate it if people who are updating to Alfred's pre-releases (from Alfred Preferences' Update tab) could let me know in this forum thread if they run into any issues with this update, for example, workflow scripts which worked in the previous pre-release not being able to run. I'm hoping to have the notarised version of Alfred 3.8 generally released within a week or so. Big thanks! Andrew
  11. I just thought... it's worth adding that you do actually see the appended newline from osascript -e 'return "~/Downloads"' in Terminal. When using bash and echo -n, the next command is immediately after your output. Cheers, Andrew
  12. @CJK Alfred doesn't process the output of a Run Script object in any way, and osascript non-optionally appends a newline to any output (which could be seen as an osascript bug, but I suspect this behaviour will never change). You have a couple of options: 1. If you switched your script to bash, then use echo -n for output, you'll get the output as expected. 2. Add a Transform utility object after your Run Script set to trim the output. This will remove the newline from your osascript. This has come up before, and my opinion remains that Alfred shouldn't automatically process the output of ant Run Script objects (e.g. to trim), as this would lead to more unexpected behaviour than not. Cheers, Andrew [moving to workflow help].
  13. @nindustries This should work fine - could you open Console.app and see if there is anything interesting logged out when this happens?
  14. @bmazin If you drag a file into Alfred's default scope, it does add the containing folder - This is to just make adding folders to the scope easier. Obviously, once ~ is in Alfred's scope, it's going to search everything within ~. When manually adding all the folders, did you try adding in all the finite ones (dot prefixed)? Also, I see you have some Box sync items there, I'm wondering if these are having an affect. @bmazin - Could you pop an email to our info@ address, I'm going to give you a build which will log the actual folders Alfred is including in the scope when folders in home is selected on your Mac. This should let us know where the discrepancy is. Cheers, Andrew
  15. When you tick for Alfred to include folders in home, Alfred enumerates the folders (NSURLIsDirectoryKey) in ~/ with the filter "NSDirectoryEnumerationSkipsHiddenFiles", and also excludes the suffix "/Library". The returned list is added to the list of manually added items in the search scope, and should be no different to manually adding these folders yourself. What we need to work out is why, in the case of your two Macs, there are additional folders being added which are subsequently resolving through to where your Mail attachments are being stored (~/Library/Mail/). I have a few theories, perhaps NSDirectoryEnumerationSkipsHiddenFiles is failing and Alfred is also adding a hidden folder which is somehow linked through to the mail folder, but it's extremely difficult for me to investigate this without access to your Mac. If you open Finder to your home folder, then use cmd+shift+. this will show all hidden files and folders. Perhaps start adding in the hidden folders to Alfred's default search scope (with home folders unchecked) until this problem is exhibited, this will give us a clue where to start looking for the culprit. Cheers, Andrew
  16. @illidian I've added the workaround in the 3.7.2 pre-release which you can update to from Alfred's Update tab Cheers, Andrew
  17. Quick additional note: If you update to the 3.7.2 pre-release, I've added a workaround to bring back the correct font rendering!
  18. @illidian There have been no changes to Alfred's font rendering or themes (including font weight) in 3.7.1. I've taken a look at this and it seems that this is a Mojave specific issue based on whether the main window has a transparent background or not. Alfred sets the window background to a special Apple "clear colour" so that the rendering can be done completely by itself. If I set the background to be black with an alpha value of 0.0001 (so basically invisible but not clear), the font rendering is essentially fixed. This feels like a hack, and I've yet to be able to find any answers on Google or Apple's forum for this. I'll raise a DTS and see if there are any suggestions to force the font rendering to be as expected over a "clear" background. Cheers, Andrew
  19. So it looks like this is a bug in Mojave, specifically relating to simulating hotkeys with the modified arrow keys. If you change the system shortcuts to something else, then this will work as expected. I'll fix the visual bug of the key not updating in a future release
  20. It looks like your combos don't actually have a ^ on them (it should show in grey under this). This has actually made me spot a little visualisation bug which is preventing the icon updating. To set a combo which is already reserved in macOS, you should be able to press the main part of the combo (i.e. left arrow), then right click within the key combo field and select ^ to apply that. Currently, the right click selections don't seem to update the combo's icon. Having said that, it does look like macOS isn't recognising these dispatched key combos as expected. This doesn't have anything to do with Notarisation - I'll take a look to see if there is anything I can do to work around this issue in Mojave! Cheers, Andrew
  21. Thanks to @szymon_k's information via email, it highlighted something I'd missed from the metadata output posted on the previous page. The kMDItemContentType for applications missing their icons was "com.apple.application-file" and not the correct "com.apple.application-bundle". The UTI defines that "com.apple.application-file" is for an Application file (traditionally older single-file carbon based apps), and not modern Application Bundles (multi file packages as you'd see for all modern applications). This is undoubtedly a bug hiding somewhere in Mojave, and something which seems to resolve itself over time. All is not lost though... I've just put 3.7.1 b944 pre-release which works around this Mojave bug, so the icons will be shown and the apps will be cached by Alfred! You can update to the latest pre-release in Alfred's Update preferences. Cheers, Andrew
  22. @Patrick Burleson Yielding execution means if there are multiple streams coming from one object, the next stream down will continue while the first one waits. If you take a look at the Workflow Editor > [+] > Getting Started > Stream Order, it will explain how stream execution order works, including delay. If you share your workflow, it'd be easier to see what's going on Cheers, Andrew
  23. @Magto the learning is based on the currently typed phrase, not just how many times you've selected it. For example, if you're selecting 'Energy Saver' when typing 'sa', then Alfred will never present 'Safari' at the top for the same keyword 'sa', even if it's you're most selected app when 's' is typed. To clarify, Alfred latches the typed phrase in Alfred's window to your selected result with that typed phrase.
  24. The bookmarks feature is a complimentary (free) feature in Alfred, and it's not even mentioned on Alfred's homepage or the Powerpack page. We are very careful when picking features to include in Alfred's core (instead of an extension in the form of a Workflow), there is significantly more time consuming research and due diligence than we ever talk about publicly. A few reasons Firefox hasn't been brought into Alfred's core are: 1. The low number of Firefox users (actually less than the 5% dean quotes) who use Alfred. 2. No public API for Firefox bookmarks, meaning a hacky approach would be required. This inevitably leads to increased maintenance effort to keep the feature working. 3. Firefox has complete overhauls every so often, rebranding, and re-launching. Alfred can't support this kind of nuance. This is not to say that Alfred will never natively support Firefox, but at this point in time, it's not a good fit for Alfred's core... Especially when there are a number of workflows which can satisfy this feature.
  25. Remove /System/Library/CoreServices/Applications from Alfred's Features > Default Results > Search Scope, then type 'reload' into Alfred to clear the cache. Note that if you remove all items from the scope like in the original screenshot, Alfred will default to scope 'all', which will include Core Services. Also, you won't be able to exclude Finder, even though it's in Core Services as this is included regardless. Cheers, Andrew
  • Create New...