luckman212

It annoyed me that LiveText activated when I didn't want it (e.g. when trying to draw a marquee in Preview.app) so I came up with this quick little toggler for the feature. Only tested on macOS 12.0.1 on an M1 Mac Mini. Please report any problems!
 
https://github.com/luckman212/alfredworkflows/blob/master/LiveText.alfredworkflow
 

 

So it seems that the underlying metadata server doesn't like the trailing -. In fact, Spotlight on Big Sur also doesn't match with the trailing -.
 
It looks like this behaviour, previously working in Mojave, seems to have been rectified in Monterey so I'm going to close this issue as I don't want to put in temporary workarounds.

It annoyed me that LiveText activated when I didn't want it (e.g. when trying to draw a marquee in Preview.app) so I came up with this quick little toggler for the feature. Only tested on macOS 12.0.1 on an M1 Mac Mini. Please report any problems!
 
https://github.com/luckman212/alfredworkflows/blob/master/LiveText.alfredworkflow
 

 

It annoyed me that LiveText activated when I didn't want it (e.g. when trying to draw a marquee in Preview.app) so I came up with this quick little toggler for the feature. Only tested on macOS 12.0.1 on an M1 Mac Mini. Please report any problems!
 
https://github.com/luckman212/alfredworkflows/blob/master/LiveText.alfredworkflow
 

 

It annoyed me that LiveText activated when I didn't want it (e.g. when trying to draw a marquee in Preview.app) so I came up with this quick little toggler for the feature. Only tested on macOS 12.0.1 on an M1 Mac Mini. Please report any problems!
 
https://github.com/luckman212/alfredworkflows/blob/master/LiveText.alfredworkflow
 

 

It annoyed me that LiveText activated when I didn't want it (e.g. when trying to draw a marquee in Preview.app) so I came up with this quick little toggler for the feature. Only tested on macOS 12.0.1 on an M1 Mac Mini. Please report any problems!
 
https://github.com/luckman212/alfredworkflows/blob/master/LiveText.alfredworkflow
 

 

Nice info @vitor — and you're right of course. I switched to a different theme and the dancing colon was gone. Always interesting to learn about obscure features like this.  I suppose it'd be easy to change fonts by duplicating the theme in Alfred, but now that I know why this is happening it doesn't bother me anymore!
 
Reminds me of this funny stand up comedy bit—can't remember who now (Ray Romano?) but goes something like..... "when you start getting older, you might notice a lump one day on one side and start panicking... until you feel the same lump on the other side and breathe a sigh of relief.  Whew!  It's symmetrical. It's supposed to be there!"
 

Sometimes, the connection between two nodes can be moderately complex:
 

 
That’s two checkboxes and a text field. If I want to move that connection to another node or temporarily disable it, I open it, save/memorise it, delete it, move it to another place, redo all configuration. I’d like to be able to move a connection to a different origin or end node easily while keeping its configuration.

This is great. Glad to see so much discussion and careful thought around this issue. Thanks @deanishe for your explanation of the subprocess / PATH issue. And thanks to @vitor and of course @Andrew as well.
 
I agree with the concept of a per-workflow: [x] Enable Homebrew support checkbox that sets  PATH  and  HOMEBREW_PREFIX . That seems like a really low-impact way to provide this functionality without affecting anything for existing users or people who chose not to use it.
 
 
Actually it doesn't ignore it—I've run into trouble once or twice by overriding  PATH  and forgetting to include a necessary dir.
 
Example:


 
(Script:   echo $PATH )
 

 

Sure, the variable will still be set, but nothing will actually pay any attention to it, will it?
 
Let’s say you run $HOMEBREW_PREFIX/bin/youtube-dl. When YTDL wants to call FFMPEG, it doesn't consider $HOMEBREW_PREFIX or its own path. It just runs the command ffmpeg, so if you haven’t altered PATH to include $HOMEBREW_PREFIX/bin, where ffmpeg is, the call will fail.
 
In situations like this, you will need to do export PATH=$HOMEBREW_PREFIX/bin:$PATH

As mentioned above:
 
 
It wouldn’t be a controversial decision (context: I’m a Homebrew developer).

Thanks @Alfred0!
 
My most favorite use-case is actually something that I hadn't originally thought about:
"Search Google as You Type"
 
Google has become more and more of a question-answering-machine.
So many times, I just want a quick answer and am not looking at reading articles/blogs etc.
For those cases, the mode of operation is "search google -> look at result -> move on".
 
The extra pane fits so well for them!
And ofc, pressing enter would open the same page in browser if I want to interact with that page further.

@Andrew The above involved writing this script filter:

I would agree that writing such a script filter is a minimal-effort, no-hassle thing.
It does feel like a teeny-tiny duplication-of-function though, given that Alfred already has awesome web-searches.
Is there a way to access the URL the web-searches are building?
Or, would it be possible to expose those URLs through press-secretary?
Or, is that not desirable due to privacy concerns?
 
Also, is there a programmatic way of accessing the web-searches? cc: @deanishe @vitor
(that way, someone could programmatically build a workflow mirroring the web-searches and their keywords if they want)
I scoured through various plists and alfdbs, but couldn't find where they are stored...
Are they stored in some proprietary format / right inside the binary?
Or did I miss something obvious?
 
Having said all this, I must agree I don't really foresee much value in doing this for all web-searches because with the exception of google and wolframalpha, I would assume most of the searches are such that they require further interactions with results (like clicking a link, copying some text etc).
 
Aside:
Here's a different (vertical) configuration I've been toying with:

 

subprocess.check_output() is a bit simpler.

I just released version 1.2.6 of the workflow, which has the following changes:
Match 3 and 4 digit codes if they immediately follow "code" or "is" (e.g. "your code is 1234", "enter code 573 to log in") Thanks to @luckman212 for the PR!
 
Download the latest release: https://github.com/squatto/alfred-imessage-2fa/releases/download/v1.2.6/iMessage.2FA.alfredworkflow

@gingerbeardman Hey 👋   Happy Friday!  I wasn't referring to your workflow actually. I was talking about Red Sweater's Usable Keychain Scripting (download).
 

I just released version 1.2.5 of the workflow, which has the following changes:
By default, only messages received in the past 15 minutes will be searched You can change how many minutes to look back by changing the `look_back_minutes` workflow variable Tutorial: How to set workflow variables Thanks to @luckman212 for the suggestion 👍🏻
 
Latest release: https://github.com/squatto/alfred-imessage-2fa/releases/download/v1.2.5/iMessage.2FA.alfredworkflow

Great! Next time, let's do this without all the drama.

@Chris Messina this is indeed a UI issue, however minor, as the underlying feature works as expected (all URLs are routed via macOS).
 
Alfred should really dynamically be showing the correct default handler if possible.
 
Taking suggestions from this thread (thanks for the relevant input), I've updated Alfred to show "Open With" instead of "Browser", and the default handler will automatically update as you type, for example:
 



 
This should be in the 4.3.2 pre-release in the next few days.
 
Cheers,
Andrew

On behalf of the thousands of UI designers upon whom the world depends, I take umbrage with characterizing UI design as the least of the world's software design problems.
 
But I will otherwise ignore it because it is irrelevant to my original point, which was about the "truth" in the interface, which you seem willing to accept as a "lie" for "practical" reasons, which is your wont to do.
 
I prefer to stay stuck in my theoretical bubble if it allows me to pursue increasing honest or accuracy with the users of software that I design or contribute to.
 
 
 
On the contrary, I am interested in expanding the use cases and generative outcomes that users of Alfred perceive based on the accuracy of its interface.
 
That Apple hasn't made this shift in the General preference pane doesn't mean that Alfred wouldn't benefit its users by indicating that routing via URL schemes is an increasingly common pattern, and that URL schemes may be handled by native apps and not just "web browsers".
 
A more compelling argument (that would take into consideration your metaphorical "negative numbers") would be that all apps should now and forever forth be considered "browsers" because any app can register one or more URL schemes into LaunchServices and thus can be refined according to the previous paradigm without disrupting it. This is more akin to expanding the set of "counting numbers" to the set of all "real numbers", which is more inclusive and still as accurate.
 
--
 
Regardless, if you didn't like my proposal, you could have just plainly said so without disparaging me as a "fellow designer".

@luckman212 Alfred is wrapping the Large Type output at approx 50 chars by default, which is why you're seeing this.
 
I've added the following option for the next build, which turns out to be actually really quite useful option:
 

 
Cheers,
Andrew

In case anyone wants to really get nuts with fine-tuned URL scheme management, I suggest checking out Finicky. It's up on GitHub:
https://github.com/johnste/finicky
 
It lets you route URLs to different apps using rule-based logic. So you could make URLs containing *.google.com open in Chrome, and still keep Firefox as your default browser (example).

I was troubleshooting hotkeys today and realized you can type ?hotkey into Alfred to query for hotkey triggers.
 

 
Neat. BUT, the filtering seems to be based on the Title and Subtitle only (they hotkey itself is not included) so e.g. this won't work:

 
Is it possible to query using ?hotkey for the key itself (maybe a feature request...)
 
 

Hello, it would be a great feature to have possible to set color (bold, italic) for some text for "title", "subtitle". Or for "LargeType".  I think it's not just esthetic feature - it has a functional meaning.
For example, in my workflow (for Language study) there is no possibility highlight phrase or word, except as braces (braces is not very good readable). But the functionality of this workflow is built entirely of this.
Thank you in advance!
 

 
Expected
 

I saw this has been asked a few times before (e.g. here) but there wasn't a clear answer.

Since Alfred 4 is coming soon, I would like to throw this into the pot to see if it might be possible.
 
My brain is getting old. It's hard to remember all the different keywords and hotkeys I've set up. To aid myself I like to be able to use multiple keywords to trigger the same workflow step.
 
Example, I have a workflow for connecting Bluetooth devices, that I trigger using `bt`
instead of just "bt" I'd like to add a few more keywords, e.g. "blue", "connect", "audio" etc.
 
I know I can duplicate the script filter opject and connect its Output to the same step—it's a poor man's workaround, but it'd be cleaner and better to allow multiple keywords, such as this:

 

This lagginess will be down to the number of connections (bezier curves) being calculated for this complex workflow, and it is something which is fixable with caching and various other tricks. Having said that, this is something I won't be fixing for now as I intend to overhaul the workflow editor in a future major release, at which point, these performance issues will naturally be addressed.
 
Alfred only draws things which are visible within the viewport, so you'll notice even with very large workflows, if there isn't a mash of long bezier curves going into a single object (like in the Spotify one), the scrolling performance is normal.