crisb

 What tool? I am looking for the same thing!

I know of two, each with its own tradeoffs (I assume it's OK to post this here as neither is a direct Alfred competitor):

If you can live without the tab search, Contexts is an excellent app switcher. It has a search mode which can find windows based on partial typing of the app name or window title. I like this app so much I tried using it for a while, and just not using Chrome tabs at all (using one window per site). That proved unwieldy. I have asked the developer if browser tab titles might be supported, and was told it was a frequent request that would be considered for the future. I'm keeping an eye out on that.

So now I'm using Optimal Layout. This is a window manager that's useful enough just for that purpose, but it also has a built-in app switcher with search. It can find browser tabs. The caveat is that it excludes Chrome tabs by default. This can be changed in the preferences, but there's a warning that Chrome tab support comes with bugs. I've found that to be true, but it's worth living with as the only workable solution for me so far.

Note I did refer to a 'different' tool, not a perfect one (yet)

I think this workflow is ready for you.

 

https://github.com/stuartcryan/rapid-browser-tabs-for-alfred

That's precisely what I'm not after. I want to hit one keystroke to search for and then jump to any open app, window or tab. Not to have to think "is this task in a window or tab?" and then choose between a bunch of workflows/keystrokes.

Do you use desktops? I have a lot of apps like browser, editor, terminal, chat, etc. and I need to switch between them quickly. So I've created 7 desktops, bind main apps to it's own desktop and assigned shortcuts for them (cmd+1 - cmd+7). Switching between desktops/apps in such way is very fast.

But it will not help with browsers tabs, so for such case appropriate workflow is required.

I have used multiple desktops in the past but tend not to at the moment (I fell out of the habit). I think my current workflow tends to involve too much flicking between disparate groups of small windows than really fits siloing them in separate desktops. Also my natural tendency is more verbal than spatial -- I think 'project name' not 'desktop 3'. But it's definitely worth thinking about, so thanks for the suggestion.

Having given all this a bit more thought, I've realised Alfred is probably the wrong tool for this particular job, excellent and flexible though it is in general. For it to suit my case, Alfred would need to have the capacity to plug workflows into the Default Results (ie. to inject open app names, and window and tab titles in amongst the app and file search results), as opposed to launching a separate workflow. AFAIK this isn't possible.

I have found a different tool that I think suits this particular job better.

I'm giving Alfred another try after not having used it for a while. I'm mainly considering it as an alternative to an app switcher called Contexts (https://contexts.co/) which, while generally excellent, suffers some unfortunate side-effects that Alfred doesn't.

I work with many apps running on the mac, and jump between them often. Cmd-tabbing through a long list is too slow. So I want to use the Alfred popup window to search for my already-open stuff and jump there.

For apps, this works nicely -- if the app is open, Alfred finds it and its window is brought into focus; if not, it the app is found and launched. Perfect.

The scenario it doesn't cover (but Contexts does) is for web apps open in seperate browser tabs (or windows for that matter). I use Trello, for example. Rather than jumping first to Chrome, and then finding the Trello tab, I want to start typing "Tre.." and have Alfred offer it.

Note the crucial thing for me is that all this is one integrated action (search for running apps and tabs/windows). I am not, for example, looking for a 'search browser tabs' workflow. That adds the load of deciding which Alfred operation to perform (standard Alfred search, or search tabs workflow), dozens of times per day.

Is this something Alfred can do? I'm currently on Alfred 2 but will upgrade to 3 if Alfred can do what I want.

Do you have more than one version of 1Password installed? E.g. beta and app store?

Ah, that's the issue. I only use the beta these days but have had the app store version in the past. And sure enough there's a stale bookmarks-default.json in ~/Library/Containers/(etc).

Thanks again.

Got it! I manually added the path to bookmarks-default.json, and Alfred picked up all the logins.

This solves my problem, but it presumably means Alfred was automatically looking in the wrong spot? Anyway, I'm happy now.

@

Alfred only treats valid URLs as valid bookmarks. If an entry in 1Password is missing either http or https in the URL, Alfred doesn't include these so as not to make any assumptions... so the missing items may just be missing http or https in their URLs in 1Password.

 

Let me know!

 

Cheers,

Andrew

Hi Andrew -- thanks for the reply! That's not it in this case. Here's an example of an entry in bookmarks-default.json but not showing up in Alfred:

["[hash]","Udacity","https:\/\/udacity.com"]

That's typical of the missing bookmarks. They don't seem to differ in any obvious way from the ones that are showing up, though I confess I haven't spent the time to look through thoroughly yet. I've been using Alfred for ages, but for some reason never got around to using the 1Password integration, so have only just discovered this issue.

Cheers,

Cris.

I haven't counted them up, but the list of 1Password 1-click passwords in Alfred prefs -> Features -> 1Password is missing many entries in my bookmarks-default.json.

Alfred does find the file (set to 'discover automatically' in the Advanced dialogue), and a subset of the bookmarks. But some are missing (I've looked at bookmarks-default.json in a text editor and can see many bookmarks there that are not found by Alfred).

There's nothing obvious in bookmarks-default.json to distinguish the bookmarks Alfred does find from the missing ones. 

Maybe it's just a matter of not having developed Alfred-y habits yet (I'm a new user), but I often find myself starting to type in Alfred, then remembering it's a file/dir I'm looking for, so having to backtrack to prefix the search term with ' or a space.

Is there a way to quickly switch to file search mode mid-stream? 

Check out the 'Setup fallback results' button toward the bottom of 'Features > Default Results'

Great, I missed that. 

Thanks.

By default, in the absence of a keyword, Alfred offers me Google, Amazon and Wikipedia to search for a term (that isn't an app name).

How can I either add to this list (to make further searches available with cmd-<numeral>), or change it (eg. to replace Google with DuckDuckGo).

I realise I can use keywords to select different searches, but I'd prefer a different set of defaults.

I don't think this is possible yet, but that sounds really useful! Maybe an 'Add files to buffer' Action object?

Perhaps you should post a feature request in the 'Feature Requests' forum

Good idea. Done.

It would be great to be able to add files to the buffer from a workflow.

This would make possible workflows such as:

- add currently-selected files in frontmost Finder window to buffer

- add paths on clipboard to buffer

etc.

Is it possible to add files to the Alfred buffer from a script?

This could make for some really nice workflows -- eg. adding the current Finder selection to the buffer via a hotkey.

No there isn't currently a way to do that in Alfred. If you are primarily looking for folder results you could make a filter to show only folders in the search results.

Ah, thanks. I'm new to Alfred and hadn't realised how simple it is to use a file filter in a workflow. Nice.

Is there any way to get Alfred to list folders at the top of the File Search results?

@franz: Thanks. I was thinking in terms of this being the default behaviour.

However before spending any time on this you might want to check out a related thread where someone's already posted something very close to what I'm after. It doesn't re-use existing Terminal windows like your workflow does, but is very functional as-is.

Here you go: dterm-ish.applescript

 

I'm playing around with making this into a workflow, so you can run scripts in the background and get file/command suggestions while you type. It's not ready yet, but hopefully that custom terminal script holds you over for now. 

That's a terrific start, thanks. Look forward to anything further you do along these lines. Be sure to tweet about them!

Looking through the code tends to confirm my Applescript prejudice. It's very readable, but it triggers memories of trying to write applescripts, and it seeming more like a trial-and-error process ("which Englishy locution works where?") than any other programming language I've ever tinkered with.

Some of it. DTerm uses the Accessibility API and Scripting Bridge to determine the path for the front-most app. You'd have to rip the code from DTerm (https://github.com/bdrister/dterm) that gets that front-most path or selected files in Finder/PathFinder and create an executable that spits out the path(s). Wire up an Alfred hotkey to that code and do what you like with the results.

Thanks, I didn't know the DTerm source code was available. Must have a look through it when I have a moment.

DTerm is useful and nice enough that it probably doesn't exactly need replacing. But as since finding Alfred I've been able to ditch so many other little utilities, I'm just wondering if it would be feasible to write a workflow that would do DTerm's job. I'm a developer, but have a genetically-predisposed horror of AppleScript, so don't offhand know if this is feasible. Would be interested in opinions.

DTerm is a great little app that allows you to run shell commands from its own mini-terminal, but the magic is that it sets its working directory to wherever the frontmost app window's open document is located. Which is great -- you can, for example, be in an editor/IDE, pop up DTerm (with a keyboard shortcut) and run git commands from the directory of the file you're currently editing.

It can also optionally run a command in a real Terminal (or iTerm) window if desired.

Could this functionality be replicated in an Alfred workflow?

How difficult would it be to adapt this to work with applications other than Finder -- ie. to open/start a terminal session in the directory where the frontmost application's currently-open document (if it has one) is located?

This might make it possible to replace Dterm (since Alfred seems to be replacing so many of my other tools, why not?).