py3status: Error messages

Many modules have hard coded error strings eg no connection

I think it’d be good if we have a way of dealing with these. the simplest option in my mind would be to have error_.. config options.

What are peoples views on how best to deal with this issue

About this issue

  • Original URL
  • State: closed
  • Created 7 years ago
  • Comments: 15 (15 by maintainers)

Most upvoted comments

Should we solve this on our own? I think our guy is too ultrabugged out at the moment.

I’ll chat to him tomorrow or friday, see how he wants to play things. My main concern is #610 getting released.

This project has become a bit high noise of late which has made things difficult for some contributers as they have been swamped with notifications/emails.

I suggest (red) module_name: error_message_here approach. … Leave the red bar to real errors / exceptions. Maybe make self.py3.notify display notifications in yellow instead of red too… … (red background, white text) module_name: error_message_here.

You need to be more clear with things. The ‘red bar’ is user notifications. I’m assuming you are using i3-nagbar rather than dbus notifications. Any colors are user configured not by py3status. We can choose the level (info, warn, error). user notifications happen for many different reasons. For the point of this issue all we care about are module driven errors, ie the module has an error that it is raising to the user. These are not the module failing and raising an Exception.

Anyhow I think to the user the error should just appear in the i3bar in color_error or color_bad. Example errors No connection Authentication error etc maybe just Error. When the user click we then provide fuller info eg which module …

I’d implement this via raise self.py3.ModuleError('Short error', desc='longer description', fatal=True) so that the modules can be kept simple.

But again I’m really interested about how we define these in a module, and how we can translate them etc.


As far as other settings are concerned. I’ll repeat myself (these are only my views)

format_... these are all processed via py3.safe_format() they have placeholders etc.

icon_.. or state_... are for users to define how things are displayed eg dpms {icon_off = " disabled" icon_on = " enabled"} whilst these are not perfect they are commonly used.


FORMAT ALL THE THINGS I think is really good and I much appreciate the work you have put in. However by also changing other things eg in https://github.com/ultrabug/py3status/pull/644/files you add string_unavailable this may be nice but we (as in the project) need to decide how we will handle these things before changing them (adding stuff is easy, undoing things is hard). temp_separator has been renamed (why?). These extra changes are what is blocking things. I know that it may seem petty but it is good to take things slowly and concentrate on one fix at a time.

Many modules already contains format_something. Changing them all (or one at a time) would mean more depreciation. It also seems easier to make a small description/documentation about formatter.py and how it is made for format only.

True, and some of these format_.. are correct and some are not. Slowly we fix the things.