Patch for skipping tracks with volume rocker
Update 2019-08-16: see the updated VolumeControl.qml for the 3.1.0. Modifications are the same as earlier.
Update: the issue below is still relevant, but for the time being I've just altered the patch in such a way that when the volume key is held down it changes volume in one direction, and when the key is released — in the other. I do understand that is not what you call elegant.
Any ideas or attempts to rewrite it, package it for the patchmanager and so on are welcome.
Archive with the patch and modified VolumeControl.qml: VolumeControl.tar.gz
You can apply the patch manually (don't forget to backup) or just replace your original /usr/share/lipstick-jolla-home-qt5/volumecontrol/VolumeControl.qml (bear in mind that the mine one is for 2.1.1.26).
Ahoy there. Please correct me if I'm wrong but as far as I see, that issue is still relevant and there is (was) no way to skip tracks with volume rocker. So after taking a look into some other patches and docs I've created a quick and dirty patch for VolumeControl.qml. It is as follows (here is the pastebin upload of it):
--- "/usr/share/lipstick-jolla-home-qt5/volumecontrol/VolumeControl.qml" 2017-11-02 21:04:52.000000000 +0300
+++ "/usr/share/lipstick-jolla-home-qt5/volumecontrol/VolumeControl.qml" 2017-11-04 00:33:09.000000000 +0300
@@ -10,6 +10,7 @@
import Sailfish.Silica 1.0
import org.nemomobile.systemsettings 1.0
import org.nemomobile.configuration 1.0
+import org.nemomobile.mpris 1.0
import QtFeedback 5.0
import "../systemwindow"
import "../compositor"
@@ -17,6 +18,8 @@
SystemWindow {
id: volumeBar
+ MprisManager { id: mprisManager }
+
property bool volumeIncreasing
property bool lateScreenshotCapture
property var screenshot
@@ -453,7 +456,13 @@
repeat: true
onTriggered: {
if (volumeBar.controllingMedia) {
- volumeControl.volume = volumeControl.volume + (volumeBar.volumeIncreasing ? 1 : -1)
+ if (volumeIncreasing)
+ mprisManager.previous()
+ else
+ mprisManager.next()
+ keyRepeat.stop()
+ keyRepeatDelay.stop()
+ initialChange = 0
} else {
profileControl.adjustRingtoneVolume(volumeBar.volumeIncreasing ? 20 : -20)
}
@@ -488,14 +497,10 @@
volumeBar.volumeIncreasing = (key == Qt.Key_VolumeUp)
if (volumeBar.controllingMedia) {
- if (volumeIncreasing)
- initialChange = volumeControl.volume === volumeControl.maximumVolume ? 0 : -1 / (volumeControl.maximumVolume+1)
- else
- initialChange = volumeControl.volume === 0 ? 0 : 1 / (volumeControl.maximumVolume+1)
-
+ initialChange = 0
+ baseVolume = volumeControl.volume
keyRepeat.stop()
keyRepeatDelay.restart()
- volumeControl.volume = volumeControl.volume + (volumeBar.volumeIncreasing ? 1 : -1)
} else {
if (volumeControl.windowVisible) {
if (volumeIncreasing)
@@ -518,7 +523,14 @@
onVolumeKeyReleased: {
initialChange = 0
if (volumeBar.controllingMedia)
- baseVolume = volumeControl.volume
+ keyRepeat.stop()
+ keyRepeatDelay.stop()
+ if (volumeIncreasing)
+ initialChange = volumeControl.volume === volumeControl.maximumVolume ? 0 : -1 / (volumeControl.maximumVolume+1)
+ else
+ initialChange = volumeControl.volume === 0 ? 0 : 1 / (volumeControl.maximumVolume+1)
+ volumeControl.volume = volumeControl.volume + (volumeBar.volumeIncreasing ? 1 : -1)
+
if (volumeBar.volumeIncreasing == (key == Qt.Key_VolumeUp)) {
// Handle pressing both buttons and releasing the first, though
// in that case keyRepeat is probably already stopped by screenshotTimer
As one may notice, it does the following things:
- Imports MPRIS interface.
- Tinkers with the KeyRepeat timer — now, if the volume key controls the media volume (meaning there is an active media player) the timer does not change volume when triggered (and, as it was before, it is triggered when the volume up or down button is held for 600 ms). Instead it sends MPRIS signal for any compatible player to change to previous or next track. Of course single press still changes the music volume.
- Changes volume rocker behaviour (again only when there is an active player). Now the volume changes on the key release.
Sadly I'm not a mobile or QML developer and frankly, not a developer at all. So if you have any ideas on improvement of that code — please do share them.
And the important point — there is still major issue: on the release of the volume key the volume is altered regardless of whether the keyRepeat timer was triggered (and the track changed). As far as I understand (again sorry, but I'm really not a developer) there must be a connection made to the keyRepeat timer signal. But if somebody would be so kind to show how it is done or propose alternative solution I'd be quite grateful.
For now the VolumeControl.qml sections in question are as follows:
Timer {
id: keyRepeat
interval: volumeBar.controllingMedia ? 75 : 300
repeat: true
onTriggered: {
if (volumeBar.controllingMedia) {
if (volumeIncreasing)
mprisManager.previous()
else
mprisManager.next()
keyRepeat.stop()
keyRepeatDelay.stop()
initialChange = 0
} else {
profileControl.adjustRingtoneVolume(volumeBar.volumeIncreasing ? 20 : -20)
}
restartHideTimerIfWindowVisibleAndWarningNotVisible()
}
}
onVolumeKeyReleased: {
initialChange = 0
if (volumeBar.controllingMedia)
keyRepeat.stop()
keyRepeatDelay.stop()
if (volumeIncreasing)
initialChange = volumeControl.volume === volumeControl.maximumVolume ? 0 : -1 / (volumeControl.maximumVolume+1)
else
initialChange = volumeControl.volume === 0 ? 0 : 1 / (volumeControl.maximumVolume+1)
volumeControl.volume = volumeControl.volume + (volumeBar.volumeIncreasing ? 1 : -1)
if (volumeBar.volumeIncreasing == (key == Qt.Key_VolumeUp)) {
// Handle pressing both buttons and releasing the first, though
// in that case keyRepeat is probably already stopped by screenshotTimer
keyRepeat.stop()
keyRepeatDelay.stop()
}
screenshotTimer.stop()
lateScreenshotCapture = false
}
Here is the full finished product — you can save it as /usr/share/lipstick-jolla-home-qt5/volumecontrol/VolumeControl.qml
The last one: the patch is tested with 2.1.1.26. I do not think that there are major changes in that area in 2.1.2, but bear it in mind.
Nice @figgis-diggis
So........why not package it up an offer it on Openrepos? :)
More users will try it if it's packaged/ready to install.
Spam Hunter ( 2017-11-04 13:45:38 +0200 )editI reckon that the fact that volume is changed when you try only to change the track makes it... e-r-r-r... not production-ready :)
Still if anybody would like to pack it for patchmanager, I'm all for it. Frankly, for now I'm a bit reluctant to study the way its rpms are made (I'm more or less familiar with the .deb format only).
If there would be no better suggestions I think I will just add to the keyRepeat line that will change the volume in other direction (so it would change back and forth when track is changed), but that might prove to be quite irritating when listening in low-impedance headphones.
figgis-diggis ( 2017-11-04 14:16:23 +0200 )editAhh, fair enough, I typed before I actually applied thought to my comment and should have re-read your post before commenting.
With regard to packaging; there is an excellent guide on TalkMaemoOrg for packaging RPM's (I know you stated your reluctance to study), but I learned how to make packages from the same guide. I'll post the link anyway; http://talk.maemo.org/showthread.php?t=92963&highlight=rpm+packaging+for+noobs - Schturman the author, is a helpful chap should you get stuck with the guide.
Spam Hunter ( 2017-11-04 14:30:28 +0200 )editOk, many thanks for the guide!
figgis-diggis ( 2017-11-04 14:38:53 +0200 )edit