Update for Big Sur/Monterey. Supports Apple Silicon.

[adwaraki]

1. Updated battery details for Big Sur and later.

2. ManufactureDate is now calculated differently.

3. Additionally, calculating health and percentage remaining is more precise using AppleRawMaxCapacity and AppleRawCurrentCapacity, than using the regular CurrentCapacity and MaxCapacity.

[adwaraki]

I have updated the shell script for the latest macOS release. Please look through it and let me know if you need any more changes.

[adwaraki]

[xilopaint]

In my opinion this PR should not be merged with the exception of the use of AppleRawMaxCapacity and AppleRawCurrentCapacity. It writes an unnecessary info.txt file, introduces a lot of shellcheck issues and adds a new inconsistent icon set (health, trackpad and serial icons are not consistent with the rest).

Also, the Python command can lead to a total of nine 9 dots instead of the expected 10.

[adwaraki]

I just maintained what the original author had with writing to info.txt and pulling the information from there, rather than querying ioreg repetitively. I could re-write this whole thing essentially in Python3, making it a completely new workflow, but I thought the issue at hand was to get this working correctly?

Additionally, I am not sure where the original icon set was obtained from, since they appear to be part of a set. I tried to match most of it, but I could not find trackpad gradient icons very readily. I am open to suggestions. I thought they looked nicer. If you have any suggestions for icons sets, I will look them up.

Could you elaborate on the shell-check issues? I don't see what I have done differently than the original code and there were no comments about shell-check issues there? It is my first time contributing to something, so I am more than happy to learn. :)

[xilopaint]

I just maintained what the original author had with writing to info.txt and pulling the information from there, rather than querying ioreg repetitively.

The original method invokes ioreg a single time and assigns its value to the INFO variable. There's no performance gain in writing a file, besides of the fact that writing files to the workflow directory is not good practice. For volatile data you should use the Alfred environment variable for the cache folder.

Additionally, I am not sure where the original icon set was obtained from, since they appear to be part of a set. I tried to match most of it, but I could not find trackpad gradient icons very readily. I am open to suggestions. I thought they looked nicer. If you have any suggestions for icons sets, I will look them up.

I think your icon set will look good if you manage to get a complete consistent scheme. Btw, your last commit message mentions a trackpad icon but you haven't added it.

Could you elaborate on the shell-check issues? I don't see what I have done differently than the original code and there were no comments about shell-check issues there? It is my first time contributing to something, so I am more than happy to learn. :)

ShellCheck is a linter for shell scripts. Please, make sure your workflow is ShellCheck compliant before submitting a PR.

Also, you need to update info.plist with the new workflow version number. You can do it by changing the version in the workflow editor.

Lastly, after updating README with the new image of the workflow I recommend you to remove the Battery.alfredworkflow file from the repository. It's an unnecessary binary that I should had deleted in my last PR. The workflow file should be generated by the author and uploaded in a new release tag.

[xilopaint]

Why are you adding the Alfred-Worklow library to the repo?

[adwaraki]

The original method invokes ioreg a single time and assigns its value to the INFO variable. There's no performance gain in writing a file, besides of the fact that writing files to the workflow directory is not good practice. For volatile data you should use the Alfred environment variable for the cache folder.

This is very weird. I see the code now and for some reason, when I forked and imported it, the text file was being written to. I did wonder the same when I was modifying things, but then left it to the original author's judgment. Guess I had the older version stashed away somewhere and both interfered with each other when I was testing it in my synced folder. I will fix it accordingly. Now what you are saying makes more sense. Note to self: be more careful of your dev environment in the future.

I think your icon set will look good if you manage to get a complete consistent scheme. Btw, your last commit message mentions a trackpad icon but you haven't added it.

Apologies. I could not find a trackpad icon that matches the scheme. For now, I have re-used the trackpad icon from the regular icon set. It is slightly out of place, but much better than what was present before I feel. I will copy the png from the other directory into this one too.

Could you elaborate on the shell-check issues? I don't see what I have done differently than the original code and there were no comments about shell-check issues there? It is my first time contributing to something, so I am more than happy to learn. :)

I was not aware that it had to be shell-check compliant before submitted things. My first PR, learning curve. :)

Also, you need to update info.plist with the new workflow version number. You can do it by changing the version in the workflow editor.

