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!

Identities, I usually don’t stop being myself

One of the most interesting developments I’ve seen recently inside KDE is KAccounts (or Web Accounts, as it used to be called). It’s not even a KDE project, but a project Nokia started some years ago, I’m guessing that on MeeGo days.

Why do I care?

As a developer it’s always very important to know what resources you have available. The more you have, the richer the users’ experience will be. Resources are not only hardware but often just semantically-structured information. For example, KPeople helps us tell apart the contact list and offers us people instead or Solid, that turns the different ways of exposing the hardware information into something easily consumable by front-end applications.

Now we’re talking about identities. We don’t exclusively rely on local data anymore, I think that’s a fact nowadays (and even 5 years ago). Our disks are just another place where we store some of our data. KDE projects must be prepared to easily offer such workflows. One of the important parts to do it properly is authentication:

  • We need a list of available services we can use.
  • We don’t want our users requested identity authentication all the time.
  • We don’t want each application to implement the N authentications algorithms of the N different providers our users will eventually have.

Why do you care? (as a KDE software user)

First of all, you want your developers to have the best tools (GOTO: “Why do I care?”).

There’s a more important issue to figure out, more ideological than technical: We ask service and software providers to use standard specifications to improve interoperability, but then in practice we are seldom leveraging it. The case-by-case set up burden makes it hard for users to have everything configured properly. An example for this is ownCloud integration. I know a couple of people running an instance, but they seldom integrate it in Dolphin, but even if they did they’d still need to integrate the rest of provided services, such as calendar, contacts, etc.
We want to tell our software what providers we have available, those providers will provide different services. The software should integrate as much as possible with those services.

How can I help?

  • Testing: There’s a lot going on, thorough testing and ideas is important. Both when it comes to making sure everything works as expected as well as what software should adopt KAccounts. It will already be available with KDE Applications 15.04.
  • Developing: Make sure your application of choice uses KAccounts to figure out the configured services. Here’s a good place to find documentation: API, and an example use-case.
  • Promotion: It’s important to reach out to service providers, make sure they know there’s such possibility and hopefully they can help us work better with their services (hey! by the book example of a win-win situation!).

Nowadays our computation experience is spread among different services and we need to be smart enough to understand how our users will adopt them and make it as transparent as possible.
AccountsSSO and KAccounts are a solid step forward in this direction, let’s get back in control of our data!

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!

Hacking Free Software, a different point of view

I joined KDE to hack. I wanted to create new thriving technologies for the world, to create tools, to learn, and, in general, to add some pragmatics into my perception of technology.

The one thing I didn’t really expect to do is all the rest.

I starting actively contributing to KDE in 2007 and I started contributing to both KDE Edu and KDevelop almost at the same time, I’ve talked largely about this aspect already so I won’t expand. I want to explain the rest.

The Community

My first Akademy, in Glasgow. felt spectacular to me, I made good friends and I remember having very deep experiences. With Albert, Anne-Marie, Rafael, Alexander, I loved the feeling that working together we could do great things and also that I could learn a lot over here. Those who know me know that despite being quite an introvert I tend to start talking a lot when I get engaged, and I remember talking a lot over there.

Foreign country, people, language, nothing mattered, the only important thing was to learn and to hack. I remember partying lots and hacking lots just as well over there. I’m explaining this because there needs to be an explanation, why someone who just wanted to hack ended up founding KDE Spain or joining the KDE eV board?

KDE Spain

Later in 2007 we organized the Akademy-es in Zaragoza. Different setting, different people and different perspective. There you did’t talk to people who want to work with you, they wanted to be convinced about KDE, about Free Softwre. I enjoyed it, it was healthy to put in perspective everything I was doing. Thinking about how to motivate others helps a lot to redirect oneself, to keep with the feet on the ground.

Later on, we decided to start KDE Spain, which was basically the intention to keep doing that in the future. Reaching out to local people, those who you won’t find on our mailing lists, at least not before you get there. KDE Spain has been to the day one of the projects I’ve invested myself the most.

KDE eV

I joined the KDE eV late in 2008. I was by then convinced that without infrastructure all good to be done in the project is in vain. We’ve all had this feeling when you see another project offering something that you have had for years unnoticed. It requires work, many pieces coming together.

Community software development (or any development for that matter) is much more complex than one would want. It needs organization and expertise in crafts one wouldn’t think before. That is one of the main reasons to push for KDE to me: having people from different fields coming together to make wonderful things happen. (Community as a Service, CaaS. Have we coined that yet?)

Barcelona Free Software

Life is all about balance. From generic to specific, from big to flexible. Life artifices made it so that my city, Barcelona, has become a focus of the KDE development and we had to take advantage of the opportunity. This time we went full local, we started to gather many people knowledgeable about KDE around and instead of creating yet another KDE thing, we created a group concerning Free Software in Barcelona.

