Alan He

6 hours ago, vitor said:

Please check with 13.3.

Sorry to update so late, mainly I am here at night.

MacBook Pro (16-inch, 2019)+Ventura 13.3+Alfred 5.1 b2129 pre-release, drag from finder does not work again.

but drag from Alfred's search result works,

2 hours ago, Andrew said:

Could you please try adding Safari via the + button in the Alfred 5.1 b2129 pre-release?

 

Also, if you could check dragging in again in the Ventura 13.3 release, that would also be appreciated.

MacBook Pro (16-inch, 2019)+Ventura 13.2.1+Alfred 5.1 b2129 pre-release, drag does not work again.     + button ok.

Some friends have encountered a situation where locking the screen using a hotkey ctrl+cmd+q works, but using the "lock" command does not work.

1 hour ago, vitor said:

You don’t need to ping me every time. I look at every post in this subforum and will get to everything. There are others also waiting, please be patient.

ok, got it.

Quote

Easy to open Chrome with selected profile.

 

Usage

type chromeprofile

idea from https://github.com/Wit4r7/AlfredAutomations. Thanks Wit4r7

Requirement

/usr/bin/python3 installed

I am the author of the workflow.

https://github.com/alanhg/alfred-workflows/tree/master/open-chrome-profile

Screenshot

@vitor

hello, look forward to review it.

On 3/22/2023 at 9:18 PM, vitor said:

No idea. At first glance it’s weird because they seem to still be quite active on GitHub and technically they don’t even need to make a new binary, just tag a new release (because Homebrew then takes care of the compilation). So theoretically this could be solved from a phone in under a minute.

Maybe they missed that thread or no longer want to work on the project. It would be nice to have the update but ultimately it’s an open-source project released for free in (presumably) the author’s spare time, so it’s their choice.

Someone could fork it and then submit the fork to Homebrew, though it would require people using that and there are still other open issues.

@vitor

19 hours ago, vitor said:

There are two Call External Trigger not doing anything. And the workflow outright fails for me:

 

brightness: failed to get brightness of display 0x1 (error -536870201)

Parse error: bad token
    <stdin>:1

brightness: failed to set brightness of display 0x1 (error -536870201)

 

1. I have deleted unused call external trigger.

2. can you share me output on the terminal and system info?

command:  brightness -l | grep -o -E 'brightness.*([0-9]+(\.[0-9]+)?)'| tr -d 'brightness '

5 minutes ago, vitor said:

 

In Ventura, sqlite3 is at 3.39.5. What I need to know is which macOS version is the minimum. Presumably you made the change because the workflow failed in a specific macOS version. Which was it?

My understanding is to follow the sqlite3 version, but I found through my own testing that the version built into Monterey is below this limit. Ventura is v3.39

@vitor Looking forward to your review.

20 hours ago, vitor said:

@Alan He Your latest update to this workflow cannot go in the Gallery. The pinned post specifies that workflows cannot download extra software on their own, including with brew install.

If you have an extra dependency, ask. The workflow already depends on node so it’s no trouble to add an extra on the Gallery.

But the change won’t work either way. Homebrew’s SQLite is keg-only, meaning it’s not symlinked and won’t take precedence.

If there is a version of macOS with a SQLite that is too old, let me know what that is and I can add that as a dependency.

1. I have updated the workflow, and dropped brew install script.

2. requirement:  sqlite3 >=v3.33.0

keyword to brightness up or down

type briup or bridown

thanks https://github.com/nriley/brightness

Requirement

brew install brightness

On 3/7/2023 at 2:53 AM, vitor said:

The av Script Filter is still using /usr/local/bin/node. Once that’s fixed, it should be good to add.

 

fixed, thank you.

look forward to being ok.

@vitor

On 2/28/2023 at 6:17 AM, vitor said:

The node_modules are stopping this from being added. Specifically, there’s a node_modules/sqlite3/lib/binding/napi-v3-darwin-x64/node_sqlite3.node unsigned binary which is only compiled for Intel. That means it won’t run on users machines as is.

I have updated the workflow and am now using the built-in SQLite on Mac. The node-sqlite3 package has been removed as a dependency.

It's enough?

thank you, I will check again.

@vitor

I have updated the workflow, and thank you.

look forward to being ok.

I don't know what needs to be done next. Or just wait for the review.

@vitor

11 hours ago, vitor said:

Thank you for the fast update. This will be live soon at https://alfred.app/workflows/alanhe/about-mac/.

 

Heads up for your other workflows that the main icon needs to be 256x256 px or larger.

 

1. what's main icon,for example. where's location?

2. the guide not show any info about main icon.

3 minutes ago, vitor said:

The keyword doesn’t matter, the code which does the updating does. What’s the purpose of the empty keyword?

ok, I understand your point.

I have update the workflow. auto-updater deleted.

thank you.

26 minutes ago, vitor said:

@Alan He Thank you for your patience. There’s one thing missing, removing the auto-updater. Gallery workflows are updatable from within Alfred itself, and as part of that a prerequisite for inclusion is that workflows not auto-update themselves. This is to avoid a confusing interaction of crossed updates and for security reasons, as Gallery workflows go through a number of checks.

 

Once you make a new release without the auto-updater, this will go in.

I set keyword empty.  as you say, I have to delete the keyword object?

just debug the alfred on that computer.

see output and paste it. like this.

2 hours ago, Pajerow said:

 

In my case, this setting change made the problem less likely.

yes, so just recommend.

I think not need any workflow.

just use trigger universal action - open with and select zip app, for example keka.

11 hours ago, Vero said:

@Alan He Thanks for the additional details. 

 

First, could you please open your Dropbox preferences and ensure the folder you're using for Alfred's preferences is set to always be available locally? If it's possible for Dropbox to make the preferences online-only, Alfred will lose access to them, resulting in unexpected behaviour.

 

Once you've done this and Dropbox shows that the files are stored locally, try changing your note again and seeing if the issue is resolved.

 

If it isn't, you can temporarily change your sync location (e.g. create a new "Alfred" folder in your user directory) so that the sync service is taken out of the equation for now. Are you now able to save changes?

 

If you are now able to save changes, I would suggest creating a new folder in Dropbox, set it to be always available offline first, then set this as your sync folder. 

 

Let me know how you get on

 

1. I restart dropbox app and it works.

2. I think you are right, the root cause is sync service.

3. recommend set dropbox's upload rate is don't limit