[RFC] version 4.0

[ultrabug]

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 WIP: dbus helper for modules #1547 so it should be rather easy

add default short_text support

• can be overridden per module
• reference PR : core: add short_text support [wip] #1494

[maximbaz]

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.

[lasers]

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 using set_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 in post_config_hook and fix on_udev to be like thresholds so it can pull a config and check (oh it's empty) immediately instead of dir(self.module_class). It's more optimized this way. There are other configs that users don't care about like request_timeout.

[ultrabug]

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

[L0ric0]

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).

[lasers]

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.

[thiagokokada]

Some other nice improvements that you can get going to Python 3 only:

• Substitute usage of which in Py3.check_commands() for shutil.which() function: https://docs.python.org/3/library/shutil.html#shutil.which. This will avoid calling a binary.
• Use subprocess.run() in place of subprocess.Popen() (mostly because the interface is cleaner, not much real benefits)

[thiagokokada]

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.

[AnwariasEu]

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?

[ultrabug]

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 :)

[ultrabug]

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?

[ultrabug]

I have finally set up the gitlab repository with preliminary code to work on py3status v4 🤗

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!

[bitozoid]

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.

[ultrabug]

TODO for v4: check #1401 option 3