Which additional quick actions would you like to have?

At the beginning, just to build on available options:

Some lines should be added to DBusAdaptor block of /usr/share/jolla-clock/clock.qml:

    signal newTimer
    onNewTimer: {
        pageStack.pop(mainPage, PageStackAction.Immediate)
        mainPage.newTimer(PageStackAction.Immediate)
        mainWindow.activate()
    }

Then a file (say com.jolla.clock.timer.conf) on /usr/share/lipstick/quickactions:

priority=9
requires-package=jolla-clock
icon=icon-m-alarm
title=clock-me-new_timer
translation-catalog=clock
remote-service="com.jolla.clock"
remote-path="/"
remote-interface="com.jolla.clock"
remote-method="newTimer"

I hope @Markkyboy can help in packaging.

@AliNa - indeed! :)

Made a patch for this and stopwatch.

I agree with you and that's why I am reluctant to vote for or implement quick actions that merely replace launching an app. Quick actions make sense only if they represent a shortcut for "lanch an app - select something from a menu - scroll down a list of options - enter another menu - do the action".

For example, "Connect to internet".

It would be one swipe quicker, if you had the option to access shortcuts/quick actions also from home screen: https://together.jolla.com/question/116268/access-favorite-settings-shortcuts-also-from-home-screen/

That's a good idea. They make more sense on the home screen than the events. If you're scrolling down your feed, you get the old problem of having to get back to the top to access the pulley. You don't get that problem on the homescreen.

This is maybe a new (important) question and not an answer to the current question... In any case quick action are not quick AND not easy (a sort of slalom of horizontal and vertical movenents). So my suggestion: carousel with 3 faces: home, events, actions. If you reach home, then go left tovevents or right to actions.

+1 for quick actions in the carousel.

And was something Jolla promised would be returning in Sailfish OS 2.0.0.10

What exactly would be the point? You already have a shortcut to Settings, it's right there in the launcher. Swipe up and tap is one action quicker than swipe right (to get to events view), swipe down (to get to the shortcuts) and tap.

Shortcuts only make sense when they provide a shorter path. Hence the name, shortcut.

@pichlo Did you vote this down? This question is a poll. Did you ever see someone pull another ones arm down when he tried to raise it for his vote? If you don't want it, just don't vote for it. ;)

No need to decide for me if this is quicker or not. As I use the settings rarely I have it in an app folder and have to scroll to get to the bottom of that folder. So it's swipe up, tap, scroll down, tap for me. But I do not need many quick actions or shortcuts so there is room for the settings app.

Thanks for letting me decide how to use my phone and what I want.

Sorry, my understanding was that you can vote up or down. Now unvoted, though I doubt it would make such a difference.

If you, by your own admission, "use the settings rarely", then why do you need a shortcut?

(Rhetorical question, you do not need to answer it.)

If you think your question is rhetorical then you will be surprised because I do have a valid answer, I think:

I want that shortcut there because I then know exactly where to find the settings. When I want to go there I want it to be quick and intuitive. It's intuitive because it's among the settings shortcuts (which are strongly related to all settings). It's quick because I don't have to search my app drawer and remember the colour and shape of the icon what would be easy when I used the app regularly.

So because I use it rarely I want (not need) that shortcut.

Thanks for your answe. It makes sense, but is not enough to convince me. If you want to have an icon in a known place, just move it there.

I started typing the following before your update so please keep that in mind. After a serious consideration, I have decided to vote this suggestion down again. Like in any other vote, I expect to have the right to vote for, against or withhold my vote. In this case, I not only do not want the shortcuts to apps there, I actively want not to have such shortcuts. (I hope the mountain of double negatives did not confuse you too much.)

I think it is a slippery slope. You want a shortcut to one app, @gri4994 wants another, and before we know it, the whole app launcher will move there. Better nip it in the bud while we can.

Can anybody please help?

I made a conf file in /usr/share/lipstick/quickactions containing:

priority=8
icon=icon-m-message
title=jolla-messages-la-new_message
translation-catalog=messages
remote-service="org.nemomobile.qmlmessages"
remote-path="/org/nemomobile/qmlmessages"
remote-interface="org.nemomobile.qmlmessages"
remote-method="newMessage"

and added some line to the file /usr/share/jolla-message/messages.qml before the last line:

    DBusAdaptor {
        service: "org.nemomobile.qmlmessages"
        path: "/org/nemomobile/qmlmessages"
        iface: "org.nemomobile.qmlmessages"
        signal newMessage
        onNewMessage: {
            mainWindow.newMessage(PageStackAction.Immediate)
            mainWindow.activate()
        }
    }

And of course import org.nemomobile.dbus 1.0 at the first lines.

It does work, but when the app has not been open before tapping on quick action, it will crash after about 15 sec. I can't figure out where's the problem. Can it be a bug in Messages app?

@Andy Branson, @lakutalo, @Markkyboy, any ideas? I think the problem is in dbus lines added. Do we need extra lines for Messages app to open with dbus calls? I couldn't find how People and Phone apps open Messages to send SMS.

@AliNa - I agree, I also think your problem is in the added DBus lines, but unlike some of the more talented coders here, I have little to no idea what to change/edit. I just don;t understand the language yet. i have played around with different lines of code, but in truth, I really do not know what I am doing!, I wish I could help directly, but you seem to be more knowledgeable than I.

I found something in /usr/lib/qt5/qml/Sailfish/Contacts/ContactCard.qml lines 158-165. The dbus interface is defined in ./common/MessagesInterface.qml. Now I'm trying to use that dbus interface but don't know how to.

@Markkyboy, thanks, but the same as you here. I'm just looking at existing examples and playing around.

There happens to be a nice thread containing links to online literature, if you haven't noticed. But honestly, who's got the time to read? I've encountered similar problems with my experiments on creating a new email from QA, which even got minus-voted recently (roflmao). So I will also have a look at your files and try my best applying a monte carlo approach of development - trial and error. :)
EDIT: I managed to open the Messages app for a specific, existing number by adding these lines

signal newMessage
onNewMessage: {
    messaging.startSMS("*existing number*")
}

to the DBus section of /usr/share/voicecall-ui-jolla/main.qml and of course adapting the conf file accordingly. But that's not what we wanted, though it could give us a clue. In fact it's the same you might already have found out yourself through your last hint. On the other side of the detonation I tried to set up a pristine dbus-service in /usr/share/dbus-1/services for our ui action with jolla-messages, but again no luck, again vanished after 5s - wicked.

@luen - https://openrepos.net/sites/default/files/packages/1290/quickaction-csd-0.1-1.noarch.rpm

@Markkyboy Thanks!

Thanks for contributing!

Indeed, well done! Open stopwatch is a useful quick action.

Nicely done @AliNa - another working quickaction! I can make a package for this, but I am very unsure about the integration of the additional code into 'clock.qml' - other than to leave the additional lines in 'clock.qml' upon removal(uninstalling) the quickaction and then only removing the .conf file and not the changes within 'clock.qml' - would it be considered a 'bad practice' to leave such changes when removing the related .conf file?

@Markkyboy, IMO it would be best to tag the extra lines of code with special comments when installing the package, and find and remove those lines when uninstalling - if still existing, since an OS update might replace respective conf files. @AliNa, would you happen to know how to pass parameters along with the signal (remote-method)?

thanks @lakutalo - I understand what you're saying, but I have little to no idea on how to do what you suggest. What would need to be done to the 'spec.file' for this to happen?, could you show an example?

Thanks man, nice information! Useful.

Useful indeed! The tricky part is to find the right place to drill the hole for the DBusAdaptor.

I found them in the appwindow file (for the clock app, see jolla-clock/clock.qml), a seperate dbusinvoker (for the jolla calender) and the firstpage (for the camera, see jolla-camera/pages/camerapage.qml).....

I have found most of the existing ones and turned them into a few RPMs and a few other users here have also shown/mentioned on how to add a dbus section to a file, but as @lakutalo points out, it's knowing where to actually place the lines of code. Most of the time when I've tried it, it's resulted in a black and white flashing screen - but I'm not surprised, as I know very little about correct syntax and placement of squirly brackets/spacing/distance/etc (if that makes any sense!, I've still much to learn), but your explanation sheds a little more light on the subject.

Also, you mentioned about adding the line 'org.nemomobile.dbus 2.0' - why 2.0 and not 1.0 - what is the difference between the two?

The choice for org.nemomobile.dbus 2.0 instead of 1.0, comes from the jolla-clock which uses the 2.0 version. Please let me know if I can be of any help...