Month: June 2014

Plasma Next: All for one, and one for all

30 June 2014 / apol / 3 Comments

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.

Porting your project to Qt5/KF5

21 June 2014 / apol / 8 Comments

One of the things I’ve been asked recently quite often is about where’s the information regaring the needed port to KF5. I’ll use this blog post as reference.

Documentation

We have quite some documentation set up already to find your stuff. The ones I use the most are:

api.kde.org: The API documentation, the frameworks section. There you can find most classes documented, within its own module.
Porting notes: Whenever developing KF5, each not obvious decision we took was documented either here or in the api documentation. It’s especially interesting to look at this when hitting a deprecated class. If it’s not here, check the API documentation, if it’s still not there tell us and we’ll fix it.
Already ported code: We have a good set of ported projects, it can be interesting to look at them and see how things have been resolved. Look for a frameworks branch.
People: As a last resource, there’s always the community to give you a hand, notably in the #kde-devel IRC channel in freenode and the kde-frameworks-devel@kde.org mailing list.

How to get started

When it comes to porting, we can have a bit of a stress at start, I recommend to take it quietly and to take any step forward as a success. 🙂

For frameworks and libraries, look here, a template for creating KDE Frameworks.
For applications, what works the best is to port first the root CMakeLists.txt file, it should look like this:
find_package(ECM 0.0.11 REQUIRED NO_MODULE) set(CMAKE_MODULE_PATH ${ECM_MODULE_PATH} ${ECM_KDE_MODULE_DIR})


include(KDEInstallDirs)

include(KDECMakeSettings)

include(KDECompilerSettings)

include(FeatureSummary)
find_package(Qt5 REQUIRED COMPONENTS Widgets)

find_package(KF5 REQUIRED COMPONENTS CoreAddons Solid)
add_subdirectory(src)

feature_summary(WHAT ALL FATAL_ON_MISSING_REQUIRED_PACKAGES)

There’s not much more to change further than that. To make it a bit faster, you can use the spartan script, to port some simple and tedious changes to the new cmake names used in KF5. Note that it’s not perfect and we don’t ensure it’s going to work, but so far it has been of good help to me.

A good way to figure out if the porting is acceptable, is to run the unit tests of your application. If you don’t have, then remember that making unit tests is fun.

Things to look into

CMake

Adopted the cmake idioms: We don’t use anymore kde4_* macros to create targets, but the cmake macros, e.g. kde4_add_executable -> add_executable.
Dependencies: Where we used to have ${KDE4_KDEUI_LIBS}, now we have KF5::WidgetsAddons. Note it’s not a variable anymore and if you use cmake 3.0 you’ll get a warning if it wasn’t found. Furthermore, now each target already pulls the include directories. We don’t need to keep adding include_directories() with each of the dependencies.
Extra-cmake-modules: Look at what’s in there, there’s interesting things you’ll have to use at some point, also it’s targetted as a cmake extension, you might want to use it even though Qt or C++ isn’t used in your project.

C++

In reality, this is probably the easiest part. You need to keep trying to make it compile, and when it doesn’t then you look at the API and porting notes until it does, then goto “C++”.

To get the port started, it’s usually best to rely on KDELibs4Support framework in the beginning. It’s a framework with all the modules we decided to deprecate, because we moved the functionality to Qt5 mostly. It will help get to a point where everything is building then you can start removing deprecated dependencies 1 by 1. It’s also good to use it when there’s development still in the Qt4 branch of the project, because merging back will be easier.

If you’re planning to keep developing in Qt4 for a while, some porting beforehand can be useful, like KIcon -> QIcon::fromTheme, this way you also reduce the divergence between branches. Another idea to do before porting is to do unit testing, so you don’t need to test by hand every feature while porting.

QML

Porting QML is not trivial, but then there were only few projects actually using it seriously. All the underlying technology changed, so it can get tricky. At the moment, in Qt5 there are 2 QML implementations, QtQuick 1, which is the one we used in Qt4 and QtQuick 2 which is the one you want to be on, which uses Qt Scene Graph and does voodoo with the GPU.

One thing you get to decide is to stay in QtQuick 1. That is, only if everything it depends on is ported to QtQuick 1. For that matter, the PlasmaComponents were ported directly to QtQuick 2, so you’ll have to make the full change.

