Category Archives: kamoso

Suggesting new ways: Kamoso 3.0 Technology Preview

The world changes, and with it, we change too. For this new version of Kamoso we wanted to iterate what we’re presenting.

The Camera

Since we’re using GStreamer, we could take advantage of newer technology available there. Now we’re using camerabin for the video capture (in contrast to using v4l2src directly).
This will offer a better experience, with less tweaks on our side, that will definitely improve the end-user experience.

User Interaction

The whole application wasn’t rewritten, but all the UI was. We have a re-designed interface that integrates some really lean and meaningful animations and sorts the components so that we can get a simple, dialog-free UI.

Sharing

Sharing is probably the most important feature in Kamoso besides video capture, and we took special care of it. We adopted the new Purpose technology that is seeing its light for the first time with this Technology Preview. We want to make sure that we can offer the best solution by making sure it integrates properly on our UI and it can also be integrated on other parts of KDE. This way we’ll be able to come up with an adequate set of plugins and enjoy them all in community. For now, we have: KDE Connect, Imgur for images and YouTube for videos.

Where to find it?

I put together this little list, so everyone can find the tarballs and packages (on the distributions that managed to package it):
https://userbase.kde.org/Kamoso/3.0#Alpha

We need you!

We need special help with:

  • Testing, on more cameras, more hardware.
  • Artwork, especially icons.
  • Coding, especially Purpose sharing plugins (Facebook? Twitter? ownCloud?)

But anything else is welcome, as always. Please get in touch!

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!

Kamoso Sprint

Kamoso sprints are special. There’s no travelling involved, there’s no big deal other than managing to find the correct day to meet with Alex Fiestas and spend some KDE time.

I think that Alex will agree with me that it was quite a productive time, we got quite a lot working and the rest more or less sorted out. I wanted to make a lengthy blog post about how did we spend the night.

Since it’s already late, I’ll leave you with this video and some pictures. I hope you’ll grasp how awesome it is to work on KDE. Again. 🙂

coffee kdevelop tea

Cheers!! \o/
(say cheeseeee!!! 🙂 )