Category: my projects (Page 3 of 7)

Hacking Free Software, a different point of view

20 January 2015 / apol / 6 Comments

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?

Communicating from Plasma 5

28 October 2014 / apol / 9 Comments

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

2 October 2014 / apol / 5 Comments

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

18 September 2014 / apol / 18 Comments

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! :)

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

KDE SDK Next, how will we develop in a year?

19 March 2014 / apol / 6 Comments

Since the beginning of my involvement in KDE and, more specifically, my involvement with KDevelop, many people have come to me and said that what we “actually need” is an SDK. So far, I never gave this much thought. Especially given that for me, the SDK was the system I’m running on and, by extension, the packaging system of my GNU/Linux distribution.

After all this time and given one of KDE Frameworks goals is to broaden our portability, I started wondering about the subject again. Some of the pieces are starting to come together already, but I still think we need to actually glue them together in a clear and pragmatic approach.

Premise: we want to build an SDK on top of the tools we generally use:
CMake, Qt, KDE Frameworks 5, Plasma, QML and C++.

For starters, we have two different major scopes: Integration with Plasma and Cross-platform facilities.

KDE Applications should be as distributable and portable as possible. On the other hand, we should be providing the tools to specifically integrate to the Plasma Workspaces.

Applications have different use-cases than the Plasma Workspaces. While applications need to be as easily distributable as possible, Plasma will want to have as much control on the system as needed to work accurately. Therefore, we want applications interacting with Qt5+KF5 and integrating through Qt abstractions, while Plasma will want to interact random components in the system regardless without fear.

What I propose:

Figure out which frameworks are portable and which are Plasma Platform integration frameworks. (e.g. KDED modules, KNotifications, Solid: are they portable? do we want to support the different platforms?)
Figure out what do we mean by supported platform (both in the case of Plasma and Applications).

Once we get there, we will be able to think about developers and:

Offer a sensible set of tools to support the development and ease testing.
Figure out a packaging plan for the libraries and tools for developers, so they can start using them for their development.
Figure out a deployment plan for the frameworks on the different platforms, so that deployed applications know how to rely on the needed dependencies.

So this are mostly thoughts, I would like to know if you’d be interested in the project. I think it makes a lot of sense to figure this out and then gather this year’s Randa meeting to make sure we’re coming up with a coherent next development platform.

Smoothing the transition to Qt5/KF5

10 January 2014 / apol / 4 Comments

Hi,
If you’ve been following development in KDE recently, you might have the feeling that either it’s not changing much or we’re doing things that are not having an immediate impact on our daily life.

This is changing soon, the KDE developers have definitely been busy. We’ve been preparing the technical layer where we will base our future technologies. That’s Qt 5 and the KDE Frameworks 5, which has been discussed and documented largely.

Anyway, I didn’t want to discuss about the past today, but instead point you out that everything is in place for you to start porting the project of your liking and start taking advantage of Qt5 and KF5.

So if you’re interested, just take a peek at the projects that are already ported (Kate, KDE Workspace, KAlgebra, KGeography and probably others I’m not aware of, you can check if the repository has a frameworks branch) and give it a try.

If you have questions, remember you can use #kde-devel in irc.freenode.org, kde-frameworks-devel mailing list.

Interesting times coming, do you want to be part of it?

KDE 4.12, KDE Frameworks 5 and Barcelona

6 September 2013 / apol / 2 Comments

Summer is almost over, so it’s time to get our things together. A new release is always a good opportunity to get together and getting some things done.

Last Friday we gathered, some had some good food, we had some beer, and we even got to discuss about the future of KDE, free software and, of course, some politics.

Dinner picture

We didn’t have enough with having food, we wanted some hacker fun, so the next morning (well, alright, it was more noon than morning) we met again. This time to work together on KF5, in our Blue Systems’ office.

KF5 mini-sprint

Thanks everybody who came, and for those who didn’t we’re waiting for you next time, or if you can’t come to Barcelona consider organizing one!

\o/