in progress brightness workflow

[Alan He]

keyword to brightness up or down

 

1. I am the author of the workflow

2. https://github.com/alanhg/alfred-workflows/tree/master/brightness-control

3. requirement: brew install brightness

 

Edited March 20 by Alan He

[Alan He]

@vitor Looking forward to your review.

[vitor]

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)

 

[Alan He]

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 '

 

 

 

Edited March 22 by Alan He

[vitor]

That tool is a no-go until they update it.

[pixelgeek]

Wow. Why won't they release a new binary?

[vitor]

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.

[Alan He]

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

 

I solved it by hosting both the x86 and arm versions directly in the workflow, so it doesn't rely on brew anymore. Fork submission is theoretically possible, but the issue is that there is still review, after all it's just a fork and not a second development.

 

 

1. Can you see if this is ok? Currently, the downside is that an x86 user downloading the workflow contains unnecessary arm program files, but the size overhead is still acceptable for now. 2. I don't have an M1 Mac on hand to test, I can only rely on user feedback from the repo that it is usable.

 

I have updated the workflow and dropped the brew dependency.

 

 

 

 

 

[vitor]

2 hours ago, Alan He said:

I solved it by hosting both the x86 and arm versions directly in the workflow

They’re not signed and notarised so it doesn’t address the problem. Those won’t even run on user’s machines so your code will continue to fail, just with a different reason.

 

The point of the requirement is to ensure a degree of security and trust. All of this is covered in the pinned post and we talked about it before too.

 

Edited Saturday at 01:39 PM by vitor