vitor

@cands Check https://github.com/vitorgalvao/custom-alfred-iterm-scripts for an up-to-date iTerm2 script.

No, that would not work because Python 2 and 3 are different. Also no. The thread is for requests, there’s no point in reading it all. All you need is to follow the guide to reinstall Python 2 then install this updated version.

That should be fixed if you download it again, as it got an update today.

That one is already there. You have to check the GitHub repository for the full list. It also includes links to general guidelines on the fixes. Welcome. Please redownload it (same URL) and try again, as I just did further tweaks. I agree. But that takes time. And we also have to think of the non-coders who find themselves with broken tools and need a workaround. This solution is a stop-gap, not the end goal. See my other comment for a more complete answer. Added. That’s not a Python problem. Maybe you need to update the regex in the Workflow Environment Variable or do another thing. As per the top post: “this is only for Python 2 Workflows which break on Monterey 12.3 and above due to the Python 2 removal. If a Workflow stops working for any other reason, contact the author as usual”. Added.

That is not correct. You have to follow the whole guide and you’ll end up with Python in the correct location—which depends on your CPU architecture—to be used by these updated Workflows. No, don’t do that! There is a reason macOS stops you and the guide doesn’t suggest it: so you don’t shoot yourself in the foot. Even if you got it to work by forcing it, you’d be introducing things in a way macOS doesn’t expect and could mess up unrelated apps on your system. That won’t work either. You’re only considering Python installations via Homebrew on Apple Silicon, which ignores a huge percentage of users. Plus, it wouldn’t fix cases where the whole path isn’t included. The current guide and workaround are good. This was not a rush job, it has been in place and working for weeks. It was thought out and tested to be the most efficient and simple way to provide a working installation for most people. That is also incorrect. It’s fine that you don’t know these things, we all have to learn, but please don’t confuse users. If you don’t know, it’s harmful to others to contradict the official instructions. Those have been studied, tested, and improved from a thorough understanding of the problem.

It absolutely is. Plenty of them. Converting Workflows to Python 3 is considerably more work, thus takes way more time and requires a lot of testing just to reproduce what the Workflow did. Plus I dislike Python, so I don’t use it much and am not up-do-date with all the language features. Converting a ton of Workflows I don’t use from one language I dislike to another language I dislike wouldn’t be a pleasant or productive use of time. If I were to take on these conversions, there wouldn’t be time to do all the ones people are asking for. And even if there were, not all developers continue to be active to accept a pull request, meaning forking the Workflow and maintaining something I didn’t start. Disadvantages all around. It’s way more beneficial and makes way more sense for me to cast a wide net and provide the stop gap solution for most things to work again in the short-term. That allows others (like yourself with this Workflow) the time to develop the long-term ports which will eventually replace the temporary fixes I’m posting. The GitHub repo is explicit: The ideal scenario is one where that repo is no longer necessary. In the meantime, its existence eases the transition.

@glawrie See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes a fixed version of this Google Authenticator Workflow.

@psifertex See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes a fixed version of the Video Conferences Workflow.

@cvallera See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes a fixed version of this Outlook Search Workflow.

@lutefish See the Updated Third-Party Python 2 Workflows GitHub page. It explains the situation, links to instructions on regaining access to Python 2 and includes a fixed version of the Zothero Workflow.