Will do.

Lastly, after updating README with the new image of the workflow I recommend you to remove the Battery.alfredworkflow file from the repository. It's an unnecessary binary that I should had deleted in my last PR. The workflow file should be generated by the author and uploaded in a new release tag.

Understood. By the way, I need some clarification about the whole contributing process, in general. What I am doing currently is forking and cloning locally, making changes, packaging using AWP and then importing it into Alfred to test and debug. After all this is done, I commit and push and initiate the PR. It appears to me that your last set of comments don't fall into my workflow (or I am doing it wrong in some manner), since you indicate modifying something in the workflow editor and removing the bundle. Could you please elaborate on what I need to change in my workflow?

P.S: Thanks for all the inputs by the way.

[adwaraki]

ShellCheck is a linter for shell scripts. Please, make sure your workflow is ShellCheck compliant before submitting a PR.

I now see what you mean. I was totally not aware of this. I am going to fix all these issues and re-submit a commit in a while.

[xilopaint]

Please, remove the Alfred-Workflow library from your PR. It looks unused and this is not a Python workflow.

[xilopaint]

I now see what you mean. I was totally not aware of this. I am going to fix all these issues and re-submit a commit in a while.

I think you built your PR using an old version of the workflow. Please, use the latest version and just add the necessary code. It will keep you from reintroducing issues that are already fixed.

[xilopaint]

Another thing you have to look into is battery age. It's not working in your PR, at least on my Mac (intel processor). It can be a bit challenging as ManufactureDate was removed from the output as of Big Sur. Currently, the age can be determined from the serial number through this method.

[adwaraki]

Another thing you have to look into is battery age. It's not working in your PR, at least on my Mac (intel processor). It can be a bit challenging as ManufactureDate was removed from the output as of Big Sur. Currently, the age can be determined from the serial number through this method.

Actually the battery age is working, to the best of my knowledge. That is the code that iStatMenus uses to calculate battery age precisely. Got it from the author. Also, the question you referenced is another way of doing it. ManufactureDate is still present in the ioreg output. The serial number method won't work if Apple randomizes the serial. It will for now though.

I need to test it in an Intel MBP though.

[xilopaint]

I need to test it in an Intel MBP though.

Now I see I get an error in the Python code:

[21:48:04.880] STDERR: Battery[[Script Filter](alfredpreferences:workflows%3Eworkflow%3Euser.workflow.E0DD4111-8365-4A51-A763-EE1B42D93F71%3EFC5EB146-FA11-4E33-8456-F60EA94E7EEE)] Traceback (most recent call last):
  File "<string>", line 1, in <module>
ValueError: month must be in 1..12

[adwaraki]

@xilopaint I tested this on an Intel MBP. The age does not calculate because "ManufactureDate" is not present on Intel laptops, which is strange. In any case, I am working on a potential fix, or even re-writing this entire thing in Python because bash does not allow for the flexibility in programming. Let me see what I can come up with and we can go from there.

[xilopaint]

@xilopaint I tested this on an Intel MBP. The age does not calculate because "ManufactureDate" is not present on Intel laptops, which is strange. In any case, I am working on a potential fix, or even re-writing this entire thing in Python because bash does not allow for the flexibility in programming. Let me see what I can come up with and we can go from there.

Dude, you are not the maintainer of this repo. You cannot decide by yourself to "rewrite the entire thing" without the permission of the author in some language you don't even know if he's familiar with.

Btw, the only Python code of your PR was written two times and both don't work.

Your last attempt gives me this output:

All the circles are wrongly filled. You probably should be using something like this:

CELLS=$(/usr/bin/python3 -c "f='●'*(round($CHARGE/10)) + '○'*(round(10-$CHARGE/10)); print(f)")

So you get this output with eight filled circles:

[adwaraki]

