This project has actually been in development for over a year. It already went through a private beta testing phase, and now is in public beta. I posted about it on other forums a while ago, but I thought Cemetech members could find it interesting too. If there is enough interest, I may start publishing development logs here, too. For a start, it's not yet another calculator project

Clouttery, the smart, cloud-enabled battery monitor which works with every device*! (* not yet, but hopefully one day)
Website: http://clouttery.xyz/

Clouttery currently:

• Lets you know the battery levels and charging status of your devices, from a single place, even if they are miles away
  
• Stores and displays the battery history for those devices
  
• Optionally notifies you whenever the battery level of a device goes below or above a certain threshold (when discharging/charging, respectively)
  
• Calculates statistics for the batteries, such as charge cycles and calibration count
  
• Analyses the battery history and lets you know about potentially damaging usage patterns
  

It's currently available for Windows and Android, has a Chrome extension, and a web console. The Windows client provides some extra perks, like the ability to show battery percentage and remaining time in the system tray, as well as computation of the remaining time on computers where Windows does not provide it. The Android app also provides battery life estimates, separate from those calculated by certain Android versions.

Clients for more operating systems and platforms are planned; the intention is to support everything, from laptops to embedded devices ("IoT", if you prefer fancy terms), and provide a good user experience across all platforms. The idea is to integrate well with each platform, providing a UI that is recognizable across all of them, and yet doesn't look too far off from the platform's design guidelines.

Some screenshots:
(if some of the images look "zoomed in", it's because my computer has DPI scaling set to 125%. It's also proof that the Windows client supports DPI scaling! )

Web interface:
http://s.lowendshare.com/7/1471363952.648.cl1.png
http://s.lowendshare.com/7/1471363978.61.cl2.png

Windows client:
http://s.lowendshare.com/1/1456099763.578.Untitled.png

Android client:
http://clouttery.xyz/static/img/scrandroid.png

Chrome extension:
http://s.lowendshare.com/7/1471364640.40.clchcem.png

In the future, Clouttery shall:

• Learn about the battery consumption habits of your gadgets and learn/be taught about your needs, so it can plan ahead of you ("If you want to have your phone usable by 6 pm, you need to stop playing games now. Oh, and enable the battery saver")
  
• Detect and warn about malfunctioning/dead batteries
  
• Deal with multiple batteries per device (especially important on devices with multiple detachable batteries, like some convertible laptops)
  
• Deal with dumb devices that have a (mostly) constant battery drain over time, such as clocks and smoke detectors, reminding you to change their batteries - this would require having the user tell Clouttery whenever batteries are changed
  
• ...and more stuff that's a secret for now (even managing to implement all of the above would be quite a feat)
  

Clouttery currently serves well the following kinds of users:

• Users who own many devices with Internet access (like a bunch of Android devices for software testing);
  
• People who forget to charge a phone after e.g. leaving it for a couple of days on some desk (used to happen to me during holidays)
  
• Those who would like to get more detailed statistics about the batteries of their gadgets, or who generally like fancy graphs
  
• Users who just want the battery percentage on the system tray (yes, some people install it just for this).
  

Since much of the functionality revolves around storing, analyzing and synchronizing battery levels, running this service incurs some costs that I need to offset somehow. I plan to offer a free basic plan for this service, then have plans at multiple price tiers with monthly or yearly billing. The more expensive the plan, the more features it has, the more devices it supports, etc.

But the good news is, a public beta-testing program is ongoing, and everyone who joins this program, and keeps being an active user until it ends, gets free Clouttery for life! Being a beta-tester requires keeping in touch with me in order to know the latest news and install the latest updates, and of course communicate any bugs and give suggestions. The Windows client updates automatically and silently. The Android one updates through the Play Store.

