A Purpose for everything

When we were porting Kamoso to Qt5/KF5, at some point I realized that it was about time we came up with whatever we’d want to do with sharing. Kipi is definitely an interesting technology, but no matter how I looked at it I found that it missed an iteration in the concept. In some aspects it’s very specific, in some others very broad. In fact, I already tried to improve it, back in 2009.
My conclusion was that I wanted to take a step back and re-think what I wanted because I don’t think it’s just about images and it’s not even just about Importing and Exporting.

• Is Import/Export really special?
• What do we want to integrate?
• How can we simplify the implementation as much as possible? Having as many plug-ins as possible is a must.
• What are other platforms doing?

This took me a while to figure out and it’s probably not ready yet, but since I needed something anyway I decided to just go for it.

What?

The idea is that at some point when developing an application you’ll need to fulfill different purposes (or desires, as some like calling it). At this point we’ll want to integrate the possibility of providing an action with all the information needed to fulfill it.

This purpose will have different fulfillment propositions, which we’ll need to provide a list with the alternatives and then be able to go for the one the user prefers.

Example 1

In Gwenview we want to be able to share the currently displayed image. To do so, we’ll get a toolbar button that on click we’ll get the 2 more likely alternatives and a “More…” option that will open a dialog that lists all the possibilities.

With all the provided information, we should be able to perform the export with minimal and integrated configuration. The different alternatives could be exporting to imgur, saving the file locally, upload to my ownCloud or my Facebook. For this, note that any configuration will seldom be needed.

Example 2

We’re reviewing code in KDevelop and we want to tell on someone we messed up. KDevelop can integrate the “Call” purpose that will propose us all the different ways to get in touch of the disaster perpetrator.

Example 3

The QuickShare plasmoid has a patch file dropped on. We receive the alternatives which can have any mime type: text files, binary files and any specific format (such as text/x-patch or text/markdown).

Example 4

An application wants to show us a location in a map. Instead forcing into some implementation, it will request Purpose to show a latitude and longitude and the user will decide where to check it. Alternatives could be OpenStreet Map, Google Maps and Marble.

How?

I came up with a small proof of concept to be able to start getting things working and I even adopted it on a couple of projects. It’s working well but I’m still a bit afraid of committing to an API. As a first step, I’m here explaining it for you all.

At the moment the API is really simple, it consists of 3 C++ classes:

• AlternativesModel, the interface for clients.
• PluginBase to be implemented by each plugin.
• Job which will be re-implemented by the plugin and tracked by the client

Then there’s some QtQuick components built on top that simplify the integration on QML applications. We should get some QtWidgets components as well, as soon as we have to integrate it on a QtWidgets-based application.

The AlternativesModel will receive a PluginType string which defines what kind of plugin will be used and the input data. The plugin type will define what information needs to be provided and what output will be received. Then the model will be populated with all the plugins with the said PluginType. The plugins will be able to specify a set of constraints, so the model can filter them out in case they’re not a good fit, and a set of configuration variables. These configuration variables are required to run the plugin and if they’re not provided, the application will need to show the user interface provided by the plugin, which is implemented through a QtQuick file, for now.

For some more precise information, here’s

TextField { id: url }

Purpose.AlternativesView
{
  pluginType: "Export"
  inputData: {
    mimeType: 'text/plain',
    urls: [url.text]
  }

  onFinished: {
    console.log("Done", output.url)
    if (error!=0) {
      console.log("error:", errorString)
    }
  }
}

Where are we?

It can be used now. It’s already integrated in the QuickShare plasmoid in kdeplasma-addons and in Kamoso which should be released eventually. Still, I’d like to see other use-cases being implemented and developed. The biggest void I see is plugins: getting Google+, Twitter, Facebook, ownCloud should be easy but needs to be done. If somebody is knowledgeable about such API’s and is interested in KDE applications integrating them, please step forward!

Additionally, if you think your application could use some purposes or that you have an idea of a new purpose that will change humanity, don’t hesitate to get in touch. We’ll change it together! \o/

Now here’s a screencast of the work in progress (especially the UI, eh..)

PS: Video uploaded using Purpose as well!