Dude, I understand I can't re-write his contribution. If I do re-write it in Python and get it working, I'll make it "my" repo and make it a different workflow. I just put in that comment because you were looking at the fix for this code and wanted to let you know that I'm looking at other options too. The author himself acknowledged somewhere in the Apple Silicon bug comments that scraping from ioreg using the script probably wasn't the best approach (FYI<#11 (comment)>). So yeah, I know. I'll fix the Python piece for this and leave it at that. All the other shell issues have been fixed AFAIK. Sent from some sort or a mobile device with an autocorrect function that has a mind of its own.

…

________________________________ From: Arthur Pinheiro ***@***.***> Sent: Saturday, May 7, 2022 2:49:41 PM To: BenziAhamed/alfred-battery ***@***.***> Cc: adwaraki ***@***.***>; Author ***@***.***> Subject: Re: [BenziAhamed/alfred-battery] Update for Big Sur/Monterey. Supports Apple Silicon. (PR #12) @xilopaint<https://github.com/xilopaint> I tested this on an Intel MBP. The age does not calculate because "ManufactureDate" is not present on Intel laptops, which is strange. In any case, I am working on a potential fix, or even re-writing this entire thing in Python because bash does not allow for the flexibility in programming. Let me see what I can come up with and we can go from there. Dude, you are not the maintainer of this repo. You cannot decide by yourself to "rewrite the entire thing" without the permission of the author in some language you don't even know if he's familiar with. Btw, the only Python code of your PR was written two times and both don't work. Your last attempts gives me this output: [Screen Shot 2022-05-07 at 16 41 18]<https://user-images.githubusercontent.com/11052366/167269397-43659f06-f6fb-4c14-8c39-e2f49c57ffdb.png> All the circles are wrongly filled. You probably should be using something like this: CELLS=$(/usr/bin/python3 -c "f='●'*(round($CHARGE/10)) + '○'*(round(10-$CHARGE/10)); print(f)") So you get this output with eight circles filled: [Screen Shot 2022-05-07 at 16 46 57]<https://user-images.githubusercontent.com/11052366/167269543-ac4e2665-b40e-4e90-ac8d-5b990f7ee127.png> — Reply to this email directly, view it on GitHub<#12 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AA2ZYWQPPT3UM5EFKH5QNB3VI3CNLANCNFSM5VG2RVUA>. You are receiving this because you authored the thread.Message ID: ***@***.***>

[xilopaint]

I just put in that comment because you were looking at the fix for this code and wanted to let you know that I'm looking at other options too.

Actually my participation in this thread aims to avoid a bad PR being merged for a workflow that I use. I didn't try to fix the M1 bug because I don't have a M1 machine.

The author himself acknowledged somewhere in the Apple Silicon bug comments that scraping from ioreg using the script probably wasn't the best approach (FYI<#11 (comment)>).

He talked about scraping from ioreg and not about the language. You won't change the approach if you just use another language to read the ioreg output.

All the other shell issues have been fixed AFAIK.

Not true. You've broken the workflow for me with your change in the DESIGN_CAPACITY assignment. I only managed to get those screenshots because I reverted your change. Also, your change in the SERIAL assignment gives no output for me while the old code works fine.

[adwaraki]

Actually my participation on this thread aims to avoid a bad PR being merged for a workflow that I use. I didn't try to fix the M1 bug because I don't have a M1 machine.

And my involvement is to get a workflow I use working on an M1 machine. The end goals are the same.

He talked about scraping from ioreg and not about the language. You won't change the approach if you just use another language to read the ioreg output.

Yes, you are right. Since it was a bash script, mentally, I conflated "scraping from ioreg" and "scraping from ioreg using bash". But the point of using a different language still stands, since many changes that break the script are due to ioreg's output moving around, and using awk to extract that information. This includes the "DesignCapacity" issue that you are talking about, because the array index on M1s and Intel-based machines are different. The script would need to include a section to extract information based on chipset. I am sure it can be done in bash too, and I was going to look into doing that. The issue is, if I am going down that route of programming, as opposed to scripting something, I might as well re-write it in Python, since it is going to be much more maintainable. There is a marked difference between doing an awk -F "," '{"%s", printf $45}' and hoping the $45 does not change, as compared to doing a dict['DesignCapacity'] extraction in Python, which basically would solve the dependency on the chipset issue.

[BenziAhamed]

Thanks @adwaraki for putting in the effort to raise this PR, and @xilopaint for the engaging review.

I'll close this PR because

• @adwaraki has already forked this workflow to create Alfred4-BatteryWorkFlow
• this PR introduces too many changes that I do not want to maintain (not that this is getting a lot of maintenance per se). Forking is a good approach.

PS: As for the original icons - I created those myself using Sketch a long long time ago 🙂