Feedback is much appreciated. What you see is the result of over a year of work: I built the Clouttery server, the three clients (Windows, Android and Chrome) plus a Linux one which is, for now, unreleased due to technical difficulties, and the (secure) API to keep all these communicating. In addition, the server also needs to communicate with dotAccount and Twitter for authentication.
All this requires using multiple programming languages (Go, C#, Java and to a lesser extent PHP), UI frameworks, designing graphics for multiple resolutions and rewriting the same code multiple times. The kind of stuff that hopefully will look nice in my CV.
In all, a ton of work, but to be honest I'm a bit surprised I managed to get this far, this fast.

For now, it's all closed-source; depending on how well business goes I may open-source (some of) the clients, the server (for self-hosting), or both. Should I give up on this business-wise, I'll try to release everything under a permissive (BSD) license.

If you are interested in using Clouttery, start here: https://clouttery.xyz/signup

Wow! what a cool idea for a project! what languages is the current linux client written in?
I have just started learning some C and I am happy to contribute depending on the license.
I do have a question though, why do you choose a BSD license over something simple like the permissive and open-source MIT license? I do find the MIT license to be short, simple and easy to understand. The MIT license can be found here: https://opensource.org/licenses/MIT. It would be a great license to modify and change specifically for Clouttery.

Thanks for reading!
~doubledogdare610!

The Linux client is written in Go, and the UI uses GTK3. I chose Go because:
- It's what the server is written in (and it's served me extremely well there);
- I don't like Python very much, and to use C#/.NET that would add Mono as dependency. Java would require a Java runtime. I'd like to avoid external dependencies, including runtimes like Mono and Java, as much as possible;
- That leaves us with a language like C or C++ as the option, which compile to native binaries. But I didn't feel like writing the API client in C or C++. Since Go produces static binaries, it seemed the best choice (also, it would be very easy to write the API client in it, as the API server is written in it too).

