Version: (using KDE 4.3.4) Installed from: Gentoo Packages Every time I'm in a hurry. I just press suspend button on my laptop, put it (laptop) in a bag a run wherever I need to be. And in some of these situations Amarok was playing before the suspend. So I'm a little nervous everytime when I have to wake up my laptop on a meeting. Did I paused Amarok? It would be really nice if Amarok can (optionally) pause itself on suspend.
Sounds reasonable :)
Technically not possible at all. Spoke to some Solid people. Sorry :(
Huh? Ok, you're the expert, but why? When I press the power button on laptop notification pops up and says "hey your laptop is going to sleep". Theoretically I can create a script which runs alongside with this notification and pauses amarok. But I'd rather have it as out-of-box feature in amarok.
Afaik powerdevil is handling this. It doesnt provide a infrastructure to notify listeners on this event. It just throws a KNotification and then suspends immediately (I already looked at their code). There's no time to react on this. Ask upstream (powerdevil maintainer) to provide some signalling before actually going down.
As #244124 was implemented I pledge once again for this feature to be implemented.
Bug 244124 being solved, I'm reopening this wish.
Please note that this could take some time. We still depend on KDE 4.4.
Reproducible in 2.6-git
Sorry about the noise, I only attempted to add myself to the CC list and instead seem to have removed most people. :(
..except that was bug #296100 and I haven't actually removed anyone, it just jumped to this bug next? Sorry again, this bug tracker is confusing me.
On the bugzilla "Preferences" page, you can change that behavior.
Thanks! The default behavior took me by surprise.
I wanna work on this bug. But it seems to conflict with https://bugs.kde.org/show_bug.cgi?id=301512 . How should I go about this?
https://git.reviewboard.kde.org/r/109846
Anmol, thinking more about this bug and bug 259862, I think we should have 3 mutually exclusive radio buttons in Amarok Playback config: When Amarok is playing: (a) Prevent system from going to sleep (b) Allow system to go to sleep, but pause playing (c) Allow system to go to sleep, resume playing on resume [question is what should be default and if other devs are happy with this - I'm going to bring this to amarok-devel@kde.org - please watch it] Anmol, please update the patch accordingly and attach a screenshot of the changed dialog to the review request. P.S: Kudos to you Anmol for recent inflow of patches - you independently pick and fix bugs, something that counts should you apply for GSoC.
I found out(on #solid) that Solid::PowerManagement::beginSuppressingSleep() can only inhibit automatic system sleep. So the two options aren't really mutually exclusive and there is another possible combination: Prevent system from going to [automatic] sleep, and pause playback on [manual] sleep. Should I add 4 radio buttons then? And thanks :) I would like to apply for GSoC, actually. I'll get working on them by tonight (GMT+5.5).
Git commit 71e55e7bdd9b31642d09145a5801777c0e120454 by Matěj Laitl, on behalf of Anmol Ahuja. Committed on 06/04/2013 at 18:07. Pushed by laitl into branch 'master'. Implement power management: suspend inhibition and pause on resume FEATURES: * Added options to pause playback on system suspend and to inhibit automatic suspend if playing a track (enabled by default); patch by Anmol Ahuja. (BR 259862, 222571) Related: bug 259862 FIXED-IN: 2.8 REVIEW: 109846 DIGEST: Amarok is now power-management aware: it can inhibit automatic system suspend and pause on resume (configurable) M +2 -0 ChangeLog M +1 -0 src/CMakeLists.txt M +2 -0 src/EngineController.cpp M +8 -0 src/amarokconfig.kcfg M +36 -1 src/configdialog/dialogs/PlaybackConfig.ui A +90 -0 src/playback/PowerManager.cpp [License: GPL (v2+)] A +48 -0 src/playback/PowerManager.h [License: GPL (v2+)] M +3 -1 tests/core-impl/meta/multi/CMakeLists.txt M +2 -0 tests/playlist/CMakeLists.txt http://commits.kde.org/amarok/71e55e7bdd9b31642d09145a5801777c0e120454
*** Bug 150396 has been marked as a duplicate of this bug. ***