Added. Editing the list isn’t very useful, because your changes won’t propagate to other people and they may not have whatever runtime you’ve added. It could cause hard-to-diagnose problems when sharing Workflows. Save your script inside the Workflow with a proper shebang (#!/usr/bin/python3) and call it as an External Script as the Language. Or use /bin/zsh as the Language and call your script with /usr/bin/python3 SCRIPT_NAME. You were never limited by the languages in the dropdown, you can easily use anything on your system.

It can’t. No software can, not the way you’re describing it. An app can’t simply inject its functionality inside another. This is the way. It’s the responsibility of apps to provide the hooks for third-parties to automate them. Some have a lot, some have none. Electron apps are particularly bad. Consider JXA. Being JavaScript, the skills you learn will be more useful in other contexts and you’ll find more resources for doing generic things. As explained above, this (again, in the way you described it) does not depend on Alfred. But from your examples, it seems like what you want can be mostly covered by a Menubar Search Workflow. Further, you can also just connect a Keyword to a Dispatch Key Combo and your first use case is also taken care of, no coding necessary, no complex integrations, done in a few seconds, and perfectly customisable.

Alternatively, copy the text to the clipboard and read it from there in the Run Script. Or, and this should be more convenient for this specific use-case, always normalise whatever text is passed-in. That would have the side-effect of fixing cases where the input is decomposed.

Short answer: bundle the dependencies. Lower the need to rely on the user’s environment. Long answer is below. With apologies to @Y1ng for having this long post in your Workflow’s thread. If you prefer, I can split these to another. What specifically worries you in that scenario? Is it the extra size? I just downloaded it to a temporary directory with dependencies and it came to just under 20MB. Granted, that isn’t small, but is it worse than the alternative? Consider your case under the multi-python scenario in my previous comment. You ask a user to pip3 install audible-cli and they now have it under a Python that is managed by pyenv. But because (let’s imagine) the Workflow is assuming a Homebrew Python installation, it doesn’t pick it up and appears broken. What do you do then? You can refine your instructions to specify a Homebrew Python needs to be used, but considering a multitude of possible setups and that the path to a Homebrewed Python changes depending on architecture, you’re now spending half of the “About” from your Workflow explaining technical details which are irrelevant to most. Or you can have a Workflow Environment Variable where users add a custom Python path, and now you need to do a bunch of checks to ensure it exists, and how to react when it doesn’t, and the Python path is now dynamic and your code is harder to maintain. Or you can make your Workflow 20MB larger. What’s the best option? It depends. What do you value most? What do you believe the users of your Workflow value most? How close to your ideals can your current level of skill take you? How do different goals correlate? Is a 1MB increase in file size worth it for a program 100 times faster? What about 100MB for something 1.5 times faster? What about 20MB for extra convenience? How do you even measure convenience? There is always a tradeoff. Your goal is to identify and pick the best one for your situation. Let’s keep exploring your specific case from a size perspective. Python is popular. If every Python Workflow included a full runtime—even if it were small—the duplication would lead to considerable wasted bandwidth and space (including in the user’s cloud hosting, for synced settings). But what about audible-cli, how likely is it that a user of your Workflow already has it installed, for another Workflow or in general? If they’re more likely to not have it (seems likely), is the extra size worth skipping the hassle of having to set it up? For under 20MB, I’d say yes; if it were 500MB, I’d say no. But even that is relative. How much of a hassle are you saving? Will a user not use your Workflow because it’s hard to setup? Will another not use it because its file size is too big? Both can be true. Which of those weighs more? Which choice will make a better Workflow for most people? Which one will make a better Workflows for yourself, one that you’ll continue to have fun developing and be proud to offer support for, which will in turn be better for users? There are answers to all of these questions. Though yours may be different than mine and they may change with time. Apologies for the length of the post. Given more time I’d have made it shorter and all that, but it’s dinner time. Have a nice evening.

You don’t. That paragraph applies in general, like installing it for yourself. If it’s for a Workflow, follow the first paragraph: bundle the package with the Workflow instead of asking the user to install it. That is significantly easier for users because they don’t have anything to setup and is beneficial to you because you know what version is used. It should be something like /path/to/python -m pip install --target "/CUSTOM/DIRECTORY/PATH" "PACKAGE_NAME" and then using export PYTHONPATH="/CUSTOM/DIRECTORY/PATH" before calling your script to ensure the package is available. Not really. You can try to guess but that doesn’t give you guarantees. A user may have, at the same time, /usr/bin/python3 (from the developer tools), /opt/homebrew/bin/python3 (installed as a dependency for another Homebrew package), and ~/.pyenv/shims/python3 (version-managed with pyenv). They may have only wanted (and directly use) the last one, but the others exist nonetheless (cue XKCD). You want to avoid that, for the benefit of both users and yourself. Extra manual steps you require, especially technical ones, increase your support burden. You should either use /usr/bin/python3 directly (macOS will prompt the user to install it if they don’t have it, and that’s done in two clicks) or require a Homebrew-installed Pyhton and use that path (not directly, use export PATH="/opt/homebrew/bin:/usr/local/bin:${PATH}" due to the different Homebrew locations). @Y1ng Since you’re just calling python, this point is particularly relevant. Starting next week, with the release of macOS Monterey 12.3, that will no longer be available. Yes, you shouldn’t be using Python 2 anymore. Or anything below 3.6, for that matter.

You must’ve renamed them. Judging by the naming pattern, via @deanishe’s script which I’m pretty sure was published to the forum years ago.

@leophegor When asking for help, be sure to include the debugger output, otherwise @Y1ng can’t know what’s wrong in your particular case. Welcome to the forums.

Are you sure ⌘K is the right shortcut and that doing it manually results in the desired behaviour? I don’t use ClickUp so I can’t go through all steps but everything looks to be working. Do note that the second Copy to Clipboard needs to have {clipboard}, not {query}, because otherwise you’re copying the passed website address.

The way you’ve organised your screenshot is interesting and clear. But for future reports, it’s best if you upload the Workflow somewhere and provide a link. That’s less work for you and is more helpful to anyone helping. Doing both is even better, but if you can only do one pick sharing the Workflow because that allows us to try it in context. On with the problem. You’re conflating Alfred features with AppleScript code. {query} doesn’t come into play here because you’re (correctly) using with input as argv. The though process is reversed: that code is to store the clipboard contents into a variable, not make the given argument become the clipboard contents. Long story short, get rid of that line as it’s not doing anything. Another likely problem is that despite you having a large delay at the top, you don’t have any between the two keyboard shortcuts. That’s part of the perils of GUI automation, you always need to ensure everything has waited enough time. Try: tell application "System Events" delay 10 keystroke "k" using {command down} delay 5 keystroke "v" using {command down} end tell And adjust the second delay accordingly. Or better yet, use Alfred’s native objects: Delay Utility (wait) → Dispatch Key Combo Output (press shortcut) → Delay Utility (wait again) → Copy to Clipboard Output (paste)

Font colour is determined by your theme; Workflows don’t have control over that.

Welcome @timrosenberg, Processes which allow you to make calculations on time typically require that you be specific with the date. That is to say you wouldn’t do 9:00 + 4h but March 10 2022 at 9:00 + 4h (consider what happens when it goes over to the next day; it has to be represented). If you only want to add hours, you’re looking at simple arithmetic: (9 + 4) % 24. The % is the modulo operator. Doing it on 24 will make it “flip over” according to a 24h clock (example: (17 + 9) % 24 = 2 or “5PM plus 9 hours equals 2AM”). You can try these in Alfred’s main window by starting with = then typing the operation. If you want to use this in a Workflow, you’ll have to be more specific in your request. Right now it’s so broad it approximates an XY problem so there’s yet no way to know what the best answer is.

What exactly are you trying to discern? Different developers build Workflows in different ways, with different languages, and give weight to different features. You should use whichever you like the most and fits your mental model better. Do note this one is in maintenance mode. @Acidham’s is still being updated.

Welcome @Pchecoandres, No, that is unrelated. From the moment you start the Script Filter, it becomes the Workflow’s responsibility to show results. How? If you don’t specify what you’ve done, it’s not possible to know what went wrong. Use the debugger to see what’s happening. At the very least, you’ll probably need to install PHP. Note this Workflow was last updated a decade ago. It may still work fine or it may not work at all because in the meantime Parallels may have changed their system significantly. @flakshack’s top post has other tips on how to remake this with some manual work (namely a File Filter, but you could also try a List Filter). Alternatively, there may be another Workflow which does this.

I haven’t tried it but your assumptions seem correct. Do note that since the synced preferences are a directory, Dropbox should only sync what changes inside. That is to say in your unlikely scenario where you make changes on both accounts without internet connection, you’d have to make changes to the same path for there to be a problem. Even if that did happen, Dropbox should offer you conflict resolution (“which file do you want to keep”), though that is best avoided. Consider making regular backups of your Alfred preferences, at least until you feel confident in your system. Alternatively, you may want to try /Users/Shared as a location for your preferences. That way you guarantee they are synced between accounts and don’t have to worry about connectivity.

@cowansf @Display Name Done this version work?