py3status
py3status copied to clipboard
[RFC] version 4.0
This is me writing down my wishes (and dreams) for version 4.0 and I hope I won't hurt anyone in doing so because I'm a rather drastic person...
As always, I'd love your ideas too. I'll edit this post if something else comes into my mind.
python
- get rid of python 2.7
- fully asyncio based
- minimal version of python = 3.6
drop the formatter
- use python f-strings formatting only
seamless configuration updates
- configuration reader should backup and update user config on the fly
- allows faster / easier deprecation of config etc
- reports on a special file to user inspection (and auto backups as mentioned earlier)
- would be auto by default, with ask-me-first or never options
make i3status a module like any other
- would be launched seamlessly if config use a i3status module
- but would be removed from core
usage tracking (opt-out by default)
- allow users to share their usage and love of py3status
- provided as a module with no output
make thresholds & borders general options
- in the core
implement a dbus event handler for modules
- already worked on #1547 so it should be rather easy
add default short_text support
- can be overridden per module
- reference PR : #1494
drop the formatter & use python f-strings formatting only
Looking at my config, I use nothing else except conditionals (which are supported by f-strings), setting specific color (e.g. color=degraded) and setting color based on threshold (e.g. color=free_disk_space with thresholds={'free_disk_space': [(0, 'bad'), (10, 'degraded'), (20, 'good')]} ) - if it's possible to support these use-cases with f-strings, I would be happy.
ability to import Xresources colors
-
Apply bad, degraded, good to default "red, yellow, green" numbers... so users can synchronize colors everywhere. I'm guessing we would use
color0
,color1
,color2
, etc.i3wm
allows this in their config usingset_from_resource $black color0 #000000
.
sensible config paths
-
~/.config/py3status/config
-- default -
~/.config/py3status/modules
-- default
Nothing to do with i3status or i3 config paths. Users should move them over. Right now, we have 6 or 7 different places to check. It is good time to make our own config directory.
simplify configs
- We can just hide all
on_udev
configs inpost_config_hook
and fixon_udev
to be like thresholds so it can pull a config and check (oh it's empty) immediately instead ofdir(self.module_class)
. It's more optimized this way. There are other configs that users don't care about likerequest_timeout
.
Looking at my config, I use nothing else except conditionals (which are supported by f-strings), setting specific color (e.g. color=degraded) and setting color based on threshold (e.g. color=free_disk_space with thresholds={'free_disk_space': [(0, 'bad'), (10, 'degraded'), (20, 'good')]} ) - if it's possible to support these use-cases with f-strings, I would be happy.
thresholds going core will have to cover this topic I suppose
minimal version of python = 3.6
is there a reason to use 3.6 as minimal version? If not I would be in favor to set the minimal python version to the python3 version in debian stable (3.5.3).
I believe it was because of f-Strings in Python 3.6.
See if we can use native Python's {name.lower()}
and some others instead of keep expanding our (rather basic) block formatter (i.e. [\?lower {name}]
). I'm guessing we would treat placeholders as variables... or go one level deeper to deal with a whole format
string.
It's likely faster, more clean, and probably fewer errors, etc... and we might be able to do more with that such as adding, subtracting, multiplying, cutting off things.
Also because Python 2.7 will be retiring in 2020 https://pythonclock.org/. Py3status have several codes to deal with Python2 and other unrelated codes. Better to make a leap right away to 3.6
and clean up things we don't need.
It looks like the full freeze date for Debian Buster is right around March 12, so Debian Buster might be released sometimes around middle of 2019.
Honestly, I don't know. This might be confusing as hell for the users... just the same.
Some other nice improvements that you can get going to Python 3 only:
- Substitute usage of
which
inPy3.check_commands()
forshutil.which()
function: https://docs.python.org/3/library/shutil.html#shutil.which. This will avoid calling a binary. - Use
subprocess.run()
in place ofsubprocess.Popen()
(mostly because the interface is cleaner, not much real benefits)
Just an idea to get some progress in this issue: merge all remaining PRs, starting to remove all compatibility code for Python 2 and make the code Python 3 only (after the release o 3.16, of course). The rest of the improvements can come later.
There are plenty of great ideas moving forward to version 4.0!
My personal favorites are:
- python f-strings for formatting:
- Making use of existing formatting definitions allows users, as well as developers to write more and more simple formatters
- There is no need for a separated documentation on who to format string
- DBus interfacing:
- Less system load
- Faster event handling, since it no longer depends on the refresh interval
- IMHO: cleaner way of interacting with the OS and other processes, as long as the DBus interface is implemented correctly
To clarify the state of the proposed usage-behavior:
- It is deactivated by default and can be opted-in?
- What information is gathered?
- Where is it stored? Is it processed or forwarded in any way, if so will this information be public?
- Is there a way to verify no information you don't want to leak is send, e.g. by printing what kind of information would be collected?
Ditching older python versions:
- Hard requirement for python f-strings
- Will break newer builds for current Debian stable, soon to be Debian old-stable
- Is this something to worry about?
- Tag last versions before loosing support for older versions for simple builds of older versions?
To clarify the state of the proposed usage-behavior
Just to be sure that everyone is on the same page: nothing has been done on this subject and even more: we will never to collect anything behind the back of users.
- So yes, this would be totally opt-in (a module you add yourself to your config)
- Information collected? dunno yet, we will discuss this openly but it will be data that will help us focus on real usage
- Storage? dunno, I'm not even sure we'd like to store something
- Verify information: we could make it clickable but anyway, module source code will be open source just as everything in this project :)
As a heads up I wanted to share that I've started working on the future py3status v4 configuration parser. I thought it would be a good starting point to define how the next generation of our project should work
I think I'm gonna open a Gitlab repo to work on it openly to separate from here until we reach something we like there... sounds good?
I have finally set up the gitlab repository with preliminary code to work on py3status v4 :hugs:
https://gitlab.com/ultrabug/py3status_v4
CI pipeline includes : flake8, black, mypy
I'm now focusing on the configuration parser refactoring and I need to add more tests. Discussions to be conducted there please!
For me, it would be nice to have audio warnings. Audio warnings may be triggered by:
- any item changed state
- any item become urgent
- a special item changed state, ...
I wonder whether visual effects may also be possible e.g. a flashing on change, or blinking text.
TODO for v4: check #1401 option 3