However:
- There are no good UI libraries for Go. I finally found some GTK bindings that would work ( https://github.com/gotk3/gotk3 ). This would add GTK as a dependency, but since most distros already have this it wouldn't be much of a problem.
- I'd like to display battery history graphs on the client (the Windows and Android clients can do it), but it turns out there is no good component to provide interactive graphs in a GTK UI.
- I ended up resorting to using a WebKit view (using webkitgtk) and graphs in JavaScript (like I was already doing in the website). This adds another dependency...

It mostly works, but I'm having a problem where the UI will just randomly lock up. It's not the whole program, it's apparently just one of the threads/goroutines (the tray context menu keeps working, and I can open new windows), but so far I have been unable to get to the root of the problem. I may actually end up switching to a different software stack for the Linux client. For now, in terms of clients, I have decided to focus on completing the Chrome one (as that will work in Linux too). Perhaps I'll redesign the Linux client so that it becomes a CLI program/daemon instead of having a GUI. This would actually be better suited for things like Raspberry Pis which are often running headless...

I mentioned the BSD license as an example of a permissive license (i.e. something that is not GNU GPL). The specific license I would select would depend on the exact circumstances under which the code is released. For example, if I open-source some clients only and keep the server proprietary, perhaps the clients will be released under a more restrictive license than if I were to abandon the project and open-source the whole stack, perhaps even with branding included (which could be e.g. Creative Commons). In the latter case I would lean into something ultra-permissive, perhaps even more permissive than MIT (say, without the attribution clause).

To sync the battery levels though, don't both devices need to be connected to the internet? If I'm trying to conserve battery levels on a device, why would I leave it connected to the internet while I'm away from it? I like the concept for monitoring battery usage and patterns, but I don't think that using it over multiple devices serves much of a purpose (except in isolated cases).

Uh... Battery Meter Cloud Edition? I'm not really seeing the point of this, unless it's coupled with other "standard" features like location tracking, messages, etc. You put a lot of effort into this, which is great, but to be honest I'm not really sure if anyone's going to use this.

Yes, to sync the devices need to be connected to the internet. The clients will still record battery history and upload it later when they get a connection. But this isn't to be used only when you're trying to conserve battery, even because usually when that's the case you already have an eye on the battery level of said device...

Smartphones and tablets are typically always connected, at least when WiFi is available, to sync emails and messages. Clouttery opportunistically groups its activity with the activity of those apps so its impact on battery life is negligible (we are continuously testing this and more often than not, popular apps like Gmail, Pushbullet and Twitter consume more battery during standby than Clouttery). Laptops typically are connected to the internet while in use, and while they are off they don't consume much battery anyway.
Because users may have their devices configured with battery savers and the like that begin turning off radios at lower battery levels, Clouttery be default suggests a "battery low" threshold of 20%, but users may want to increase this to 30% or more if their batteries discharge fast or if they simply want to have a bigger warning window.

In the longer term, the online component of Clouttery will make predictions about battery life (clients currently make predictions about themselves, but those are not sent). Predictions will make sure you receive a notification (which may be a false positive) in scenarios like this one:
- 4 PM: Your smartphone battery gets to 40%, and all radios are off to conserve battery;
- 4:30 PM: Another device of yours goes online, and gets to know about the estimate that your smartphone battery will get to 20% by 6:30 PM. 20% is the "battery low" threshold for the smartphone;
- 6 PM: The second device goes offline too;
- 6:30 PM: The other device issues a notification saying your smartphone battery is probably low (~20%) but it can't be sure, as the smartphone has not synchronized since 4 PM.

If clients get the ability to make predictions about other devices as well, without needing to be online to do so, then the step at 4:30 PM in the example above doesn't even require the second device to go online. Also, a second device doesn't even need to exist: a notification can simply be issued by the server at 6:30 PM. That notification will then be available in the web console, and could be sent by email once Clouttery gets the ability to do so (the main reason why it doesn't yet to it is because I'm not asking users for their email address, to reduce friction. Later you'll be able to specify one in the web console).

One of the biggest unknowns right now is knowing how those predictions will be made. We can use simple math, like clients currently do to calculate their own battery life estimates. However, those can be extremely inaccurate if at some point the device starts using more or less power. I'd like to go for something more sophisticated that learns about the battery consumption habits of the user (e.g. that it always makes a one hour phone call by 3 PM, and that during the call the battery has three times the standby drain) and takes those into account.

This kind of stuff, and eventually things like the detection of broken batteries, could be done with machine learning, but for that one needs a big training set. No publicly available data set on battery levels seems to exist, so I'd need to rely on the Clouttery beta testers. And for the user-specific predictions (like those "charge by lunch time" or "daily phone call/gaming session"), the system would need to be trained on each device individually. This requires at least one month of battery history for the device, and some processing, which is why it becomes hard to give this service away for free.

If you're wondering whether people will use this, indeed they will, there's a reason why Cortana and etc. will now show notifications when your phone battery goes low. People actually like that kind of tiny helpers (and those will always be available on the free plan of Clouttery). When I began working on this, that functionality didn't exist yet. And Clouttery aims to be more cross-platform than those. Of course, for people to use it, it must be very easy to set up, which is why it is prepared to allow people to sign in with different services. The pairing aspect could be a bit easier, and I have some ideas to fix that. It also needs to support almost any platform, but certain platforms are hard: for example, iOS requires a major investment.

I should perhaps be putting more emphasis on the "battery" part and not on the "device" part. The original idea of Clouttery was to monitor "dumb" Ni-MH batteries solely based on timing (I have a number of those, and they should be recharged periodically so they don't die). The ability to take care of "dumb" stuff like those batteries is still in the works, hopefully once all of those ideas are implemented Clouttery will make more sense. But right now, I find it useful and so do a few of the beta testers, so it's not completely useless.

@gbl08ma some people (usually always the same people) will regularly criticize the worthiness of projects with baseless arguments. Whether their intentions are to discourage the author or legitimately criticize, it's generally better to take those comments with a grain of salt.

Wow gbl08ma. This is an excellent idea. In regards to the WiFi drains one's battery issue most "average" users (people who are less technical) that I have met in real life just leave it on all the time; they don't care. I know people who leave their computers on 24/7 and never even put it in standby mode. With that in mind I think that this could take off.

It seems many modern phones have WiFi usage on standby pretty well optimized, at least when the reception is not bad (because when it is, they need to transmit at higher power levels for the wireless hotspot to receive their comms - same as with cell phone towers). I know (because of Clouttery) that on mine, having the WiFi on or off makes little difference in the power consumption. It seems the biggest battery drain is the GSM modem, which naturally needs to transmit at higher power levels to reach towers that may be over 1 km away.

On laptops, Windows 10 now also collects battery usage information even for "classic" (Win32) applications, of which Clouttery is an example. Many of them including Cortana, the Windows Explorer, Slack, Skype and OneDrive appear higher on the list than Clouttery, and all of those are in the background without getting much use. I think Clouttery could use even less battery if I configured it to synchronize every 5 minutes instead of every minute. Of course, once you have Chrome open you can forget about battery life... it comes at 50% usage on my Surface

EDIT: Clouttery now lets you sign in using a Google account, in addition to Twitter and dotAccount.

One thing I'm particularly curious about is what motivated you to attack this problem in the first place. I certainly do see the value in knowing the status of all of your devices, especially if you continue to work on the problem of pattern-detection and prediction and can help people understand when they're going to need to charge their devices before they're in dire straits. Thanks in advance for explaining your motivation!

Well, the idea for this project appeared after identifying a series of "little problems" I have/was having. Then as I thought more and more about it, the more possibilities I saw.

- I was detecting odd battery depletion patterns on some of my devices and I wanted something that let me look at the battery levels over a longer period. One of these was an Android phone, but the graph shown in the battery settings just wasn't cutting it. Hence the level logging aspect of Clouttery.

- I have a relatively cheap Windows (x86) tablet, which has a not so uncommon quirk about the battery info: it won't calculate remaining time like some other devices do. Additionally, I don't like battery level icons - I much prefer seeing the percentage.
I found software that would calculate the remaining time and put it and the percentage in the tray next to the clock, and that's why the Windows client can calculate the remaining battery time independently from Windows, and display battery percentage and time remaining in a tray icon. Apparently other people like seeing the percentage too as multiple users have told me they installed Clouttery just to have this feature

- I own a bunch of old handhelds with internet connection capabilities laying around. Almost all of these are Windows Mobile 6.x devices with slowly dying Li-Ion batteries (some of the devices are over 10 years old). These batteries need to be carefully charged and discharged to avoid losing capacity, so why not make a program that helps with maintaining battery health? Months after beginning to work on this project, it finally was mature enough so I could make a Clouttery client for Windows Mobile (unpublished, as it's unfinished and because it's unlikely that anyone else still uses Windows Mobile. Is there anyone interested?). I also have a Windows Phone 7 phone, but this OS doesn't expose to apps any API for reading the battery level. So unfortunately a client is impossible.
One of these days I'll begin working on a UWP client that will work on Windows Mobile 10 devices (but I don't own any of these, at least not yet).

- Similar to the above, I have other stuff laying around that requires batteries but is not that smart, yet requires ~monthly battery changing/recharging. And lots of Ni-MH spare batteries. It would be great if Clouttery could remind me to charge those too. Although this was a big part of the original motivation for building it, Clouttery doesn't yet solve this problem of mine...

- The realization that with more and more "Internet of Things" stuff laying around, a chunk of these are set-and-forget battery powered devices that people will end up forgetting to recharge. So hopefully Clouttery can position itself as the battery monitor for that sort of stuff. It would obviously require manufacturer support... but guess what, I also have some projects ongoing on the IoT field

- Some family members would constantly let their smartphone battery go full-empty - hard times adapting from the feature-phone era where batteries lasted a week. Also, a big part of the reason why it happened is that they used their laptop way more than the phone, and would leave the phone forgotten in some corner or bag. Problem solved - now the laptop warns about the phone battery.

- As an example of Clouttery could evolve to do if it was in widespread usage: Recently, some Surface Pro 3 owners began noticing serious battery capacity degradation. People on the Surface subreddit put up a spreadsheet so others could submit information about the batteries of their devices, in order to try to identify how widespread the problem was and what models were affected. If Clouttery was popular enough, users could opt-in to this sort of information sharing, helping manufacturers or consumers' rights organizations. More interestingly, if there were easily identifiable patterns on the histogram of the broken batteries, Clouttery could warn unsuspecting owners of defective devices that their battery is beginning to show damage.

Finally, Clouttery is something new, a product that didn't exist before. I was kinda tired of making worse versions of existing web services, and this is without any doubt something that has never been done before.
Furthermore, it's the perfect project for people like me who like full-stack development: it requires developing a backend, a web frontend, clients for multiple platforms in different languages. Clouttery gave me the reason to build my first Android app (and let me discover how bad Java is, and how terrible the Android APIs are), made me go back to .NET development (to find out C# is much nicer than Java), and tremendously improved my experience with a language I like very much, Go (used on the backend and some clients). It's been a year and so far it's the side project I've enjoyed the most.

EDIT: as people on SAX have demonstrated great interest in the "open vs closed source" aspect of this project, and because I might not have been clear enough in my previous posts, the question of whether to open source Clouttery has always been more of a "when" than a "if". Yes, I want to open-source it, at least the clients, but right now doesn't feel like the right time.

I also don't think many people are interested in helping with development, as few people are interested in using it, hence why I'm not hurrying up. But please tell me if I'm wrong.

This is the stack used:
Server: Go, HTML and a bit of CSS and JS (client-side). http://ink.sapo.pt/ is the framework used for the web console; outer pages use http://purecss.io/.
Windows client: C# with winforms
Android client: typical Android app written in Java with Android Studio
Linux client: Go with GoTK for GTK bindings, a bit of HTML+JS for the graphs
Chrome client: Go (compiled to JS with GopherJS) with a bit of JS for the parts that can't be done in Go

I will volunteer to beta test the OSX client, if one is to be made, or the *nix one on OSX. In addition to that, I volunteer to test extensions made for any OSX browser.


I'd be impressed if you somehow integrate the ability to remotely charge using your system. But I'm also equally aware that's not remotely feasible yet :p

I think it's time for a development log...

I have paused work on the clients for a while to focus on the server side. In the beginning of the week I have tried to get a Clouttery client to run under Mono, to see if I can avoid the random lockup problems the Go-based client has. It would have the benefit of being able to reuse a big part of the code from the Windows client, which is written in C#. It would also have the benefit of (hopefully) working on OS X or whatever it's called now.
The core works fine (API client, devices, notifications, etc.) under Mono but UI is a big pain to get working, but not because GTK# is hard (on the opposite, it actually makes the work easy because I can use the UI designs I planned to use on the Go version).

The reason why I couldn't progress much on the Mono client front was because of something extremely silly: these days Linux desktops don't seem to agree on how to display tray icons, or if tray icons are supported at all, and if you don't believe just do some research about libappindicator (not deprecated but doesn't work on some systems - oh, and did I mention the only Mono bindings I could find are broken?) and GtkStatusIcon (deprecated, works on some systems but not mine - the Mono bindings seem to work fine, but KDE won't show an icon). GtkStatusIcon used to work on my old Linux Mint install with KDE 4 install but it won't work on my new Arch Linux install with KDE 5.

Clouttery was designed to be constantly running, so it can monitor the battery and show notifications, but obviously it shouldn't have a window open to do this. Hence why a tray icon is ideal - and it works very well on Windows. Without a tray icon I don't really know what other interaction paradigm to use. Looks like I'll have to find a way to get the libappindicator bindings working, or wait for the KDE bugs which prevent the GtkStatusIcon from working to be fixed. It really needs to be a solution that works across most desktop environments, otherwise the client will be impossible to use for some users.

Having hit that dead end on the Linux client side, which caused extreme frustration, I turned into the server side. I spent most of the week implementing the billing system, not that I plan to begin charging for Clouttery soon, but it's best to get at least the foundations of that part working so that the remaining code can be made to work with it.

This part is actually much harder than it sounds, because I want it to be fairly complete, and so it supports different types of coupons (both credit and percentage discount coupons, expiring or not, etc.), upgrading and downgrading between plans without losing money (so e.g. if you are on a plan that costs $5/month and in the middle of the billing cycle you downgrade to a free plan, you get a coupon for $2.50; similarly, if you change to one that costs $10/year, you'll only have to pay $7.5), invoice cancellation, applying multiple coupons to an invoice, etc.
Not yet done but in the roadmap, there's support for associating payment methods (e.g. credit cards) so that recurrent billing can happen without the user having to pay invoices by hand and support for multiple payment methods (right now all payments are mocked).
Before everyone begins shouting "but but PCI compliance", don't worry as Clouttery will not store any CC data, everything is handed off to a processor like Stripe. (BTW, the reason why subscriptions are not dealt with through Stripe is that I want to be vendor-agnostic, and also do stuff like accept Bitcoin payments without having to pay Stripe's fees on them).

Since it's certainly going to be a while before this week's work is pushed into production, and as beta testers are probably never going to see this due to their unlimited free plans which don't expire, here are some screenshots:

http://s.lowendshare.com/7/1472251999.37.FireShot%20Capture%204%20-%20Billing%20Settings%20-%20Cloutt_%20-%20http___192.168.10.106_8088_manage_settings_billing.png

http://s.lowendshare.com/7/1472252058.729.FireShot%20Capture%205%20-%20Invoice%20-%20Clouttery_%20-%20http___192.168.10.106_8088_manage_s.png

Over a month after the last update, I have big news! This is basically copied from my post in another forum, I hope you don't mind.

Clouttery for Android is now available on Google Play!

https://play.google.com/store/apps/details?id=im.tny.segvault.clouttery

If you had previously installed Clouttery from an APK, please follow this guide before you do anything.

This is version 0.9.0, an update to 0.8.0 (which was distributed as an APK download) that brings important performance improvements (background memory usage reduced by up to 50%) and minor bug fixes. It also has some internal parts rewritten which cause incompatibility with the previous version, since most people will want to reinstall from Google Play, I figured it wasn't worth it to write migration code, and that's why you need to follow that special guide.

From on now, further updates will be pushed to Google Play so users don't have to install APKs manually.

~~ musical interlude ~~

About the Linux client, it's coming... slowly. I had to give up on using Mono, because even though I was able to reuse much of the code from the Windows client, I had trouble getting the GTK interface to work on anything other than my development machine (I had to compile my own gtksharp in order to get access to certain GTK widgets, and this made the process of redistributing the Mono version extremely complicated). I also couldn't get a tray icon to work in any Linux desktop environment - that was the end to the tray icon saga I mentioned in my last post.

All things taken into account (the fact that Mono needed to be installed, plus a custom gtksharp version that isn't compatible with the other apps that depend on it, plus the fact that the tray icon outright didn't appear on some platforms due to libappindicator and GtkStatusIcon problems), I decided it was best to give up on using Mono.

So I decided to take the Python base I had started long ago and continued its development, this time using GTK for the UI (I had previously tried tkinter which was clearly not adequate). This time, the tray icon works under MATE and KDE, and Gnome should be no problem either. I could also run it on three different Linux computers with different distros, after installing the necessary dependencies.
Only thing that's left to figure out is how to make the battery history graphs work, and how to distribute this. I tried using PyInstaller to build a stand-alone thing and it failed catastrophically. In the worst case this will be a ZIP file with Python code inside and you'll have to install some Python 3 libraries.

Heh... it's the third post in a row by me... I suppose Cemetech users should not be left out in the dark, especially not after that front page feature, so here's another update.

The server, and the Web Console, have been updated. The main change is that the new billing system has gone live, as you can see by going into Settings -> Billing in the Web Console ( https://clouttery.xyz/manage/settings/billing ). In order to help beta-test this system, some changes were made to the accounts of the existing users.

1. Everyone was moved into the new "Unlimited" plan, which is just like the old "Segvault Insider" plan, except it costs $5 per month.
2. Before you panic, a 100% off coupon was issued to everyone.

In practice, what this means is that beta-testers will still get Clouttery for free, for life, but they will be "billed" on a monthly basis. Every month, an invoice for $5 will be generated... and immediately paid by the 100% discount coupon. Or at least, this is what is supposed to happen. Everything was very well tested before pushing to production, but there's nothing like testing on a live system.

This also allows beta-testers to test a bit of the billing interface, including the invoice viewing page. You can also add a credit or debit card to your account, but since we're still testing Stripe, it is still in test mode. So you can only use the fake card numbers listed at https://stripe.com/docs/testing. If you're really in the mood for helping us, you can try to trick the system into accepting an invalid fake card, like 4000000000000069. Or you could add many, many different payment methods and make the system unbearably slow, or break it.

It was really fun to code this billing system from scratch, at first I thought I would not be able to make it, but then things started coming out better than expected Only issue is that it took much longer than expected to complete, but that was mostly because I couldn't work on it for the past few months. 70% of it was written in a single week last summer.

Sorry, our batteries were out of charge

That looks awesome! Too bad I have a Mac! Great idea, and I hope you can take it further!


Very Funny... (Ba Dump TShhhhh)

edit by Alex: Please edit your posts if you desire to post two or more times in a row in the same topic within a rough 24-hour period.

I'm slowly making progress on a Python-based client for Linux. The plan is to adapt it to macOS after that.

Glad to hear that! I'm finally getting a laptop after almost 5 years so I look forward to using this service. I went to signup and was glad to see I had already created an account a while ago.

While looking around, I do have a change to point out:



Should probably have the grammar/punctuation changed to:

For Linux, I believe the biggest challenge with getting the Python client published is a way to ensure all the necessary dependencies are installed - I suppose creating packages for installation with dpkg, yum, etc. and listing the dependencies in the package will help with this, as then package managers can make sure the dependencies are satisfied. However, some of the packages I'm using seem to be available only though pip, so I'll need to figure out how to make that work.

For macOS I don't know much about how packages work. I believe the only major thing needed is a) a way to get the battery status and b) tell users to install GTK3. Every other package I'm using probably works there as-is.

I would rather use one of these tools that take a Python program and produce a standalone binary, but all the ones I've tried so far have failed to produce a working binary with a sensible size. This seems to be because of the dependency in GTK3 and pygobject, let's see what can be done.

About the grammar in the plan description, you are right that it needs fixing. This has actually been on the to-do list for a long time, but there are always more important things to do. I should probably change the use of the verb "to expire" to something less negative and easier to understand. Like this: