[Marble-devel] Review Request: Inhibit screensaver in turn-by-turn navigation mode
Dennis Nienhüser
earthwings at gentoo.org
Tue Aug 31 09:25:09 CEST 2010
> On 2010-08-30 22:08:14, jmho wrote:
> > I'm wondering if there is a more canonical way of preventing the screensaver starting. Applications which provide a presentation mode or video players should have the same problem to solve.
>
> Dennis Nienhüser wrote:
> Hm, the inhibition comes down to
>
> #include <QtMobility>
> new QSystemScreenSaver( this )->setScreenSaverInhibit();
>
> It works on Maemo, Linux, and possibly every other platform supported by Qt. Not sure how a better solution should look like? I'd guess other solutions not using QtMobility are full of platform dependent #ifdefs.
>
> The rest of the code is there to realize it as a Marble plugin, which adds some code overhead, but has the neat side-effect of adding the QtMobility dependency only to the inhibit-screensaver plugin. The marblewidget lib and the marble applications don't need to know / link against QtMobility.
>
>
> Torsten Rahn wrote:
> Well, to be honest this patch looks a bit odd to me as well. I know it's a pragmatic approach (and usually I like those), but still:
> * For some feature that would be regarded a common use case on all platforms we link ("optionally") against yet another library that isn't even shipped with distributions yet. I do understand that in the future Qt Mobility might become important to rely on - at least on "mobile" devices. Still I wonder whether the library is "there" yet.
> * The way it is implemented as an "invisible" render plugin looks a bit like a workaround. Do we need another new plugin interface?
> * The feature touches the "energy saving" dept. We haven't much taken this subject into account yet (except for avoiding timers in Marble). Is there some other "big picture" for energy saving/avoidance of waking up the CPU where this kind of plugin would fit in better?
>
>
> * For some feature that would be regarded a common use case on all platforms we link ("optionally") against yet another library that isn't even shipped with distributions yet. I do understand that in the future Qt Mobility might become important to rely on - at least on "mobile" devices. Still I wonder whether the library is "there" yet.
Well, it works on Maemo where it is most important. If other platforms don't work as well yet, it doesn't hurt much if the plugin is not compiled. I could use the Maemo libraries directly like in the Maemo position provider, but why choose a specific solution if a more general one is there?
> * The way it is implemented as an "invisible" render plugin looks a bit like a workaround. Do we need another new plugin interface?
I thought about that, but finally decided for stressing the term render plugin a bit and use the existing interface. Mainly for two reasons: 1) Pragmatic (get it done fast) 2) Unsure about similar use cases to have it fit into a common plugin interface.
> * The feature touches the "energy saving" dept. We haven't much taken this subject into account yet (except for avoiding timers in Marble). Is there some other "big picture" for energy saving/avoidance of waking up the CPU where this kind of plugin would fit in better?
I don't think energy saving is the primary concern here: Driving around with Marble on the N900 without this plugin, you have to touch the screen every two minutes (the longest period you can configure the screen not to go off as a user). This makes it unusable for turn-by-turn navigation.
- Dennis
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/5167/#review7302
-----------------------------------------------------------
On 2010-08-27 11:31:52, Dennis Nienhüser wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/5167/
> -----------------------------------------------------------
>
> (Updated 2010-08-27 11:31:52)
>
>
> Review request for marble.
>
>
> Summary
> -------
>
> In turn-by-turn navigation mode you usually just watch the screen, but do not "use" the system. A screensaver (screen blanking and locking on Maemo) coming in at that point is highly annoying. This patch adds an invisible render plugin that uses QtMobility to inhibit the screensaver as long as the plugin is enabled and a position provider is active. Given that it is a plugin on its own, the new dependency to QtMobility doesn't affect Marble much: Without QtMobility, the screensaver inhibition plugin is not build and its functionality isn't there, nothing else.
>
>
> Diffs
> -----
>
> /trunk/KDE/kdeedu/marble/FindQtsysteminfo.cmake PRE-CREATION
> /trunk/KDE/kdeedu/marble/src/lib/graphicsview/ScreenGraphicsItem_p.h 1168534
> /trunk/KDE/kdeedu/marble/src/plugins/render/CMakeLists.txt 1168534
> /trunk/KDE/kdeedu/marble/src/plugins/render/inhibit-screensaver/CMakeLists.txt PRE-CREATION
> /trunk/KDE/kdeedu/marble/src/plugins/render/inhibit-screensaver/InhibitScreensaverPlugin.h PRE-CREATION
> /trunk/KDE/kdeedu/marble/src/plugins/render/inhibit-screensaver/InhibitScreensaverPlugin.cpp PRE-CREATION
>
> Diff: http://reviewboard.kde.org/r/5167/diff
>
>
> Testing
> -------
>
> Works on my N900.
>
>
> Thanks,
>
> Dennis
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.kde.org/pipermail/marble-devel/attachments/20100831/4cf9fb4e/attachment.htm
More information about the Marble-devel
mailing list