bumblebee-status/bumblebee/modules/cpu.py

# pylint: disable=C0111,R0903

"""Displays CPU utilization across all CPUs."""

import psutil
import bumblebee.engine

class Module(bumblebee.engine.Module):
    def __init__(self, engine, config):
        super(Module, self).__init__(engine, config,
            bumblebee.output.Widget(full_text=self.utilization)
        )
        self._utilization = psutil.cpu_percent(percpu=False)
        engine.input.register_callback(self, button=bumblebee.input.LEFT_MOUSE,
            cmd="gnome-system-monitor")

    def utilization(self):
        return "{:05.02f}%".format(self._utilization)

    def update(self, widgets):
        self._utilization = psutil.cpu_percent(percpu=False)

# vim: tabstop=8 expandtab shiftwidth=4 softtabstop=4
[modules/cpu] Add initial version of CPU utilization module Re-enable the CPU utilization module as proof-of-concept for the new core engine. see #23 2016-12-04 17:45:42 +01:00			`# pylint: disable=C0111,R0903`

			`"""Displays CPU utilization across all CPUs."""`

			`import psutil`
			`import bumblebee.engine`

			`class Module(bumblebee.engine.Module):`
[modules/datetime] Use parameter functionality to get format Make the format string of the datetime module configurable using the new parameter() method in the module. Also, restructured the setting of the config information a bit so that the parameter() method can be used in the constructor of a module. see #23 2016-12-09 08:23:53 +01:00			`def __init__(self, engine, config):`
			`super(Module, self).__init__(engine, config,`
[core] Widget creation/update overhaul Until now, widgets were re-created during each iteration. For multiple, reasons, using static widget objects is much easier, so instead of creating new widgets continuously, modules now create the widgets during instantiation and get the list of widgets passed as parameter whenever an update occurs. During the update, they can still manipulate the widget list by removing and adding elements as needed. Advantages: * Less memory fragmentation (fewer (de)allocations) * Easier event management (widgets now have static IDs) * Easier module code (widget contents can simply be the result of a callback) see #23 2016-12-08 08:44:54 +01:00			`bumblebee.output.Widget(full_text=self.utilization)`
			`)`
[modules/cpu] Add initial version of CPU utilization module Re-enable the CPU utilization module as proof-of-concept for the new core engine. see #23 2016-12-04 17:45:42 +01:00			`self._utilization = psutil.cpu_percent(percpu=False)`
[core] Add input processing Create infrastructure for input event handling and add i3bar event processing. For each event, callbacks can be registered in the input module. Modules and widgets both identify themselves using a unique ID (the module name for modules, a generated UUID for the widgets). This ID is then used for registering the callbacks. This is possible since both widgets and modules are statically allocated & do not change their IDs. Callback actions can be either callable Python objects (in which case the event is passed as parameter), or strings, in which case the string is interpreted as a shell command. see #23 2016-12-09 19:29:16 +01:00			`engine.input.register_callback(self, button=bumblebee.input.LEFT_MOUSE,`
			`cmd="gnome-system-monitor")`
[modules/cpu] Add initial version of CPU utilization module Re-enable the CPU utilization module as proof-of-concept for the new core engine. see #23 2016-12-04 17:45:42 +01:00
[core] Widget creation/update overhaul Until now, widgets were re-created during each iteration. For multiple, reasons, using static widget objects is much easier, so instead of creating new widgets continuously, modules now create the widgets during instantiation and get the list of widgets passed as parameter whenever an update occurs. During the update, they can still manipulate the widget list by removing and adding elements as needed. Advantages: * Less memory fragmentation (fewer (de)allocations) * Easier event management (widgets now have static IDs) * Easier module code (widget contents can simply be the result of a callback) see #23 2016-12-08 08:44:54 +01:00			`def utilization(self):`
			`return "{:05.02f}%".format(self._utilization)`
[modules/cpu] Add initial version of CPU utilization module Re-enable the CPU utilization module as proof-of-concept for the new core engine. see #23 2016-12-04 17:45:42 +01:00
[core] Widget creation/update overhaul Until now, widgets were re-created during each iteration. For multiple, reasons, using static widget objects is much easier, so instead of creating new widgets continuously, modules now create the widgets during instantiation and get the list of widgets passed as parameter whenever an update occurs. During the update, they can still manipulate the widget list by removing and adding elements as needed. Advantages: * Less memory fragmentation (fewer (de)allocations) * Easier event management (widgets now have static IDs) * Easier module code (widget contents can simply be the result of a callback) see #23 2016-12-08 08:44:54 +01:00			`def update(self, widgets):`
			`self._utilization = psutil.cpu_percent(percpu=False)`
[modules/cpu] Add initial version of CPU utilization module Re-enable the CPU utilization module as proof-of-concept for the new core engine. see #23 2016-12-04 17:45:42 +01:00
			`# vim: tabstop=8 expandtab shiftwidth=4 softtabstop=4`