If you need to port to QtQuick 2, there’s also some scripts you can use to ease the change. You’ll want to basically change all the classes starting with QDeclarative* to QQml* and QQuick*, they usually keep the same name. If you were using QGraphicsView features, then you’re screwed.

In the actual qml/js side, when porting to QtQuick 2, you’ll want to update all imports. All Qt imports versions were bumped, so now you’ll have to change “import QtQuick 1.1” to “import QtQuick 2.2”. In the same direction, “import org.kde.plasma.components 0.1” now becomes “import org.kde.plasma.components 2.0”

Final considerations

I recommend people to do their porting, I think it’s a solid step forward for the project and will help you clean up parts of it and start thinking future.
Qt 5 provides many interesting new concepts. I’m thinking of QtWebSockets, QtWayland, QtWebEngine and I hear Qt3D is getting really interesting. Additionally, it enables your project from letting the Qt code integrate properly in the new C++11 concepts.
Porting to KF5 will also help your project become more portable and reach out to different platforms.

Finally, if you think this is interesting for KDE but you can’t find time or energy to dedicate it, please take a look at the Randa pledge, where we will push together to get KDE to embrace fully the KDE Frameworks 5.

KDE Software on Android

12 June 2014 / apol / 19 Comments

Despite my involvement in KDE and free software operating systems, one of the features I’ve always loved from Qt is how we can use it to develop an application that can be used on any platform. Since I got my first /programmable/ phone, I’ve wanted to get my projects to work there, especially through all Nokia approaches to the issue, and I’ve managed to do so with relative success.

At some point last year I got to the conclusion that, if I wanted to remain somewhat sane, the best approach was to start focusing Android by caring about the CMake side of the issue and let QtQuick get into place, which is not in place yet, but admittedly in a much better state than a couples of years ago.

My KDE on Android approach is that any KDE project should be able to be built and bundled for Android from the sources, that is with an apk file as a result, without having to change the project sources: c++ or cmake.

I started working on this longtime ago on Qt4, but the fact that kdelibs was about to change and the poor direction of the port drove me away from bothering. Also if we want portable interfaces we want QtQuick Controls. I don’t think there’s much doubt there.

I restarted the project last November. I compiled a full Qt5 installation and started to get it to build, my intention was to use android.toolchain.cmake again, but I then decided that it would be better to create a new cmake toolchain file to have all the control I needed over how it’s being compiled. Some things need to be treated with special love like how executables are built and especially being able to create apks.

At the moment it seems to be working reasonably well, I’ve been using KAlgebra as a test. I get to easily deploy the Analitza framework which is a dependency and then consume it from KAlgebra which bundles all dependencies into a nice publishable APK.

Enough back-story, let’s see how we’d build KAlgebra (or any traditional KDE project for that matter).

To get all the features going we need:
* Qt 5.4 built for Android (currently in dev branch)
* CMake 3.0
* Android NDK
* Android Development Kit
* the ToolChain file I created (still to find a proper place, can be found here)
* Extra-CMake-Modules
* The project’s source code, because the power is in the source!

Here’s an example on how to get it done [1], but that’s the expanded version. As an attempt not to scare you here I used a simplified version, by having a cmakeandroid macro defined, passing cmake all the needed information.
mkdir build-analitza build-kalgebra cd build-analitza && cmakeandroid ~/src/analitza && make && make install cd build-kalgebra && cmakeandroid ~/src/kalgebra -DQTANDROID_EXPORTED_TARGET=kalgebramobile && make && make create-apk-kalgebramobile

Which I think it’s readable enough.

To conclude, we are able to consider Android as a candidate for KDE projects to adopt. There’s much more to do both on KDE, Qt and cmake sides, but we can get to discuss it when you’ve ported your application.

For the moment, I’d like to know if there’s any application that is interested in being built for Android, I’d like to give it a try, especially if it’s already been ported to QtQuick and Qt5/KF5.
Furthermore, in case anybody is interested, I’ll open a wiki page with this information, in case anybody wants to use it, for the moment my cmake toolchain and manifest can be found here:
http://quickgit.kde.org/?p=scratch%2Fapol%2Fkalgebraandroid.git