Jump to content

Andrew

Creator
  • Posts

    4,941
  • Joined

  • Last visited

  • Days Won

    320

Everything posted by Andrew

  1. @yeagerfan if you update to the latest 3.8.1 pre-release, this is now fixed
  2. @billiesoniq scroll down past "Full Disk Access" in the Security & Privacy prefs, and under "Automation", make sure iTunes is ticked for Alfred. macOS should have asked automatically for you to grant this access, but if you missed the popup, it may have been left unticked, preventing Alfred's access. Cheers, Andrew
  3. @gentle_md that beta is 3.5 years old and long retired, just use the latest version of Alfred
  4. @Anton Patrushev if you set Alfred focusing to "compatibility mode" in the Appearance > Options preferences, then Alfred will behave like a traditional window rather than a (Spotlight-esque) panel. BTT should then be able to see window changes. Cheers, Andrew
  5. @deanishe hmmm I seem to remember there was a reason I used the NSWorkspace method instead of NSFileManager one, but can't find anything in my notes. It may have been a legacy thing... To be honest, until you said that, I had forgotten that NSFileManager even had an unmount method! I'll have a bit of a dig Edit: Aha... that method is newer than I thought, macOS 10.11+, so it's more tricky to include as Alfred 3 supports older versions than this. Cheers, Andrew
  6. @deanishe The error which is returned to Alfred after the NSWorkspace call only goes as far as Error Domain=NSOSStatusErrorDomain Code=-47 "fBsyErr: File is busy (delete)". With a quick look, I can't see anything obvious to get more info within the API, but I'll make a note to look into this when I get a bit more time.
  7. @yeagerfan I have a fix in for this already for an upcoming 3.8.1 release - it's to do with a change in the way eject errors are being dealt with. Cheers, Andrew
  8. @nikivi Okie! I don't see a problem with that... I'll see what I can do
  9. Interesting reading this thread - I'll add a note to remove the constraint there which prevents you saving when the title is empty, as I imagine that it has existed from before you could wire things into a keyword object. In the case of being a direct input (i.e. being show from an inbound connection), and there being no title, would you prefer there to be no result shown at all, just an input box? (instead of an empty result). Cheers, Andrew
  10. @politicus put the absolute path to shuf, wherever you have it installed. Cheers, Andrew
  11. @Flyshewoorst yes, I added a QWERTYZ keyboard layout, created a new project in XCode adding a local monitoring for events in the way you described, and watched the events coming in. When typing cmd+alt+# on the QWERTYZ keyboard, I see keycode 42 coming through as expected when Alfred is or isn't running. This mixed with the fact that Alfred doesn't alter macOS level events means there is nothing I can do to fix this. Perhaps try temporarily creating a new user account and try your tests there. It could be that there is an underlying configuration or app on your profile which is inadvertently causing the unexpected behaviour. By trying this on a new user account, you'll get default behaviour. Also, is your keyboard a standard macOS keyboard, or do you have a 3rd party keyboard?
  12. I've been trying to reproduce this issue this morning, and other than 1Password assume the hotkey alt+cmd+keycode 42 which is cmd+alt+\ on my keyboard, I quit 1Password and I have not been able to reproduce the issue you describe. Is there a specific reason you're using NSEvent.addLocalMonitorForEvents instead of using the Responder Chain which is the default and recommended way to interact with key events within your app? I'm changing the title and moving this out of Alfred bugs.
  13. @Flyshewoorst The only event tap Alfred uses is for snippet auto-expansion, and this is a read only view over the events for observing key patterns matching snippet keyword strings. At no point does Alfred directly alter lower level events, so there is no way Alfred can be directly altering the events in the way you describe. Could you provide a little more information on what you're experiencing (perhaps a step by step, as I can't see how to reproduce what you're trying to explain), and perhaps what you're trying to do yourself, as this may help point to why you are experiencing oddity. As you've seen in the global monitor, there isn't an issue, so it could be something to do with the way you're interacting with your local tap. Also, do you have any other apps installed which may be causing events to be changed (even in relation to Alfred), such as Karabiner. Andrew
  14. @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
  15. @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.
  16. This is the default configured shortcut for the default results too (in Alfred's Advanced preferences) - Reveal in Finder.
  17. I've just pre-released 3.8 b958. If you're on the pre-release channel, update now!
  18. 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
  19. @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
  20. @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
  21. @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
  22. 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
  23. 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
  24. @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].
×
×
  • Create New...