I came to the sprint hoping I could iterate 2 issues I’ve had been trying to get sorted with Plasma for a while:
Integration testing for plasmoids
Discuss how to keep pushing Discover for the next releases both with Plasma and the VDG.
The new testing infrastructure is in place and I hope I’ll get to merge soon this week. Feel free to peek: patch1 and patch2.
This is very important because it will allow us to make the testing of plasmoids systematic, to some extent, making it easier to develop plasmoids and containments while maintaining and increasing the delivered quality.
Regarding Discover, there’s lots of ideas. Definitely far more than we can materialize. For now, we’ll be delivering a much more polished experience for 5.6 both on the strictly technical side (better appstream and PackageKit integration, better use of QtQuick in some areas) as well as on the looks side, mainly thanks to Andrew and Thomas who keep pushing me whenever something is not entirely perfect, which is awesome.
Visual Design Group (VDG)
The first special thing was that there was a VDG sprint in parallel. It wasn’t VDG people who joined us, but an actual sprint. This was especially good because it allowed for a fluid back-and-forth of ideas. It’s especially important both to have some designers full of dreams kicking our asses from time to time, as well as some kind of pragmatism back to them so the good ideas can end up being part of our workflows.
Another special thing about the sprint was having the WikiToLearn team over. It was their first actual sprint as well as first time we all met together in a KDE event. I think it worked great, despite being different communities in nature, it’s interesting to see how synergies kept happening. I’m sure there’s good space for collaboration and I’m looking forward to keep working together.
Apparently they have a particle accelerator there. What?!
Some days ago I started wondering about containerized applications, I looked at a few alternatives and then decided to give xdg-app a go. It took a while, not really because it’s especially hard, but mostly because I’m rather stubborn, then I decided to ask Alexander Larsson and he guided me quite well.
All in all, it’s rather easy, it implements a packaging format, but one that I feel KDE can maintain reasonably easily. I set it up in 2 chunks, copying GNOME’s approach: one repository for the run-time (that includes Qt5 and most of the KDE Frameworks 5) and then another one that can build applications. One thing we could do now is set up servers that built nightly versions of our applications, I’ll have to ask the sysadmins how do they feel about it.
Anyway, you’re waiting for screenshots and I’ll give you screenshots. Some problems are still obvious, but it’s a first step. Patches welcome! \o/
One of the problems we’ve historically had in the GNU/Linux world (and especially in KDE, since we’re cross-distribution) is that we’ve always had a hard time at explaining how to install our applications. Basically because it’s different on each distribution.
My first approach to this problem was creating Muon Discover but that’s clearly not enough because, in the end, we seldom look for new applications. Often they will be recommended on a blog post or forum and we’ll want to install it. But then, while recommending it, it will either be a vague “you should try KMail” or a “you should ‘apt-get install kmail’ or whatever applies to your distribution.
What I’m proposing today is to embrace AppStream at the level of URL handlers (for web browser integration). AppStream shows GNU/Linux distributions maturity by offering a solution by letting the upstream projects set the identifier in their appdata.xml file (among other things) and then let distributions name the package however they want, rather keeping to push different naming schemes down each other throats.
AppStream has been supported in Discover for over a year now (only for PackageKit so far) and, since introducing this feature is straightforward, I implemented it in master.
If somebody wants to give it a go, test master and click here: KMail
I think this will be beneficial not only for KDE but any project packaged on GNU/Linux distributions that have a presence on the web and need to find their way in users’ installations. This will of course be limited to getting the URL scheme adopted by our peers.
/me winks at Gnome Software and Ubuntu Software Center.
KDE Connect is nowadays on a sweet moment where many things can happen. This is an interesting moment to sprint, because it will allow all of us to work together on interesting features that can then be merged at once with greater impact.
The things that are the most important to me are:
The Plasma Phone port. See more below.
Improvements on the Plasma Desktop integration. Currently it’s a bit weird. It mostly works, but then it’s currently lacking any interaction with the remote devices. We should review what it does and what can we do to offer what the user actually needs.
Using the phone (or any other device) to transparently provide data to the desktop system. We have many interesting listed ideas. Use the phone to provide location, the phone’s microphone and camera, etc.
File system synchronization
What will I do?
One of the things I’ve been working on lately is a new KDE Connect client. Initially with the Plasma Phone in mind, this new application opens a new window of opportunity also on other platforms. First of all, it should be right away usable on Jolla (when they adopt a saner set of dependencies) and the Ubuntu Phone.
From our point of view, one of the biggest problems of KDE Connect is that we have a hard time to pivot over to other deskop-based platforms, mostly because our desktop approach so far is a plasmoid, which isn’t very portable. Having a standalone application will help as well to reach such platforms as well.
Another thing I’d like to work on further is KDE software integration on Android. Things should be set by now, but we need work to shape the path further. Things like setting up the KDE Frameworks 5 CI for Android for example will be a huge step forward. Also building some other application for Android, will help us get a better overview of the current state.
All of this will happen in the next KDE Connect sprint within the Randa Meetings. If you like KDE Connect and wish it to bloom into the tool we’re all looking forward to, consider donating!
One of the things I’ve heard on every KDevelop sprint is: we should be light, like Kate but with our added value.
We’ve addressed this in many ways so far: we’ve optimized the code for performance so it’s more responsive and starts reasonably fast, we’ve made sure most done is accessible using the keyboard so we don’t feel clumsy and overwhelmed by all the options.
Today, I wanted to reflect on 2 things:
What do we miss to be that ideal light editor?
What’s a good lightness inspiration?
Otherwise, TLDR, there’s a video below.
What do we miss?
The avid Planet KDE reader will know that being light is a complex concept, there’s many ways to perceive lightness: Is Kate light? Is KWrite light?
When we talk about lightness, we generally refer to different metrics. If something is worth waiting for, we wait, and that’s fine. We don’t want to feel we’re wasting our time. A good example there I’d say it’s Chromium. It’s probably one of the heaviest beasts we run on our systems. Nevertheless, it doesn’t feel as such (at least until you run out of memory).
There’s another point of view: We bomb users with features. In fact, it’s awesome to have features and it shouldn’t be a trade-off. On the other hand we’re never using all features at the same time, optimizing that would be awesome. We should work on it: identifying the different workflows and creating user interfaces that enable them.
What’s the role model?
One of the developments that have struck me the most during last years is Kate. Instead of focusing on the editor, it went the KDevelop route: it has started to offer all of the information at once (especially odd, given that there’s quite some feature overlapping).
More generally, if I look at what others are doing, I see two major groups:
On one hand, there’s atom.io and sublime that seem to be doing something very similar. Most of the components they have we have as well, but then the focus is rather different: they have very few visual interaction components, mostly just the menu, so you can just play with the text and you know where to go look for stuff. UI’s are usually embedded in the source code view.
On the other hand, there’s Eclipse or Visual Studio that do something quite similar to what we do: present everything in the traditional desktop application way with docks and a couple of smart tricks, because they try to tackle the whole workflow problem.
I understand how we got to where we are, but I also really understand why people can prefer something like atom. My feeling is that “It doesn’t make me feel like I should be debugging while I’m coding”, even though they oversimplify on some areas.
What do I propose?
I decided that I wanted to feel what’s to work without all the clutter, so I implemented a Concentration Mode for KDevelop. I stripped most of the visual stress, so usually we’re left with the good ol’ katepart editor, with all KDevelop‘s features. I’ll become my own guinea pig: now that I have it clean, how do I use the tools? Can I still do the same things? As discussed on the mailing list, this has had some fruits already.
I think it’s really cool: code, code, code, quick open and shortcuts.
Now, a bit of a video implementing what I discussed here.
What to look for:
We get to hide the navigation handle, leaving only the toolbar, the document title and the central view.
The toolviews are still accessible.
The menu is still accessible
For now, I can decide to just see what I’m working on. Now.
The world changes, and with it, we change too. For this new version of Kamoso we wanted to iterate what we’re presenting.
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.
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 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.
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.
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.
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.
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.
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).
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.
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:
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.
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..)
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.
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?
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.
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.
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?
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.