[dragon] Inhibit powersave
Review Request #129651 - Created Dec. 14, 2016 and submitted
Since solid power api is not released, i use freedesktop dbus to fit other desktop power managers
*Harald master was not merged (16.04 / 16.08 to master) -> it has fresh bugreports for fixed issues.
Last merge to 16.08
2016-04-18 Merge branch 'Applications/16.04' Harald Sitter
after that in brach 16.04
2016-04-26 Hide toolbar on multiscreen setup Anthony Fieroni
2016-04-20 Don't try to resize maximized window Anthony Fieroni
2016-04-19 MPRIS2 property 'Identity' to match desktop file entry Anthony Fieroni
Do you want to merge them or you will ship ?
Inhibiting is so very bad...
- org.freedesktop.PowerManagement is deprecated https://www.freedesktop.org/wiki/Specifications/power-management-spec/ there seems to be no information as to what it was deprecated in favor of though
- we could use org.kde.Solid.PowerManagement but that would not work on !plasma as I understand it
- we could use org.freedesktop.login1 https://www.freedesktop.org/wiki/Software/systemd/inhibit/ which would work everywhere but on plasma, as apparently powerdevil tells logind to shut up
- there's this unlanded RR https://git.reviewboard.kde.org/r/126650/ which would kinda solve our problem, albeit also using org.freedesktop.PowerManagement
Where to go from here I do not actually know. I'd rather not use org.freedesktop.PowerManagement given its depreated state, at the same time I am somewhat inclined to not care given every source code I checked is using it anyway. that being said the RR currently doesn't inhibit screensavers.
As for the merge problem. When you commit to maintenance branches (i.e. Applications/) you need to manually merge them into master or any other relevant branches as well. There is no automatic merge and I am also only merging into master on-demand, when I make a change myself. To fix this it appears you can simply merge Applications/16.04 into Applications/16.12 and then Applications/16.12 into master
I am pretty sure the inhibition port is lackluster. Notably KnotificationRestrictions inhibited screensaving which I am assuming doesn't fall into the PowerManagement domain so the new code while inhibiting sleeping it seems ot miss screensaver stuff.
Fortunately knotificationrestrictions is ported and you can just keep on using it.
If I am not mistaken having cmake generate an adoptor out of xml is preferred https://techbase.kde.org/Development/Tutorials/D-Bus/Accessing_Interfaces#Using_Classes_Generated_From_D-Bus_XML
While being only slightly more efficient it is infinately nicer code as you don't have to deal with qdbusreply manually ;)
explanation of what QLatin1String does and what QStringLiteral does
Long story short: only use QLatin1String iff you have an ascii
const charand need to pass it to a QL1S supporting function. e.g.
string.startsWith(...)would be faster to call with QL1S as there is a specific override to handle QL1S http://doc.qt.io/qt-5/qstring.html#startsWith-2
Please no whitespaces surrounding arguments.
You are preventing shutdown here. As I understand it there is no if-else if you only use login1 as logind doesn't have control over screen power saving.
Seeing as this introduces a new i18n string this can't go into Application/16.12 unless you make them strings literal for the branch or get an exception from the i18n team. https://mail.kde.org/mailman/listinfo/kde-i18n-doc
Either is fine since the string is probably not actually user visible anywhere.
It would be good to add a FIXME or TODO comment about the lack of screen power saving supression. I think KNotificationRestriction won't actually do that.