Hello guys, I need help porting an widget for plasma 6

Here is the cmake:


cmake_minimum_required(VERSION 3.20)

project(plasma-pstate)

find_package(ECM REQUIRED NO_MODULE)
set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH} ${ECM_KDE_MODULE_DIR} ${CMAKE_MODULE_PATH})

include(KDEInstallDirs6)
include(KDECMakeSettings)
include(KDECompilerSettings NO_POLICY_SCOPE)
include(FeatureSummary)

find_package(KF6 REQUIRED COMPONENTS
Plasma REQUIRED
I18n
)

find_package(Qt6 CONFIG REQUIRED COMPONENTS
Quick
Core
)

add_subdirectory(src)

feature_summary(WHAT ALL FATAL_ON_MISSING_REQUIRED_PACKAGES)


I made some modifications to use kf6 but with no luck:

Here is the output error:


CMake Error at /usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find KF6 (missing: Plasma) (found version “6.0.0”)
Call Stack (most recent call first):
/usr/share/cmake-3.28/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
/usr/share/ECM/find-modules/FindKF6.cmake:93 (find_package_handle_standard_args)
CMakeLists.txt:13 (find_package)


Do you have any ideas? I’m using Kde neon 6.0.2.

Could NOT find KF6 (missing: Plasma) (found version “6.0.0”)

It says, it needs a KF6 dependency, here Plasma.

You need to install the development dependencies, here kio-dev libplasma-dev ki18n-dev, qt-quick-dev and qt-dev.
I don’t know the precise naming of the packages but they should be pretty similar.

1 Like

Thanks for you answer, but, I think I already have installed those packages.


sudo apt install libkf6plasma-dev libplasma-dev
Reading package lists… Done
Building dependency tree… Done
Reading state information… Done
libkf6plasma-dev is already the newest version (6.0.2-0xneon+22.04+jammy+release+build16).
libplasma-dev is already the newest version (6.0.2-0xneon+22.04+jammy+release+build16).
Starting pkgProblemResolver with broken count: 0
Starting 2 pkgProblemResolver with broken count: 0
Done
0 upgraded, 0 newly installed, 0 to remove and 6 not upgraded.


Maybe some other hidden package, but I have no idea what is package is missing.

Not an answer but as the original author of this widget, I guess I need to tell you that you don’t need it any more. You can achieve the same result by using the power profiles available in system settings under “Energy Saving”. The only thing you will miss is Dell’s thermal framework settings if you are using a dell laptop which supports that framework (you can use the cli tool smb-thermal-ctl for that).

The whole widget was just a quick and ugly hack btw :slight_smile:

2 Likes

Thank you very much for your answer and thanks for doing this awesome widget, I use this widget ever since its inception. Maybe it is time to retire it or write a simple widget only to change the smb-thermal.

Do you have any idea if there is a way to run a smb-thermal-ctl script when changing the power profile?

For each of “AC Power”, “On Battery” and “On Low Battery”, you can configure a command to run under certain “run conditions”:

Not sure if I should take this question to mean that the UI isn’t discoverable enough and needs improvement. Either way, this is the straightforward option.

If you’re looking to react specifically to a power-profiles-daemon profile getting enabled, i.e. “power-saver”, “balanced” or “performance”, then the D-Bus API of power-profiles-daemon can be monitored for its "ActiveProfile" property. I think it should send an automatic "PropertiesChanged" signal when that property (or any of its other ones) changed, but even in case it doesn’t send a signal, polling would still be an option.

1 Like

I was about to comment this as well, but I realized that I can’t figure out how it works exactly. I mean what exactly are we seeing in that screenshot? That you can have some scripts running when entering or exiting the… “Leave unchanged” power profile? :slight_smile:

Also: I would expect to somehow be able to “attach” such scripts in every power profile, but that doesn’t seem to be the case.

@ismaelbonato
I want just to mention that smb-thermal-ctl is just a python script which uses the libsmbios library so if you are familiar with python it should be at least easy to adapt it to your needs.

Oooh, that’s another angle I hadn’t even considered. The custom script fields are for “power states”, i.e. AC, battery, low battery. The “power profile” is a separate setting. I definitely struggled with labeling these fields when revamping the UI because a profile from “power-profiles-daemon” is obviously a “power profile”, but also AC/battery/low-battery is also obviously power-related. So I left the former as is because we can’t do much about it, but labeled the latter “power states” to give it at least some kind of distinction.

Guess it didn’t work out.

What I would really like to do, but takes more work, is to move the custom script settings into a different tab, a sub-page, or even a different settings module altogether. There are a number of ways one could go about this, but all need a good amount of design work to improve on the current (somewhat poor) state of this particular setting.

If you’ve got any short-term fixes in mind that could clear up this confusion without a bunch of extra work, good suggestions are definitely welcome. (Or patches! I know you’re a developer!)

1 Like

Yeah! I am a developer! :slight_smile:

An apparent quick fix would be relabeling thing. Ie instead of “Run custom script” something like “Run script on AC power state change” and then labeling the “When entering/exiting this power state” to something that leaves no confusion on what state we are talking about. Ie “when connected/disconnected to AC power”, “When battery is running low” etc.

I’ll try to submit a patch for that (should be straightforward) and also a second patch (no promises on that) with a solution to attach a script to when entering/leaving each power profile.

1 Like

famous last words :sweat_smile:

1 Like

Sorry I’m spamming this but I just realized that when you are seeing it on a laptop computer, you get the three power states above (AC, Battery, Low Battery). If you look at the same page on a desktop PC (as I did) it makes little sense as you can see in the screenshot

Oh well! :roll_eyes:

Oh! I see the disconnect. If you never switch power state profiles or even know about them, of course there’s no point to enter/exit script triggers. That’s a bug, yeah. Not just useless for desktop PC users, but actively harmful. (The third script, execute stuff on idle, theoretically still makes sense. So I guess we shouldn’t hide it altogether.)

For the strings, we could define different labels depending on whether you’re looking at AC/battery/low-battery. But perhaps that’s something to consider after figuring out how to deal with the desktop PC confusion. I’ll get this fixed for 6.1 at least, let’s see if we can have a quick fix for 6.0.x that doesn’t introduce new translatable strings. I’m thinking perhaps don’t show the run conditions button and always show the idle timeout command.

Both makes sense to me. Perhaps the Visual Design Group might want to contribute to that issue as well (pinging @ngraham).

@ismaelbonato sorry for going off topic. Seems like with your post you helped us in discovering a bug :slight_smile:

1 Like

I’m glad to hear that.

It is nice to run a script when on AC or battery, but it would be awesome if I can run scripts when changing power profile or just on the widget properties something like this.

It would be easy than write a widget only to change the dell thermal staff and I think a lot o people would be happy with it.

Thank you very much guys.