Jump to content

vitor

Staff
  • Posts

    8,507
  • Joined

  • Last visited

  • Days Won

    708

Everything posted by vitor

  1. Made a few small updates. Added support for the new notificator and removed support for the old one and terminal-notifier. I also improved the process of getting packages from GitHub, to ensure a .alfredworkflow is downloaded. You don’t have to add the new version to your Workflow if you don’t want and it’s working fine; nothing was broken, the behaviour is the same.
  2. Given the constraints, yes. You can improve it by using ?workflow myString instead of ?myString. That way you guarantee to only match against Workflow names, not their objects. But why are you running AppleScript code through Python, is it part of a larger script? If not, run it directly because it will be faster, more readable, and more resilient.
  3. @LaurentP See Making Python 2 Workflows work on macOS Monterey 12.3 and above. This Workflow is already covered.
  4. @xilopaint I have revamped Notificator. No intensive testing yet, but it seems to work as expected. I’ll soon substitute it in all my Workflows. It’s now way more Alfred-centric, and expects to be run from inside a Workflow environment. Notificator is released to the public domain, so you do not have to credit me for the inclusion. That said, because you will be adding it to a library instead of a stand-alone Workflow, I’d appreciate a note about it linking back to the original. That is so if people have suggestions or comments or complaints, they do so at the source and I can improve it for everyone.
  5. The sound is coming from macOS, not Alfred. If you press your Hotkey when nothing is selected, you’ll both hear the beep and see the Edit menu of the app you’re in flash. If you press ⌘C in the same situation, you’ll get exactly the same thing. Copying is part of how the feature works. You may still be able to get around it and find some API to get the text selection of apps, but I suspect it will end up being a finickier solution that might not work on non-native apps. Can’t say for sure, as I haven’t researched it.
  6. I will work on it behaving as we discussed. I should have something this week, barring some unpredictable factor. The interface isn’t yet complete in my head, so I may be forgetting to consider something. Please ping me when you do, so I can link to it on the table as an alternative.
  7. Added. But that Workflow is old. If you were not using it before, it may be broken anyway for unrelated reasons (e.g. changes in the Skim app).
  8. Looks like I inadvertently removed the download and source links from the top post in the latest edit! Readded.
  9. If you’re on Monterey 12.3, you’ll need further fixes. Reinstall Python 2. Redownload and reinstall the Workflow, to regain the executable bit. Open the Workflow in the Finder. Locate the save_attachments.py file and open it in a text editor. Change the top line from #!/usr/bin/python to (if you are on an Intel Mac) #!/usr/local/bin/python or (if you are on Apple Silicon) #!/opt/homebrew/bin/python.
  10. That won’t work for people on Apple Silicon. The more versatile option is to prepend export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" and then call python (no full path). Like so (linked removed because fix was added officially).
  11. Sure it does. I have been using it for almost a decade, as has every other user of the Workflow. If it’s not working for you, check the debugger. You know how this works—if you don’t give me any information on what you’re doing and what’s happening, there’s no way for me to help you. The Workflow makes the conversion using the correct BBCode tags; the result os only visible when previewing or submitting the post.
  12. env points to whatever is in your environment; that’s the point of using it instead of a full path. It’s why export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" works, as I’ve explained. And that’s why these Workflows need tweaks. @m4Aark pointed you to the updated version, the instructions above are correct. There’s no setting for it, I auto-stylise them via MarkdownTransform.
  13. You’re supposed to install the symlink in ${HOMEBREW_PREFIX}/bin/python, not /usr/bin/python. @m4Aark correctly mentioned that above. Though they did not mention two important steps which may be necessary first: export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" and eval "$(brew shellenv)". These are all covered in the KB article.
  14. Welcome @eysorindik, The creator of this Workflow hasn’t visited in a long while. As the maintainer of a similar Workflow, I’d be interested in reading your findings.
  15. That’s not a Python issue, so you’ll have to ask the developer.
  16. It’s the same thing conceptually, which is why I mentioned it. What I’m having a think about is the implementation, because if I do it it will be a single script you call and does everything, it won’t use extra files.
  17. Welcome @thehotrod, You're in the wrong thread. The correct one is In particular, see the second post. It will tell you how to get the correct path to Google Drive and the information I need in case you continue to have issues.
  18. Added. Not a problem, continue with the reinstallation. What’s the use case? A Workflow which would need that fix is unlikely to work without modification anyway, and I’m already applying the fix to the updates I’m making. In other words, for that Workflow to be useful to you, you need to know how to fix it.
  19. That’s a nice gesture, but do make sure he’s OK with it. What we know is an homage can be perceived by others as an endorsement. I have no idea what Dean’s thoughts are on the matter, but I know mine. Sometimes people really want to show their appreciation and that is touching, but to me it is important that I don’t seem to be involved with something I’m not. Definitely! In the meantime, you can just show a Notification via AppleScript. It won’t have a custom icon, but everything else will work. Yep. Notificator needs to be built in advance, for the icon. Though I could change it so it’s built on-demand and cached. I’ll have a thought about that. That’s the right choice and what I expected you’d do. I frequently mention you when pointing to developers who were already making Python3 Workflows before the removal. That is needlessly complex. All you need is export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}". That single line will make calls to python3 use a Homebrew-installed Python if it exists, or /usr/bin/python3 if it doesn’t. If the user doesn’t have the latter either, macOS will take care of it by showing users a GUI to install it in two clicks. It’s not that env isn’t working, it’s that env checks PATH, and Alfred uses the default. That’s why that single line solves it all.
  20. And I’m happy to report the list isn’t only growing, but shrinking as well! When a Workflow is officially updated, it’s removed from the table. In the past three days, that has happened four times. Some of them have non-Python 2 alternatives listed, but that column was only added three days ago so it has plenty of room to expand (submissions welcome!). @CandiceJoy To answer your Python 3 question from a developer perspective, the simple answer is that the Python team broke compatibility from version 2 to 3. It’s largely considered a botched transition which took over a decade to complete and is still felt, to the point the creator of Python has publicly stated there may never be a Python 4.
  21. Welcome @Crystal, See Syncing Your Alfred Settings Between Macs.
  22. @Eiffel See Making Python 2 Workflows work on macOS Monterey 12.3 and above.
×
×
  • Create New...