Re: Preferred way for an application to inhibit suspend on KDE

2017-01-22 Thread elboulangero
nt is present on the bus, sometimes it is not. When it's here, I can see both of the well-kown dbus names: 'org.freedesktop.PowerManagement' and 'org.kde.Solid.PowerManagement'. When it's not here, none of these names are present on the bus. Cheers On 01/21/2017 09

Re: Preferred way for an application to inhibit suspend on KDE

2017-01-20 Thread elboulangero
> If you are on a dev edition it's probably a temporary bug. User > edition should work fine. Well I downloaded the KDE Neon "User LTS Edition" from 2016-12-29. Now, I noticed on the website that there's another LTS edition from 2017-01-19, and I'm starting to wonder if the LTS edition might be a d

Re: Preferred way for an application to inhibit suspend on KDE

2017-01-20 Thread elboulangero
Thanks for the information. I'm running KDE Neon on a virtual machine, downloaded from , and I can tell you that there's no 'org.freedesktop.PowerManagement' or 'org.kde.Solid.PowerManagement', that's why I'm a bit puzzled. > FWIW, I would always call login1. In fact, I woul

Preferred way for an application to inhibit suspend on KDE

2017-01-20 Thread elboulangero
Hi, I'm writing an application that needs to prevent the system from suspending. I strive to support every GNU/Linux desktops, and I'm a bit stuck with KDE. I didn't find any obvious way to do that. On GNOME and related, I would use the D-Bus service 'org.gnome.SessionManager'. On XFCE, it would