Feat: Peripheral status and integration #140
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: zach/z-bar-qt#140
Reference in New Issue
Block a user
What & why
WIP. Aims to add support for storing and displaying information about connected wireless peripherals. Will most likely be targeted mostly toward displaying battery percentages.
Battery polling daemon is started through QML if the UPower widget is enabled. The daemon is slow to initialize, but once warmed up it will report device stats with a 15 second interval. It uses a lock file to prevent multiple daemons from spawning.
The battery widget on the bar shows the device with the currently lowest battery percentage.
Related issue
#139
Type
New feature
Tested
Breaking changes?
None
Checklist
I have tested the following devices:
The mice show up. Controller shows up. ANC headphone does not report on the module, but is visible in blueman. Soundbar correctly does not show up since it has no battery.
I will do a thorough review once the PR is out of WIP.
WIP: Peripheral status and integrationto Feat: Peripheral status and integration094fc568f1to5a01c4b472Added commits that deal with the failing CI/CD.
I discovered containers in docker and workflows to use a slim container. This is good to only get a minimum required container to do the job. Here is a snippit of the change:
I also changed from alpine to debian since additional dependencies are required to conform to Alpine's use of musl.
Amount of jobs is reduced as well for python's CI. Will likely do it for all CI checks later (including using slim when beneficial), just python for now. Reason being to reduce reinstalling packages or rebuilding for each separate job. Python's CI now is separated from static and a verify check. Verify is what will be required as that runs the typecheck, tests, and nuitka build check.
Currently, typecheck is on the verify job. This could go to static if you do not deem this an important check. let me know about that.
Pyproject was also missing dependencies for the CI to grab all needed dependencies. Initially, had optional dependencies, but this is likely unnecessary as we have few dependencies as of now.
5a01c4b472to8883d98b00battery.pycould be separated into modules. Multiple sub-features into separate files could improve readability, though that could be my preference. Reason is thatbattery.pydoes not give much of a hint what the file is as a sub command. Separating the file into multiple modules separates separate functions such as:peripheral/config.py,peripheral/listener.py, andperipheral/daemon.py.Now, I have not read every line in detail to ascertain proper separation, so module naming and the amount of separation are things I am unsure of.
Other than that, code looks good to me. I will approve and let you decide if separating into modules is what you want to do.
@@ -0,0 +244,4 @@def _start_hotplug_watcher(on_hotplug: Callable[[], None]):try:import pyudevimports are done within try catch statements. Is this commonplace in Python rather then importing into the file at the top?Has to do with that a global import would create naming conflicts.
Could be a good idea, yeah. Though it's pretty low on the priority list for me honestly, since the reason for splitting the file wouldn't be to make components reusable and strictly only to increase readability.
I will merge this, then.