gandalfsaxe

17 minutes ago, vitor said:

 

It seems you have misunderstood the solution @Andrew is investigating of doing the conversion to PNG on paste. So you wouldn’t send the TIFF, that would be used as the source of truth for the image.

 

It’s not just about energy usage: stability, accuracy, predictability, performance, and the specifics of macOS’ inner workings also matter. As explained above, a conversion is always necessary and converting images on copy is worse on every one of those metrics than converting it on paste. Either solution addresses your request, since pasting is where it matters. So if both options solve the issue and one of them is superior is most regards, that’s the one to pursue.

That's good. That would be an even more attractive solution, provided that the conversion is low-latency enough.

21 minutes ago, dserodio said:

 

There are still many users (like myself) on Intel Macs, and an app like Alfred should absolutely not waste resources.

Sure. It should be an option, and I don't have all the information to decide which should be the default (it could be the conservative option of keeping it as TIFF). Intuitively I just think it's inconveniencing more users at this point to be sending huge TIFFs around than the relatively small energy footprint of doing TIFF to PNG conversion (even on Intel macs).

On 2/20/2023 at 4:19 PM, Andrew said:

Before I provide a bit more info, please trust that in creating Alfred, I have an intimate understanding of macOS performance, and the focus areas to prevent load on your system. There is only so much of this I can impart casually on a forum.

 

 

In asking this, I request you re-read my paragraph on raw vs promised data.

 

Internally, the Screenshot app will be dealing with raw TIFF data. It provides TIFF data and PNG data types in the clipboard, but to prevent load on your system, the PNG type will be promised. This means that the conversion to PNG happens when an app requests to USE the data, not at the point of capturing. This deferment is a magical feature of macOS which helps with the snappy nature and lower load.

 

When you paste the screenshot into e.g. Messages, messages will prefer the PNG data (as that's better to send over a network), so it asks the pasteboard for the PNG promised data, and internally, this conversion happens at that point in time.

 

If Alfred were to ask for every PNG promise when it sees it in the clipboard (from any app), then this conversion to PNG is forced for every single image copied to the clipboard, essentially undoing the magic work Apple put in place with promised data in the first place, and ultimately leading to a higher load on your system.

 

TLDR: By making Alfred work with the raw TIFF data, this is zero load on your system. Adding the option to convert to PNG on use means you'll get the conversion happening at the point of use, just like the Screenshot app will be doing.

 

Cheers,

Andrew

Hey Andrew, thanks for the detailed explanation. Now it makes much more sense to me.

I hope you can explore some PNG conversion feature for those of us who prefer *always* PNG (and then can revert to native copy-paste function in those rare instances where a PNG is not accepted by the application). With the advent of the Apple Silicon chips in Mac, I would not be worried about the extra system load by doing image conversion of screenshots. I truly appreciate your concern for system load and performance in general, as this is surely one of the reason why Alfred is so snappy in general. That's a very good attitude! In this case I'd just vastly prefer Alfred to be converting the screenshots to PNG immediately upon saving them rather than send huge image files everywhere. I've begun to use the Alfred clipboard less for images since this discovery as it literally means the difference between an image loading in 1 second or 5 seconds in Slack in many cases etc.

In any case, it was good to understand the technical background for this issue. 

Can you elaborate on what this means versus just pasting the screenshot directly with ⌘V not using Alfred? Can you give one or two application or contexts where it doesn't work as examples?

What doesn't make sense about this to me is that PNG has long been the default file format for screen captures in macOS; why is this not an issue for the standard screen capture (via ⇧⌘4+control) if it's an issue for Alfred?

Not saying I don't believe you btw!  Just that I don't understand why this is a problem for Alfred and not for Screenshot.app if the format of PNG is the issue and the system default is PNG and have been so for years 🤔

On 2/17/2023 at 3:01 PM, Andrew said:

I internally implemented prioritising png data over tiff if it is available in the clipboard, and this turns out to be unreliable across a range of apps. In my testing, which the macOS screenshot to clipboard worked flawlessly, some design apps copied bizarre and large png representations when the "tried and tested" tiff was exactly what was expected.

 

I am now investigating adding an option in the clipboard preferences to convert history images to png on pasting from Alfred's clipboard history.

Why is a conversion needed at all? The original screen capture is png if you paste it directly from the clipboard. Why can't Alfred just access and use this? And just store these in the history?

If I take a screenshot to the clipboard (e.g. using ⇧⌘4, then taking a screenshot to the clipboard by holding control), then:

1. Paste it normally —> PNG of reasonable file size.

2. Paste it via Alfred's Clipboard History —> TIFF of giant file size.

Why can't it just be the PNG as when you paste it directly?

It's easy to reproduce by pasting via the two methods into a note in Apple Notes and then seeing the files:

On 2/16/2022 at 9:40 PM, christophehad said:

Using the Cmd+ O shortcut opens the folder in the same Finder window as search

Ok good to know! I haven't had this issue since I changed the setting System Preferences -> General -> Prefer Tabs: [Always] (default: in full screen), which I prefer in all contexts anyways. But thanks for the tip!

21 minutes ago, gingerbeardman said:

Something is wrong if it is taking 30 to 120 seconds for you. 

 

For me it generally (depending on the complexity of the query) takes a few seconds, and one of those is a wait before we actually begin the query.

 

That said, things (Apple's server?) never used to be this slow, so I think it's good to have faster options.

 

So I've uploaded 2.3 which defaults to skipping thumbail images.

https://www.gingerbeardman.com/alfred/

 

The keywords for song/album with thumbail images are still there, but renamed as isong and ialbum, for people who wish to use them.

 

Thanks for the suggestion!

 

 

Ah I was on VPN before, now it's only 10s, and without thumbnails 3s. I still prefer without thumbnails though. Thanks

1 minute ago, gingerbeardman said:

Yes, you're missing folders to store the thumbnail images.

 

See my previous message.

Fair enough 😉

I made the folder and it works now. Only caveat is that it takes a long time (30 - 120 s) every time I search for a new song, so it only really works with songs you've already searched for in practice. I'm just thinking, is it then really worth it to cache all those thumbnails? Why not just do like with artist, no thumbnails? 1) It's instant and 2) Works out of the box without need to manually create a new folder in `~/Library/Cache`

7 minutes ago, gingerbeardman said:

How long are you waiting?

 

Queries take 5 to 15 seconds for me.

 

I've just re-uploaded the version I have here, just in case.

 

If it's not working after re-downloading one more time, then we'll have to debug:

1. view the workflow in Alfred
2. click the bug icon
3. pop up alfred bar and do a query, eg. song hyperballad 
4. copy the debug output from main Alfred window to a pastebin/gist
5. paste a link to it here

I see this output: https://pastebin.com/raw/yAzL8WRb

 

 

I pressed "Paste" on pastebin, but then the text just vanished and I couldn't see any link. I'm not logged in. So you'll get it here.

This is the output. Have just replaced my real username with [USERNAME]:

```

[01:06:16.161] Logging Started...

[01:06:26.188] Search Apple Music[Script Filter] Queuing argument 'hyperballad'

[01:06:28.355] Search Apple Music[Script Filter] Script with argv '(null)' finished

[01:06:28.356] ERROR: Search Apple Music[Script Filter] Code 1: Traceback (most recent call last):

  File "song.py", line 48, in <module>

    filepath = os.path.join(alfred.work(True), str(e['trackId'])+".png")

  File "/Users/[USER]/Documents/-sync/Alfred/Alfred.alfredpreferences/workflows/user.workflow.B27FA796-BE33-4980-B971-E4C970639005/alfred.py", line 77, in work

    return _create(os.path.join(os.path.expanduser(path), bundleid))

  File "/Users/[USER]/Documents/-sync/Alfred/Alfred.alfredpreferences/workflows/user.workflow.B27FA796-BE33-4980-B971-E4C970639005/alfred.py", line 90, in _create

    os.mkdir(path)

OSError: [Errno 2] No such file or directory: '/Users/[USER]/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow Data/com.gingerbeardman.alfredv3.applemusic'

```

9 minutes ago, gingerbeardman said:

That's not my file, that's a modification by somebody else.

 

My original files are here: https://www.gingerbeardman.com/alfred/

 

I just fixed it before my last message.

 

Also, make sure you search for reasonable terms:

• song taylor, generates an error somewhere at Apple for whatever reason (probably too many results?)
• song shake it off, returns good results
• song taylor shake, also good

Ah my bad.. unfortunately still only artist work for me. Downloaded from https://www.gingerbeardman.com/alfred/Search Apple Music.alfredworkflow

1 minute ago, gingerbeardman said:

There was a problem with song, please re-download my 2.1 to fix that.

 

All now work for me.

 

 

I downloaded the workflow from link https://drive.google.com/file/d/1XmXl5nq9Qn8Lvo7Zv1ESyCmaRDhyh-2u/view but I'm still seeing the same behavior. I just re-downloaded to make sure, no dice. When did you fix it? Latest change in the workflow files were April 21st 2020.

On 4/21/2020 at 6:15 PM, Macchio said:

Stumbled over this post and ran into the same issues that other users have mentioned when running macOS Catalina 10.15.

 

After running the debug I saw a duplicate error showing a missing directory, so as an experiment, I ran the following in Terminal:

 

mkdir ~/Library/Caches/com.runningwithcrayons.Alfred-3/ && mkdir ~/Library/Caches/com.runningwithcrayons.Alfred-3/Workflow\ Data/

This created the directory where the python script returns album thumbnails from the Album & Song search commands.

 

Additionally since Catalina replaces iTunes.app with Music.app, I went through the three python scripts and archived some of the URL scheme that Music doesn't seem to need. I bumped up the workflow version to 2.1 for tracking purposes.

 

Search Apple Music.alfredworkflow [Google Drive]

 

Thanks to all the creators who have put this together!

 

Pro-Tip: Update Line 19/20 in the artist, album, and song python scripts to your country code to improve search results with images.

Artist work for me, album and song doesn't 🤔 Any suggestions?

2 hours ago, deanishe said:

IIRC, you only need to write application "Blah Blah" in a script and AppleScript will try to run the application  (i.e. it doesn't matter if your code even takes that branch—AppleScript will still "connect" to the app). And you’ll get the “Where is Blah Blah?” dialog if it isn’t installed.

 

I believe the best solution is to rewrite in JXA, where you can use Application(variable), so you are only creating application instances for the apps you actually want to use. AppleScript doesn’t let you pass a variable to tell application.

 

So no easy solution in AppleScript? It would be easiest if there was a solution here because the whole workflow is already in AppleScript.

The guy did mention in the issue conversion that Firefox doesn't support Apple Script but apparently he found a solution and added a bunch of other browsers when he was at it.

https://github.com/AndrewC-B/alfred-open-in-chrome/issues/1

Gave this a shot, but Apple Script is too damn obscure. The author seems too busy to fix it, and I gave it a few hours myself.

It's basically just a workflow that opens a browser tap in another browser. The problem is, if the user doesn't have the exact list browsers installed, that is supported in the workflow, a dialog box always comes up when invoking the workflow.

If anyone here is proficient in AppleScript expert you could probably fix it in a couple of minutes

PS: If anyone could also add an optional "close tab in old browser", that's be awesome.

Google has recently added an extra step to "I Feel Lucky" searches so you have to press an extra button, thereby defeating the purpose of the feature. Example:

Anyone got "I Feel Lucky" Google search working again, so you can do it in one step? I'm not sure there is a working workaround. But if there is now or in the future, I hope someone will share it here.

I would find it useful to be able to point to external locations for Alfred snippet files, for example to be able to separate personal/work snippets, where work snippets could be available only on a work machine.

Hi,

I'd like to see better grid snapping of workflows. Currently they snap to a very fine grid of 10 px (I think). I don't need that granularity, and would like them to snap to a much larger grid, like on the Windows or Mac Desktop (if you enable snap to grid). Over time, I've noticed that I spend needless time on fine-aligning stuff, when I really don't need that fine granularity. As per macOS conventions, you should still be able to get the current 10x fine grid when holding down ⌘ or something like that.

@vitor Sure.

As an example, I have an snippet with:

Name: Happy - Owl

Keyword: !owl

Snippet: ⊙▽⊙

Pressing the Viewer Hotkey:

It tells the keyword "!owl" in the lower right portion of the screen.

If instead I invoke the "Snippet keyword" (which I've set to "s"), I get:

I.e. no keyword "!owl", just the title and content of the snippet. It would be useful it this would show the keyword as well, either by default or by holding a modifier key.

Hi,

I sometimes forget the keyword for a snippet, but when I search for it with the snippet keyword (default is "snippet" I think), it only shows the snippet in a one-liner, not the keyword, so I never learn the keyword unless I look it up in Alfred Preferences or invoke the Snippet Viewer Hotkey. I'd love to be able to see the snippet keyword if I held in e.g. ⌘ key.

PS: This is largely resolved by using the "Snippet Viewer Hotkey" instead of "Snippet Keyword", but I'd be nice to have both places.

I just realized that I do this by adding a symlink to e.g. /Applications, and then just pointing Alfred to that. Problem solved

I'll go with this solution, but if anyone happens to know the answer to my original question, feel free to leave it here for future reference 😊

Hi,

Is it possible to press a specified hotkey, and then have Alfred launch/hide app1, app2 or app3 depending on whether the hostname on my current machine is machine1, machine2 or machine3?

The use case would be to use the same hotkey on all my computers for opening different versions of portable Visual Studio Code.

19 hours ago, Subject22 said:

 

Hey, finally got around to this. Obviously feel free to fork and/or submit a pull request. I will also endeavour to keep the first post in sync with the GitHub repo.

 

https://github.com/AndrewC-B/alfred-open-in-chrome

Great 👍

Would like to see this too.

9 minutes ago, vitor said:

 

What all of those have in common is that you’re not just pressing ⌥, which is what I commented on. You’re arguing against a point I didn’t make.

Ah I think we both spoke past each other. I always meant I wanted to invoke Alfred with only either Left Opt + Space or Right Opt + Space, not only Left Opt or Right opt. Edited for clarification.