Moving PowerDevil to kdereview

[Friedrich W. H. Kossebau]

Am Donnerstag, 4. September 2008, um 20:42 Uhr, schrieb Sebastian Kügler:
> On Thursday 04 September 2008 20:24:21 Friedrich W. H. Kossebau wrote:
> > Am Donnerstag, 4. September 2008, um 18:59 Uhr, schrieb Sebastian Kügler:
> > > On Thursday 04 September 2008 15:18:09 Friedrich W. H. Kossebau wrote:
> > > > > The core is the KDED module. Polling was removed thanks to a system
> > > > > that sets the polling time to the next upcoming idle event. Every
> > > > > time the polling function is called PowerDevil calculates the
> > > > > minimum time for an idle event to come, and sets the timer
> > > > > accordingly. For example, in a scenario where you have a lot of
> > > > > events in a small amount of time, PowerDevil polls the system every
> > > > > minute. For detecting system activity, it uses the same grabbing
> > > > > system used previously in KDE4Powersave.
> > > >
> > > > Please tell me where I am wrong:
> > > > So this is a per-user/session demon, right? But shouldn't this be a
> > > > per-system demon? How are things supposed to work if two or more
> > > > users are logged in at the same time, perhaps even running different
> > > > environments (KDE3, KDE4, GNOME, ...) which all try to react to
> > > > system changes?
> > >
> > > This one is covered by Solid and ultimately HAL, no? (I'm assuming that
> > > powerdevil only offeres the options that it's allowed by the capability
> > > checks, as indicated in the Capabilities tab, just like the shutdown
> > > options in the ksmserver logout dialog).
> >
> > This code looks like the PowerDevil demon acts itself as events handler:
> >
> > --- 8< ----
> >
> > PowerDevilDaemon::PowerDevilDaemon(...)
> >
> > :        m_notifier(Solid::Control::PowerManager::notifier())
> >
> > {
> > ...
> >     connect(m_notifier, SIGNAL(buttonPressed(int)),
> >       this, SLOT(buttonPressed(int)));
> > ...
> > }
> >
> > void PowerDevilDaemon::buttonPressed(int but)
> > {
> >     if (but == Solid::Control::PowerManager::LidClose) {
> >
> >         KConfigGroup *settings = getCurrentProfile();
> >
> >         if (!settings)
> >             return;
> >
> >         switch (settings->readEntry("lidAction").toInt()) {
> >         case Shutdown:
> >             shutdown();
> >             break;
> >         case S2Disk:
> >             suspendToDisk();
> >             break;
> >         case S2Ram:
> >             suspendToRam();
> >             break;
> >         case Standby:
> >             standby();
> >             break;
> >         case Lock:
> >             lockScreen();
> >             break;
> >         default:
> >             break;
> >         }
> >
> >         delete settings;
> >
> >     }
> > }
> > --- 8< ----
>
> I assume that the corresponding QActions won't be available when the
> capability check in Solid fails (otherwise, the call itself fails).
>
> I didn't look at that part of the code though, so I might be wrong.

Perhaps :)

This is not about GUI input, like selecting "Shutdown" from the applet, but 
the demon reacting to events from the system (here: the lid is closed).

So imagine two users logged in, Sue and Bo. Bo was surfing before, has the 
(her) demon configured to  suspendToDisk() on lidclose. Sue configured the 
(her) demon to lockScreen() on lidclose, because she is going to compile 
something. Sue kicks off the compile and closes the lid -> Sue's demon locks 
the screen, but Bo's demon suspends -> Sue will be happy... not. 

Friedrich
-- 
Okteta - KDE Hex Editor, coming to you with KDE 4.1