A couple of months ago, I was started receiving reports that the extension is stopped working on GNOME Shell 3.32. Shell has changed some API for pure JavaScript classes which not inherited from GLib GObjects. I had to decide to split the project into two branches for the new version of API and old one. But we already had the second branch desired by many people for a long time. So instead of splitting resources into 3 similar branches, I decided to finish that Gtk port and make it as the single default branch.

I was about to drop this project several times. It’s an expensive development for me. It needs a huge amount of time for testing and development. You can’t just run it on one system or even run it in virtual machines, containers or dockers because it’s hardbound to real hardware. It’s difficult to test some features like for CPU thermal throttle I should burn my CPU to test it to an example. There are many other difficulties like 100 kernel versions, tens GJS and GNOME Shell versions and various hardware and so on.

Recipe of freshly baked video card: “If there is nothing to lose. You should get a fried video card out. Disassemble it. Remove all dust and leftovers of the old thermal cease paste carefully. Put it in the oven on a couple of sheets of paper. Warm it to 250-270, °C then bake it about 2-3 minutes. DON’T TOUCH IT!!! Just open the oven and lets it cool by itself on the air! Place fresh thermal cease paste and assemble all together. Put it back. IMPORTANT!!! Cross fingers and turn your PC.”

Yeah, it could be real thing even if your wife laughs at you: "So it's more tasty now?!" I made it myself recently with my overclocked NVidia card after testing the project on Live ISO with Nouveau driver. I think Nouveau should have better DPM or I just should stop such testings on `random` distributions.

Achievements of the porting

  1. GNOME Extension is about 5% of all code. It’s just making its job as indicator for monitoring service, power events listener and the launcher. All that slow thing was moved to standalone application. It will be loaded when it’s needed. So it will be less affect GNOME Shell performance and freeing up resources for other useful extensions or applications.

  2. The application (Power Manager) has a place to grow now. It was always 2 main worries when we have decided to add some new features:
    • Do not break things which working;
    • And do not eat GNOME Shell and other system resources because it’s running in the main thread of the Shell and always persistent in the system memory.

  3. The enhanced compatibility makes it possible to use on GNOME Shell 3.32 and others DE. It could bring some fresh air to the project: new people, ideas, contributors and supporters.

  4. The code, architecture structure of the project is much cleaner, optimized and improved. It could help to bring more contributors to the project too. Sure, there is a lot thing to do yet but it’s just difficult to start. The code was a mess after all fixes, enhancements and new features. Now it’s getting cleaner like a fresh start for next changes :)

  5. There are already some enhancements like predefined power profiles, additional system information, thermal throttle checking for intel driver, system loading, memory widgets and more changes under the hood.

Disadvantages

  1. The main power manager application couldn’t be loaded immediately. It takes about 1s on my workstation and could be vary depending on current settings and system settings. But do you really need it running all the time?! It’s like a system monitor, you can open it check something and close it to free up resources for real tasks.

  2. It doesn’t look like the extension on GNOME Shell’s Wayland.

OMG! Some people don’t notice the real changes

I think many people even don’t understand the changes and still thinking it’s GNOME Shell’s PopupMenu.

Side by side Find 10 differences :)

OMG! It’s slow!

It's unresponsive, slow, and laggy. Do you even understand what’s just happened? When you are clicking on indicator button it launches another Gtk application like any other on the system by clicking a shortcut. I can make it persistent in the memory to able opening it immediately. But what the sense in the such feature and that porting except for it wouldn’t affect GNOME Shell thread. It’s like always run some application in the background to able shows immediately to example LibreOffice or GNOME System Monitor. So I wanted to tell more about the porting and advantages.

BTW I’m even considering to make that feature for such enthusiasts :) But it’s not finished transformation yet and I don’t want make such pointless features.

I understand Linux is getting to be more casual platform and there are a lot of non-technician users like my mom. She wouldn’t understand such a slow opening if she would even use it consciously. Sorry, mom! I love you! :)

If you are power-user you could step in and improve some things so.

Usual mistakes

  • OTHER POWER MANAGMENT TOOLS Disable on battery event inside the extension or inside other tool. The worst thing is when you trying to use SEVERAL POWER MANAGEMENT TOOLS together like this extension, laptopmode-tools, TLP, system76-power, etc Solution: ensure you are using the ONE POWER MANAGEMENT TOOL at least for CPU. You could test your settings by monitoring current settings in the system journal and turning on/off your power supply.

  • IRQBALLANCE It’s a cause of plenty issues when you trying to control your CPU core threads! Solution: Uninstall it or disable its systemd service.

  • intel_pstate CPU driver. Using/choosing that driver tells: I don't want to let my system (kernel) control CPU. Let's it be automatically depending on already loaded code inside my CPU! So I don't care! Solution is to disable intel_pstate driver in the kernel boot command line. It’ll give the chance to the Linux kernel and users control CPU depending on all actual tasks and events.

Your system will go crazy until freezes and memory dumps, especially, on the weak, ultra-low, mobile CPUs.

Next steps

  1. Make changes in the profiles to able handle other types of system components like sensors, display brightness, etc.

  2. Rework system events to get more events like loading, TT and so on.

  3. Refactoring of all CLI and DBUS interfaces

  4. Re-branding of the project because it’s already not just Shell extension. We are thinking about OSPower and OSPower Manager

  5. Finish a packaging of the application for other desktops.

Conclusions

I think it’s already a big step forward! There are a lot things to do. Maybe be it’s not perfect. But I has really tried to do so.

Thank you for your patience!