vitor

Update. If you choose any of the options that let you pick from a list (“wlp” and “wlu”) and continue typing after it (don’t put a space, just continue typing), you’ll start filtering the names, so you can quickly find the ones you want.

Update. Fixed issue where adding to the watchlist from an unsupported url would cause it to add a blank line; the name of the video is now between quotes on the output notification; updated youtube-dl.

Another vote for this. Drag and drop from the file buffer would be insanely more useful than simply dragging from the results.

You’ll see on the first post that’s the reason I decided to not include Firefox in the list — it’s not a reliable method. This is supposed to be a list that includes the shortest, easiest to compreend, most effective ways of getting that information, which is why Firefox is absent — like you said, it needs a hack. Camino was removed because it was discontinued. I do something similar to that script on my PinAdd workflow (if the user picks “depends” as the browser), but I use bash to call the relevant information. The goal of this post is not to use applescript, but much to the contrary, to show how to use it to the absolute minimum just to get the relevant information you need to, from each browser, so you can call it from your language of choice.

My point is that Chrome was given as an example, not a use case. If you call Chrome enough times, even pressing “c” will get it on top of the list, and the browser is one of the most called apps, so I very much doubt he wants to actually call Chrome via “ome”. Using workflows in that manner is not ideal, since it would never scale — he needs (is asking for) a way to make it work across the board, for everything he might need. The answer, given by Andrew on the second post I linked is that no, it’s not currently possible to do it “out of the box” to that level (and he explains why), but it is possible to make a workflow for it.

He’s using Chrome just as an example. That solution would be impractical in the long term, as he’d have to do the same for everything. Like Racer pointed out, the feature is there. Also, if you do a search in the forums for “fuzzy matching”, or something similar, you’ll find a bunch of posts pertaining to the same question, and explanations as to why it works like that. You can see the differences between fuzzy and full fuzzy, and why it’s not the default.

From what I’ve read on this forum, yes, you can run them concurrently without a problem, if you want to try it out. However, there are additional features that you only get with the paid version, namely file navigation, file actions, some 1password integration, custom searches, and others, that you might miss.

It’s not simple to explain the power of workflows without knowing how you use (and don’t use) Alfred and your computer day to day, and hence in what way they could be helpful to you — it’s one of those features that you get used to and use more and more, as you start to understand everything you can do with them. They’re not without their share of limitations, but are way more powerful than extensions. If you don’t plan on using any, never really cared for custom actions (extensions, and now workflows) anyway, are happy with how your v1 is working, and don’t feel like spending the money, then keep it.

I’ve been seeing this kind of situation more and more. It’s starting to feel like just having all the boxes unchecked by default would be a better option, since a lot of (novice?) users do not seem to understand what they’re for (or don’t pay attention). Since it’s also a bit tiring to select a specific set of characters for escaping over and over, an option to have a default (or let Alfred use the latest one) would give greater control to more experienced users. A different solution would be to substitute the check boxes for an input box. That way, users could simply type what characters they’d like to have escaped, depending on their specific needs (the current options certainly do not cover every case).

Common mistake. On the window where you’re writing your script, look for “Escaping”, right above the text area. Deselect there what you don’t want to be preceded by the backslash.

I suggest you take a look at the workflows section, to get a feel of what can be accomplished with them (look for the ones with a lot of details and screenshots). At this point, it’d be difficult to argue against this feature alone being well worth the upgrade.

Seeing as you don’t seem to need a lot of control, easiest way would be killall sass

I do not intend to make and maintain a separate version with marginal different behaviour, specially since there are easy instructions, made simpler with each revision, exactly for that purpose. Like I said before, when you already have the tools installed, you only need to start at step 6, and it’s pretty straightforward, just one small addition and one small substitution. The reason I don’t include that feature by default, is that it would mean bundling ffmpeg with the workflow, and I choose not to do that due to its license. Not that its license is necessarily incompatible with mine, it’s not, but I made the conscious choice of making the workflows on that github repo, together with every resource in them, public domain. In another post I briefly touched on why, for this reason, I decide to not include software with more restrictive licenses. I want anyone that uses this code to be able to take any part, at any time, and use it in any way, for whatever purpose they so choose, without having to think about it. You could argue I could simply include the command for it, and not the ffmpeg executable, but that, to me, does not seem like it’d provide a good user experience. I can bundle youtube-dl because its license is essentially the same as mine (do whatever you want). Fortunately, what this also means, is that you (or anyone else) are free to get this workflow, bundle ffmpeg with it (and/or include the relevant commands), and redistribute it. I’ve uploaded the version that gets both the video and audio (available for seven days), and removed from it the updating options, so it won’t automatically replace yours again. In the future, however, you’ll have to do the command substitution yourself (or keep that version); it really is very straightforward, and if there’s any step you find to be difficult to follow, I’d be glad to help, and possibly even update the instructions to make it clearer.

No problem, you should then finish it up by filling the titles and descriptions, and perhaps even adding an icon. If you need any help making a modification, let me know, but it should be straightforward to figure out what everything does.

Unfortunately, since it’s calling the window to the front, it means it’s recognising it, so I’m not sure why it is not working, specially since it does work with other apps (such as Alfred). I’ve downloaded the trial, and not even the example they provide is doing anything, so someone else will have to pick this one up (or you could contact them directly).

I’ve seen this misconception a number of times already, so I’d like to first clear that you do not need to make your workflows in python. Realistically, I often find simple (about 5 or 6 lines) python scripts that could be accomplished just as well with bash (and the tools that come with the OS) in just one line (which is the case here). The code you want for this is grep '{query}' FILE_TO_SEARCH.txt > FILE_TO_OUTPUT.txt How you implement it in Alfred, however, depends on your exact needs. How would you prefer this to accomplished, would a File Action that always outputs to the same file (say, on your Desktop), suffice? If yes, then try this quick test (link available for seven days). You use it as a file action on any file, and it’ll show a window asking for the string to search (don’t mind the text that’s already there, it won’t interfere, and it’s needed for Alfred to know what to do next). Let me know if it fits your needs.

I’ve repurposed one of my workflows to make a quick one for this. Keep in mind I do not have the app, so I cannot test if it’s working correctly (that’s up to you, now). Get it here (link available for seven days) and let me know. Do jns (JustNotes Search) and write something, to search for it, and jnm (JustNotes Make) to make a note — write what you want, and after that use “ // ” (space, slash, slash, space) followed by your tags. So you’d for example do “This is my text // and these are my tags”.

You don’t actually need on alfred_script(q), here. You can compress everything to one line, by doing tell application "Google Chrome" to quit, which will do the same, and will be more readable/maintainable, when doing it to multiple apps. However, I agree with David that using the builtin quit might be simpler, depending of course how how much control you need out of this.

Sure, what features do you need? If you don’t need tags to be inserted directly from Alfred, for example, then it’s even easier, because you don’t even need a workflow — you can just set it up as a custom search.

It works for me. You need to be more specific with what you’re trying to do. Are you using a workflow, are you simply typing the URL in Alfred, what exactly do you need?

To edit the title, first do Edit, to edit the post, and then pick Use Full Editor.

So you basically want a way to automatically press ↩? You can do that via applescript with tell application "System Events" to key code 36 Is that what you’re looking for?

Update. It now uses a more “natural” directory detection. Commands start in the frontmost Finder window, and if you have none selected or open, they’ll start on the Desktop.

Update. Removed Camino support.

Updated the list. Removed support for Camino. As a reference, it was # Camino tell application "Camino" to return URL of current tab of front browser window tell application "Camino" to return name of current tab of front browser window