With the huge help of Martín, we’ve built an open group to meet and discuss about Free Software in a nice and relaxed setting. It was a piece I always missed in the puzzle.

Barcelona Free Software logo, thanks to Jens Reuterberg

  • How to make the world use Free Software?
  • For example, people around me. Are we offering what they need? What do they use?
  • How come I don’t even know them? What do they create?

Work with us, become the KDE e.V. Executive Director

Haven’t you made your mind up yet? KDE e.V. is looking for a new Executive Director and we want you on board!

As Lydia described, KDE has many things to offer and many goals to achieve. We are looking for a talented professional who will push the organization, alongside the rest of the Community, and help create the useful technologies of today and tomorrow.

If you like freedom, challenges, getting to know people from all over the world and new technologies that make people thrive, don’t hesitate to look here and send us your CV.

Communicating from Plasma 5

Porting KDE Telepathy to Qt 5 and Plasma 5

I started working on that port back in the last KDE Telepathy sprint in Barcelona last April. Back then, I started to work on it because I have been doing heavy usage of the KTp plasmoids back when using the KDE 4 Plasma series and I didn’t want to live without them. Back then, I only ported the minimum parts of ktp-common-internals so it would work with KF5, as well as the plasmoids. It was quite some work, but definitely worth it since I’ve been using them ever since, and it’s worked wonderfully.

Last week I started working on those ports again, this time trying to start get all of them ready for end-users, first step being starting to port the rest of modules. It’s worth mentioning how good the response has been, given that many people chipped in and gave some modules a go. It’s a bit weird to do this kind of porting in KTp, because there’s tons of little repositories to port rather than a big one, but I guess it’s kind of part of it’s beauty anyway… 😉

KPeople as a KDE Framework

KPeople is a Framework for fetching contacts from different sources (Telepathy, Akonadi, Facebook, etc) and unifying them into a same model,

An important part of making sure all of KTp works is ensuring that its dependencies are up to speed and this time the one I’d like to bring some light to is KPeople. The port is ready really, only depending on having some of its own dependencies from kdepimlibs in a releasable state, but it’s also quite in shape too. It’s a framework I’d really like to see shining in the next months.

Furthermore, I finally managed to find some time and get the automatic contact merging back on. This I started more than a year back and then Franck Arrecot worked to make some GUI interface for it, I think it’s quite interesting. Take a look into it if you think it’s interesting. :)

We need you!

Last but not least, there’s still lots to be done. I’d like to aim for a nice and clean release of KTp by the end of the year, ready to be shipped with Plasma 5.3 and the applications, if the maintainers allow so.

So if you’d like to help, you can take a look at this Kanban board we created and take the tasks you’d like.

Porting Muon Discover to KF5

Muon has been a project that I’ve been very eager to port and iterate for a longtime. I’m happy with the 2.0 series, lots of changes were made and it has served us well. More importantly though, we have a solid technology to keep pushing our work on.

Porting

Now the first change has been the port to Qt5 and KF5 and adoption of QtQuick 2. This has been one of the few projects that have suffered from it, especially because we did a couple of hacks so that Muon Discover would integrate with the rest of applications’ look and feel. In any case, it’s sorted out now, we adopted the new QtQuick Controls and it works quite good, only problem being the usage of QQuickWidget, but that will be solved eventually, when we have everything we need in place to take the next step towards better integration between KXmlGui and QtQuick.

What to expect?

The most important news is that it will be as good and fresh as it used to be, integrated with the newer look and feel themes, capable of offering different sorts of data, such as applications, wallpapers and plasmoids.

Furthermore, some new features will be introduced with the forthcoming Muon 3.0 that will change how we integrate Muon on our systems. First of all, Appstream is being adopted for good. Now it will be possible to get a useful PackageKit backend, which has been adopted recently.

  • Additionally, for the ArchLinux fans, I did some fixing on the PackageKit libalpm backend so now it can be used again. 😀 Still, work on the Appstream set up is needed and help is very welcome.
  • Since I wanted to use a good PackageKit reference implementation, I looked into Fedora. I’ve been trying to get it working, but haven’t succeeded that much yet. I expected Appstream to be a first class citizen there, and things keep falling apart. We’ll have to work more in this area.
  • Kubuntu will remain using QApt for now. It seems to be working properly and there’s no intentions to change. Debian has also been ported to use use the same backend, we are pending though on some decisions to be taken with regards of metadata sources, that is, Appstream again.

**shrug** Looks like we’ll have to give a good push to Appstream!

Future

I would like to see different Plasma-oriented distributions embracing Muon as a resource management front-end. So far, resource management hasn’t been part of our user experience, with the exception of KNewStuff.

