Jump to content

lycopodiopsida

Member
  • Posts

    46
  • Joined

  • Last visited

  • Days Won

    2

lycopodiopsida last won the day on March 25 2019

lycopodiopsida had the most liked content!

Profile Information

  • Location
    Heidelberg

Recent Profile Visitors

1,481 profile views

lycopodiopsida's Achievements

Member

Member (4/5)

14

Reputation

  1. Hi, I would also say that, in my opinion, the reliance on keywords is the least ergonomic feature in Alfred. There was a problem with the way Alfred acted (or rather the lack of actions) on content, such as text or files, but it was mostly solved with universal actions. But the lack of fast and reliable WF fuzzy search in Alfred stops me every time I decide to use it, since to be fast with it I have to remember several keywords per workflow or search for Workflows with ? or "alf" and life is too short for it - a launcher should be fast and smooth. The way it works now is maybe ok for users who use only 5 WFs overall, but for powerusers the way we trigger WFs is not optimal in my opinion. Alfred went a long way with automatizations, WF editor, WF debugging (love this feature), snippets and universal actions, so I have some hopes that the way we interact with WFs will be addressed too...
  2. Since we are moving in a new amazing direction, are there plans to introduce more automatic triggers, e.g. do something based on application focus switch or application activated? I am aware that it also a scope thing - such things can be done with Keyboard Maestro, Hammerspoon and BTT. However, since we are already moving in that direction with window management and all these applications use the same API, why not? In the end, it can mean 1 app less to buy/configure for some people and also more sophisticated workflows in general.
  3. I see... it is indeed a problem also for the "Search Apple Music workflow" which is broken now - it would be trivial to fix it, but alfred module is imported. Is there any chance it could be ported to python3? I assume that it would ease the porting efforts for the rest of the workflows significantly.
  4. It was meant more in the sense "everyone can help out, the coding tools are free"
  5. I would not claim that the changes were huge, just because Python2 programs do not run unchanged under Python3. If anything, it only proves that it was handled in a very bad way. Looking at Swift and Rust a lot is possible with feature switches and language editions, and Java is an example of a language of a comparable age, which handles the changes nicely, although it has removed some deprecated API's and had some module-related breaking changes with Java 9 which already caused enough problems. But even for huge changes, like project Valhalla, they are absolutely committed to backward compatibility. Python, on the other side... well, we know how it went.
  6. I can see the value in a widely used language such as python being delivered with the operation system, but... besides it being a very convenient attack vector most users are not aware about, I have to say that it is also not very useful as power user/developer. Even in an ideal world, where apple would take full responsibility and updates python in time there is still version-pinning, question of environments and so on. I think the general wisdom was "never use the macOS-provided python version for any serious task" so that is was more of a inconvenience since you have then to reconfigure aliases/links by hand. Of course, part of the problem is than Python has handled the transition from 2 -> 3 in the worst possible way, cause a big rupture out of a pretty minor change. These days it would be done with some kind of "-lang_feature=python2" tag, but we all learned from it. I don't know what is the position of Apple on Ruby, afaik it was used a lot in AppStore and old itunes app... but even if it will be excluded from the default shipment in future, it is pretty stable in a good sense. On the other side, I do not think that Python will make the same mistake again. Workflow developers own us nothing, and I have fixed some incompatible workflows in the past. But on the other side, python2 cannot be provided forever just because some workflows are abandoned, especially since in that case the blame is more on python itself. I have not touched python in years, and most code I wrote was in Python3, but as far as I remember the changes from 2 -> 3 were pretty trivial in most cases, there were even some automatic transition tools. If not, we should find people in the community who help port essential workflows to python3. VSCode/Pycharm CE are free as a beer, after all. I am in the middle of moving my household, thus a bit of time-constrained, but for non-urgent workflows I could offer my help.
  7. My point is not about counting apple's money, but whether shipping such things as python with operation system is justified. I think it is fair to say that there is a general agreement in the developer's community these days, that it is not. How Alfred solves it, is an entirely different question which is not important, since this problem is solvable - from providing instructions for homebrew to triggering installation for xcode-tools or leaving it completely up to workflow-authors. And to be honest, even if apple would remove in 2 more years, there would be be people completely surprised by it.
  8. Apple has other implications - apple shipping a python distribution with the current read-only system partition means either a drastically increased system update cadence, or a potential security issue for all users in case of a vulnerability. The time of kitchensink-style operation systems, shipping everything - from JVM to web server - is gone, for better or worse. Getting these tools/languages installed is also pretty easy these days. Apples remove schedule is as erratic as ever, but to be fair python2 was marked as deprecated in Catalina in 2019. Thus, it is hardly a surprise. What weights heavier, is that there is no support from Python development team for Python2 since 2 years. The timing may be wrong (should have been with the Big Sur release), but the action is still justified.
  9. I will not go them off the hook: writing is on the wall for Python2 since two years at least - from python developers and from apple's side. The problem is python2 being outdated and not supported, thus not trivial to install anymore with e.g. homebrew. Shipping an python3 distribution is trivial, alfred could provide an own.
  10. It seems, that macOS 12.3 (the last update) finally removed python2 from the system. The decision to do it in minor release is questionable, but it is what it is. A surprising number of older workflows is still written in python2 and authors never bothered to port them to python3. You could install python2 manually, but it is not really advisable, since it received no updates/patches for 2 years and is a potential security issue. Other than that, there are not so many options: port the workflow to python3 by yourself, wait for author to do so or look for another.
  11. Hi, I've uploaded it to github, see my post in this thread:
  12. Hi, nice work! I still wonder, however, whether a workflow could be created which will send a selected file(s) with file action to airdrop.
  13. Hi, You don't need a workfow for such tasks in Launchbar. Launchbar has a pretty good system integration, so the only thing you need is a system service for text manipulation, as described here: https://developer.apple.com/library/archive/documentation/LanguagesUtilities/Conceptual/MacAutomationScriptingGuide/ManipulateText.html Here is a bigger collection but you will also find other if you google. After you install such a service, you can call it directly from LB.
  14. I think it is a limitation, users can live with. Being up to-date is not such a big deal for bookmarks, which are mostly static.
  15. Hi Jan, there is a recent thread about it: Short answers: yes, it is possible to some amount. You need a shortcut for text as described in the thread I mentioned which you would call with a separate shortcut (double CTRL in my case). It would place the text in Alfred and place the cursor before the text, so you can call a workflow on it. I mention a workflow, and I mean it - without it, Alfred cannot do much with with your text. Unfortunately, such functionality is really a very strong side of LaunchBar...
×
×
  • Create New...