lycopodiopsida

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...

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.

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.

It was meant more in the sense "everyone can help out, the coding tools are free"

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.

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.

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.

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.

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.

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.

Hi, I've uploaded it to github, see my post in this thread:

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.

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.

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.

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...

So far I've found only code for processing JSON bookmark files: https://github.com/duanemay/alfred-workflow-chrome-bookmarks https://github.com/blainesch/alfred-chrome-bookmarks Since I don't want to write the parser from scratch, I need either to grab the most recent of the json backup files, or simply convert a bookmarks.html to json first, which should be not so difficult. Need to play around with it.

Yes, it seems to be the only valid option. Every possibility to work with SQLite db is a rotten apple, even if it is cached by the workflow. In my case, browser is just running sometimes for a week, which means, DB would be locked all the time. I should look in github for older workflows with a working parser of bookmarks.html, the rest should not be that difficult.

This is not necessary true. People in web development have basically stopped to test websites in other browsers. And if an issue appears, the first question is always "can it be reproduced in chrome", as if anything not appearing in chrome is a browser bug. For a monopoly you don't have to kill other browsers, just render them significantly less useful for users. Safari, too, is not safe anymore, since the webkit !== blink.

I also would like FF to be supported, since the provided ff workflow tries to read the SQL db and is, thus not working when FF is running. I, however, don't see it that critical with workflow vs. 'provided by default' since I think that Alfred is lacking features in more important areas. A working workflow would be sufficient. A simple solution could be to allow the bookmarks feature in Alfred to parse a html file - this way FF bookmarks could be added just by pointing it to the profile folder and setting the browser.bookmarks.autoExportHTML flag. Regarding browser choice in general: I have a feeling, that Safari is somehow falling behind in performance, especially if one uses it with all bells&whistles, like adblockers. Chrome is the new IE - barebone, introducing more and more limitations, a privacy nightmare. It its strange to see, how FF is getting in the "David vs. Goliath" role once again. So, while I absolute believe that Chrome is by a large margin the most used browser for Alfred users, the thinking here should be more strategical, since we don't want to ask ourselves in 10 years how we've got there with browser monopoly.

Done!

I've posted updated workflow to github with permission from Carlos. Link to repository Direct link to the Workflow file

So, I've fixed this workflow for now... I will try to contact the original author to get his permit to republish it. Until then ping me via private message with your mail, I will send it.

I should maybe say file-based workflows, navigation as it is is fine - you find some folder and drill down. It it more about doing something with results (though I like the buffer idea since it can keep files forever). Is it difficult to implement in general? As far as I understand, mime-type can be grabbed form any file in macOS.

I am not sure it can be blamed on "lists vs trees". IMO Alfred does the navigation fine enough and has some nice features, like file preview always shown in the window. The problem is what you can do with things you've found - and here one would again land by support for system services. Zipping a found folder is something macOS can do natively, LB can do it most likely for the same reason, but Alfred would require an extra file action no one has written yet, as far as I searched. I think system services are a low-hanging fruit (well, not necessary from the amount of work needed to implement it) which would add a ton of functions instantly. So let us hope we see it implemented soon enough.

It is actually pretty simple: - create a new action - right click on workbench - Triggers>Hotkey - do the rest like in the screenshot