Additionally, there’s a forum thread where a new graphical design is being worked on so it doesn’t look all that clunky (especially managing to make QtQuick Controls applications look good).

All this is already available on our Git repositories. A final version will be released early 2015 together with Plasma 5.2, although I’d like to roll a stable version first, so distributions can start adopting it.

Mathematics that you can touch

These last months have been intense, so intense I needed a bit of a distraction. I’ve always felt some kind of curiosity for the world of 3D printing and, as I’ve said in different occasions, I always push KAlgebra to the limit when I have the occasion.

I had been researching, I’ve never had a 3D printer and I probably won’t have one in years, but I still wanted to figure out how to get do something there. First, I went through many 3D printing services and looked through the different supported formats. To be honest, I implemented the one that looked the simplest, it happened to work quite similar to how OpenGL works internally, so it seemed like a safe bet.

Once I had a working export algorithm, I chose an extremely good looking plot (thanks Percy ;-)) and then I uploaded it over to one of those 3D printing services. The website showed me a preview, it seemed like their software understood the format, so it looked like my job was done. I fiddled with it to get it printed in a reasonable size and submitted it to print and send. For the curious, here’s the formula I used:


piecewise { x^2+y^2+z^2<35 ? 2-(cos(x+(1+5^0.5)/2*y)+cos(x-(1+5^0.5)/2*y)+cos(y+(1+5^0.5)/2*z)+cos(y-(1+5^0.5)/2*z)+cos(z-(1+5^0.5)/2*x)+cos(z+(1+5^0.5)/2*x)), ? 1 } = 0

A couple of weeks later a box arrived to our office. To be honest, it was a bit weird. I was very excited, but then nobody else was when I showed it. Because it's math I guess, and it's boring. I felt a bit like when I used to spend my nights hacking KAlgebra around then show it around. Anyway, I'll say it. A 3D plot, in my hands, to play with them. How cool is that? :D

** crickets **

 

Now I'm sure you're excited and willing to try it. It will be available in the next version of KAlgebra, that will be released in the KDE Applications 2014.12, which by the way will be the first KAlgebra release based on Qt5 and KF5, and will be featuring many other new features.
And of course, it's free software developed in an open community! If you're feeling adventurous or you just know how to build KDE software, feel free to pull analitza and kalgebra repositories and give it a try! :)

Taking advantage of OpenGL from Plasma

I’m excited, and I hope you’ll be too.

David Edmundson and I have been working hard the last weeks. It’s not that we don’t usually work hard, but this time I’m really excited about it.

A bit of context: in Plasma an important part of the system drawing is painting frames (others are icons, images and the like). Those are in general the elements that are specified in the Plasma themes. These will be buttons, dialog backgrounds, line edit decorations, etc.

So far, to paint those we were assembling the full image in the CPU and then sending it over to OpenGL as a full texture, then we would do the composing of all the different frames, according to the information provided by QtQuick, through the Qt Scene Graph. There are 2 main problems in the current approach.

  1. We were maintaining huge textures in memory. Every frame was completely stored in memory and gpu memory. Which means that the bigger the dialogs are, the more memory we consume, even though the texture is flat.
  2. Every time we resize the frame, we have to re-assemble the frame in CPU memory and upload it again.

First: The 9-patch approach

First we made it possible to have the frames to be rendered by each different parts and assembled by the GPU. This wasn’t possible, because Plasma themes are quite complex, so now we have 2 different paths. If the theme element can take advantage of the optimization, it will use the new code, otherwise it will stay working beautifully on the former, thorough implementation [1].

Therefore, instead of rendering all the frame now we’ll be uploading 9 textures to the GPU, and let it either tile or stretch depending on the settings in the theme. This way:

  1. we are uploading 9 tiny textures rather than a big texture.
  2. when the frame is resized, we tell the nodes to resize and the GPU does the job [2].

Second: Caching the textures

Now everything was in place, we’d have many times the small 9 elements but we kept uploading them to the GPU over and over. It’s little textures, but it’s still better if we get to re-use what we already have. To do so, we’ve placed a little hash table that keeps track of the already created textures to re-use them. This way, we get to tell the Qt Scene Graph to use a texture that has already been uploaded rather than a new one. We’ve run some tests, here’s the result:

  • In PlasmaShell we get 342 miss and 126 hits, so roughly 25% of bandwidth and memory improvement
  • In KRunner we get 108 miss and 369 hits, so roughly 350% improvement on memory and bandwidth improvement.

Future, further work

Sadly enough, raw memory usage is still quite high, when running plasma shell on massif, we are still reported as most of the memory usage being in the GPU graphics card (or rather i965_dri.so), so we’ll have to dig it [3]. We’ve found some ways to improve this, for example by enforcing OpenGLES 2, but this requires Qt 5.4 which is due October. I implemented it nevertheless, and it works fine.

