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/
I’m sure many of you already read about Clazy. For those who didn’t, it’s a quite convenient tool for checking your code and making sure you’re getting Qt’s API right. There’s some non-trivial quirks here and there that aren’t very important but once polished can push your system considerably, especially on those cases that are ran repeatedly.
Recently, I introduced a -DENABLE_CLAZY=ON setting on extra-cmake-modules, that comes quite handy so if you want to run it on your project you just need to enable it and then Clazy will get rather verbose (although with arguably no false positives). It will work on any KDE project right away, since it comes from KDECMakeSettings.
Note: This will work provided clazy is installed and you’re running Clang as a compiler.
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!
When approaching this issue I had been thinking about the issue for a while. I had mainly 2 problems: I was rather frustrated with previous Linux-based systems so far and the one I liked didn’t really scale for us. One thing was clear: We had to stand on the shoulder of giants.
The first one to think about was the N9 SDK (and by extension N900). It used to have a scratchbox-based system that emulated the one on the phone. It was useful for testing the applications locally on the device (although I actually never used that), I think that this one had both cross-compilation toolchain and base system, as well as the host and it used QEmu if a host executable was run. It felt weird because it shoved you in a weird system and you had to pull your code in weird ways to fetch it. Otherwise it worked great. Afterwards, madde came. It’s what I was looking for really and played quite well with cmake, actually when I published the steps on how to develop for the N9 it’s what I used back then, but it probably was too late for it to become a thing I guess. Also many people weren’t too fond of it, as I learned after some time.
The Android NDK is the other I took into account. I don’t think it would be fair to compare anything we could do with the actual Android SDK, so I’ll limit myself to this one. This one ships the complete cross-compilation toolchain and runs native (similar to the BBX SDK, IIRC).
For the N9 approach, I would have had to concentrate on figuring out technologies that were long dead (and probably should remain). For the Android approach I found 2 big problems: We have to actually work on generating the actual binaries (which means, from any platform to a specific ubuntu-vivid-arm target) plus all the dependencies. This meant, creating a new distro, and we already had debian/ubuntu for that, let’s use debootstrap! Oh, wait…
For a start, I took what sebas already started, in fact. Using debootstrap to create a chroot jail that could cross-compile the projects into our platform. This started to prove feasible really soon, as 2 or 3 days after working on it (and after fixing some issues that kept arising, mostly on KF5 itself and packaging), I already started to output binaries that could be deployed on the device.
My IDE is outside of the jail, so there isn’t much we can do to integrate at all (we can’t access the build directory, and most of the data in it isn’t too meaningful for the outside anyway). A solution would be to ship and run the IDE from within the SDK though.
You need to be root. Not only to generate the system, but also to run it.
An idea I wanted to approach was docker. Everyone on the web world is shit-crazy about it and it’s deeply based on traditional Linux, so there’s quite in common already. Doing something similar to the deboostrap there was a piece of cake, and I managed to re-use the set up code I already had for the previous version.
Also everything is inaccessible from the IDE
I’m less aware of the limitations I’ll find.
Still, this second approach feels lighter and it’s quite fun to investigate something new like that.
It seems that the jailed systems are the way to go, at least for now, so the tools I’ve created so far assume that they live in the jail as well. So, what do we have?
createpkg: Makes it possible to create a deb package that can be sent to the device for testing. It’s much simpler than the simplest deb package ever, but it works. Much better than sending executables over, much better than learning how to package for Debian.
deploypkg: sends the deb file, installs it and starts the application.
click-get: Downloads a click file from the Ubuntu Store, it’s harder than you’d think.
kdev-debdeploy: Does it all, inside your good ol’ IDE.
To be done
Workflow: Figure out a way to deploy KDevelop within either jail, but then we’ll also be able to use kde-debdeploy, that does mostly the same as these tools, integrated on the IDE.
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.
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!
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..)