Being more precise, a big offender is using a wallpaper image. We’ve looked into it, the code looks fine, but then it makes a big difference, so big that I still don’t understand how it can be. A good suggestion if you’re testing Plasma 5 on a system low on memory, is to run it with the plain color wallpaper. We can save up to 30% of memory consumption, no kidding (it actually depends on who you ask, either massif, htop or ksysguard; but they all agree it’s a big deal). We’ve investigated a bit and found ways to improve the situation there, but if you are interested, feel free to join!

Finally, another problem with regards to memory consumption is QML. We make heavy usage of it and it shows memory-wise. We should see if we can adopt any optimization to stream-line our usage, but admittedly it’s much better than one would have expected.

Testing

If you want to give it a try, you can already find most of this in master, and it will be available from the next KDE Frameworks 5.1 release which will be available by the second week of August.

Hope you liked it, it was a great exercise to investigate all this! I learned a lot and gained quite some respect for the Qt Scene Graph and QML development teams. Keep rocking!

[1] More precisely, at the day, when there’s no hint-compose-over-border or mask-*-overlay elements

[2] an exception for it being (hint-stretch-borders and hint-tile-center hints, where we’ll have to re-render on resize it).

[3] David, Vishesh and I we all have Intel drivers, but I guess it’s a good card to test-case on, given how mainstream it is, currently.

Plasma Next: All for one, and one for all

I haven’t been directly involved in Plasma development in the past a lot, only since very recently, because of my job at BlueSystems. Ever since I started working on the Plasma Desktop Shell, I’ve had 2 important concepts in mind that I’ve tried to follow:

  • The desktop is the place people go when they want to be performant.
  • Let the user focus by offering simple concepts that just work.

So far it’s looking good, I’ve been using it on my system daily and I haven’t had many important problems. Interestingly enough, one of the things I like about Plasma 5 is how it doesn’t try to get you in a spaceship. It does what you expect a shell to do, we’ve focused on making sure this is done properly and that all the tools to extend it are there, in case you want to go crazy. But the Plasma Shell, Plasma is solid.

Going crazyEnhancing Plasma UX

I think we need to, we want to. We thrive on it. The reason we’re developing software is to blow your minds, our mind. On the other hand it’s harmful, it’s much easier to go crazy than to provide a meaningful set of polished features. And we want polished.

But we want features, I want to take advantage of our frameworks and integrate the technologies that drive our lives, everyday, more and more. That’s why I think we want to start working on the services and applications that will complete that Plasma experience that, in the end, will be slightly different for many of us. Because we’re not all the same.

Now let me list some technologies that I’d like to see grow and hopefully help push in the following months.

KPeople

If you think about it, the ways we communicate over the Internet today and the ways we did 10 or even 15 years ago are essentially the same: we still chat through test, audio and video; we still send e-mails and we still exchange files in unreasonably broken ways. On the other hand it feels different, I think mostly because of using many devices with different sizes.
We want our software to understand these concepts. Different people and even groups of people offer us very rich and colorful semantics we want to be able to embrace both from Plasma and applications.

Having the people around us easily accessible is very important to be performant while still remaining as a simple concept we all understand, we don’t talk to an e-mail account, we talk to a person; only in many different ways.

KDE Connect

If talking to others is important, talking to us is even more important. Everybody I know, works with his phone on the desk and some of them with a tablet in the bag. I don’t think it’s easy getting to be performant if we have to keep checking what’s up on different devices. Furthermore, there’s no technical reason for that, we have KDE Connect. It needs polishing, it needs love but it has huge potential.
One of the things I like the most about KDE Connect is that it’s really easy to adopt. You have it available today on Android (and therefore BBX, Jolla, Ubuntu Phone and a couple others that support android apps), it’s in the way to be on iOS and we have a library you can re-use to take it to your favorite platform, that is obviously supported by Qt 5.

There’s lots of barriers to break there, we want a cloud-based client so you don’t need to have all devices in the same room; we want to break the barrier and see it developed in those new platforms we would never expect to find them. Also we want you to explore with us and find the synchronization nirvana.

My Conclusion

Finding a balance between making something simple and solid, KISS style, and going creative doesn’t go well together, on the other hand Qt and Plasma offers us lots of flexibility, so we have ways to do so.

I decided to go with this Musketeers (or I thought) slogan because it depicts quite well how I see myself using my laptop in some time. Every time less about those little windows and more about aggregating my people and my self, through the different gadgets I carry.

Corollary

Last, but not least, as usual I’d like to remind you that want to help ensure all this happens in the best of the conditions, you can consider donating to the Randa fundraiser, where KDE will gather and come up with many tools that will render this possible, in the best of the conditions.

FreeSoftware to the fullest!