Category: Software Libre (Page 5 of 9)

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

New git repositories structure: The KDE workspaces

2 April 2014 / apol / 6 Comments

I know most of you have been following the upcoming Plasma Next release with interest, there’s lots of work being done, and as usual, most of it happens under the surface.

I would like to talk today about the new repository structure we have been working on during the last weeks: Splitting the kde-workspace and kde-runtime repositories.

What did we use to have, so far?

What we have now is mostly an evolution of what KDE ever was, only that after many iterations, especially given the long history we’ve been through, since the Kool Desktop environment days, in CVS back then. Since then, concepts have changed, the community has progressed and ultimately, the projects we’re offering have evolved a great deal.
Nowadays our workspaces are built around the kde-workspace repository which is a subset of what kdebase once was. It contains the code relative to the shell, System Settings, kinfocenter, KWin and other components, even some libraries.

Note that some of these are big components, some are small, some are part of Plasma Active, some aren’t. This had different implications, for example: Plasma Active depends on having the desktop environment installed, repository-wise, so does KWin need to have systemsettings installed, etc.

What will we have now?

We chopped kde-workspace into several chunks. We separated what’s specific to our desktop users and what can be independent components, trying to make sure that we end up with manageable projects rather than a bag of surprises. This leaves us a clean outline of what projects we are working on, while still letting us figure out what is part of a project and what isn’t.

This is all glued together by the dependency-data files, where we specify what project depends on what project within KDE. This means both and compile-time and runtime. The dependency-data files will start gaining relevance as it suggests, what does it mean to have a full Plasma Desktop installed or, for example, a full KDevelop. *

What does this mean?

Depending on how you look at it, nothing changes. I would like to highlight some points though, of what I think will have the most impact.

Simpler to modify and deploy the components. Some of our components are more complex than others. Now you can modify System Settings without pulling a full KWin.
Easily follow your favorite projects. Now you’ll be able to follow the commits in a specific project (See the “Follow this project” check in a project page). This should increase peer review for people interested in a project but concerned about receiving noise on the inbox.
Simpler to reach the components. Now it’s easier to figure out where the System Settings are, given that you can find them in projects.kde.org right away.

I hope you’ll be as excited as I am, hopefully by joining the development team and helping us create a wonderfully awesome Plasma Next release.

* This opens the possibility to review what’s extragear and what’s KDE SC roles, it will be an interesting discussion.

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/

KDE, the present and present+1

26 June 2013 / apol / 1 Comment

Usually I don’t blog because there’s not much going on. Lately it’s been because there’s been too much things going on.

As always in communities, it’s not something somebody is doing in his corner, but some synergy coming together in a beautiful and convoluted way. Let me try to sort what I’m talking about.

The Akademy 2013 is happening soon. It’s going to be a very interesting event, KDE is evolving in a fast pace, more than most of us realize. This year’s Akademy will be crucial to the future of the project, I wouldn’t miss it.
This year, Akademy comes with a small present in it. The Akademy-es 2013 will happen in Bilbao as well, the two days before the Akademy. It’s our biggest opportunity to help people from Spain join the KDE awesomeness. If you are around and understand Spanish, don’t hesitate to join!
We’ll have talks, we’ll have discussions and we’ll tell you that you must go to Akademy. 🙂
Qt5 is gaining traction and we’re getting up to speed to adopt it through the KDE Frameworks 5 Project. The Qt contributors will be meeting in Bilbao as well, discussing what features we’ll be finding in Qt 5.2 and further. That means that they’ll be deciding what things we’ll have available for future releases by KDE!

Ok, so I’m saying that we’ll be gathering a bunch of people talking about what we do. What’s so special about that?
Well, first of all it’s not just people. It’s people who are passionate about what they do, the people who have created the KDE we all know and the one we don’t know about yet.

Personally, these are the topics I’d like to discuss about this year:

I want to talk to distributions. I want to remind them that Muon Discover will be working on their platform soon. I want to work together with them to make sure they are on board and that it will go smoothly.
I want to get in touch with the KDE Edu fellows, see what they’re up to (I hear that there’s some new awesome application coming together). I want to discuss about Khipu with them, it’s seeing some very interesting progress recently, I’m hoping to see it released soon!
The KDevelop team will be having their meeting there as well. I foresee a closer and closer KDevelop 4.6 release, and we want to make this one the best ever. Also I’d like to discuss some otherwise interesting stuff as well such as some changes in the C++ support that we’ve been discussing.
I’m quite excited about the KPeople project, as well. It’s coming together very well, getting ready for applications to adopt it. KDE Telepathy has already started worked on supporting it on some parts. Also KDE PIM should be adopting it soon, so will other projects. I want to easily interact with my friends from our applications. Awesomeness.
And last but not least, the KDE Frameworks 5 project, that I already talked about before. It’s probably the most important initiative in KDE, at the moment. Let’s push it all together, at Akademy!

I know it’s been a huge blog post, but also I think that it displays where we are. Lots of people, a big community, with smaller communities in it, coming together for a greater purpose, having beer and exchanging ideas.

\o/

See you in Bilbao!

GSoC proposals, from both sides

26 February 2013 / apol / 3 Comments

So Google Summer of Code 2013 has been presented already and there’s many people asking about it. From my perspective, GSoC has changed quite a bit over the years, so I have. When it started I was starting university, since then I’ve been a student in 3 occasions and a mentor in 3 other occasions. I figured that given I’ve been at both sides, I could give some advises to incoming people that can be useful.

The student side

The first year I applied for GSoC in KDE I wasn’t accepted. I guess that this fact alone made me respect GSoC a little more (sometimes I feel like people see it like an easy way to get money during summer). The first time I applied for something, I proposed for something that I figured that I missed from KHTML that I missed while developing KAlgebra (MathML support). I didn’t love the project but I wanted the outcome. I didn’t talk to anyone from the community about it, not before, not after. I guess this was my biggest problem, this and that I was (and still am) clueless about KHTML internals. That couldn’t be well received by the mentors.

The next year I took a different approach. This time I went for KDevelop, it was a project that I used in a daily basis back then already and I already had sent a couple of patches to fix some usability problems there. I thought about what could I do there to improve it. I was following KDE development closely, and cmake was starting to be adopted by then so I guessed KDevelop could use some support for it. Before doing so, I remember talking about it with apaku and adymo, who gave me some suggestions for my proposal, telling me that there even was some work started on that area. Being accepted there was huge for me, not only I would be doing something that I wanted during a whole summer, but also something that I needed and I would join a team that I respected a lot.

The next two times got easier, and I don’t think it was mentors preferring me over other students, but I got to understand KDevelop as a project, our user base and their complaints. That gave me a good advantage when writing proposals.

The mentor side

GSoC is great for KDE. We get yearly handwork for working on our projects. Nevertheless, I think that almost any mentor can tell about bad stories. It’s one of those cases where we’d really like to focus on the positive, but it gets really hard.

Before the students are selected, mentors have 2 major challenges in my opinion: they need to select both a good project and a good person behind it.

To get good project one of the things we usually do is to create an idea page with things to be done on our projects. We try these ideas to be something that has enough charge for someone to spend 3 months working full-time, we put features that are not really pushing since there’s probably someone else doing them and something that can be appealing enough to a student to pick. The ideas page is the channel that ends up attracting more students in the end, but it has a number of problems for us, the first being that this list is where someone not caring that much would go. Try to stay away from this profile, please care.
To get good people, the first thing I do is to take into account how the proposal was written.
Does it take into account all features? Does it explain how the project will change the bigger picture? Why is he doing the project? Does he believe in the project? Is there any possibility he’d stay after the GSoC? Does he even know how to write properly?
And who is this person?

I know it’s not very scientific, but keep in mind GSoC is not about getting a new feature for us, but about getting a good contribution so we are thorough. In the end, we’re going to spend many hours mentoring this person and project, we don’t want that work to be for nothing.

My suggestions

Read the mailing list, show up on IRC, figure out what’s the project interest and if you’d fit with those people.
Don’t compromise about the project idea, make sure you pick an awesome idea that you like. If you don’t find one, make it up.
Make sure that you know what you’re doing and why.
The proposal is not about choosing a project within the ideas page. It’s about saying how you’ll make it a reality.
Sending a patch beforehand helps a lot. Much more than saying how you rock. Also if you’ve contributed to other projects, make sure the proposal points to it. The important thing for us is to know that you can code and work with a community
Follow the Planet KDE

And please, note that’s my very own opinion. Not KDE, not KDevelop or KDE Edu, although I’m sure that other people will agree with (some of) my points.

Muon Discover, new version, new features, new look

19 February 2013 / apol / 13 Comments

A new Muon release is approaching and I wanted to use this occasion for sum up a little what happened in the Muon area, in view of the forthcoming 2.0 version.

The first thing you’ll notice is the version bump from 1.5 to 2.0. This is because the whole suite had 2 big changes. Firstly, Jonathan reworked libqapt which will be seeing a 2.0 version as well, and I refactored Muon’s internals so that we could have different back-ends in it.

I’m excited about this last change; not only for the features it’s already providing, like the KNS and Bodega backends, but for where I’d like it to go in the near future. We’ll know more about it soon though. 🙂

Another important change, was that we moved some of the Discover UI from QML to better integrate with the rest of KDE applications, specially by using a native scroll bar and prefer the main window’s toolbar to our custom buttons. I’m not much of a graphical person, but I’m quite happy about the result. I hope you are as well.

Here there’s a small video I made for you to see what’s going on in Muon Discover 2.0. I hope you like it and I hope you want it. 🙂

Cheers! \o/

My first year at BlueSystems

13 December 2012 / apol / 2 Comments

About one year ago, the 1st December 2012 I graduated, and by the same dates I started working for BlueSystems. Since we usually consider year periods like achievements, I thought it was a good occasion for a flashback, so there we go!

The KDE GTK Config KCM was my first assignment. It was something new for me but still interesting otherwise. I was more used to work into making applications, there I worked right into helping integrate an important part of the software we have available to KDE. I think it was successful in the sense that many people are starting to take advantage of it and hopefully enjoying the possibility to fully customize the look of all applications, haven’t you tried it already?
The second project I worked on was Muon Discover. There I spent most of my time this year, by bringing to KDE a new way to see what you have available for enjoying on your system. I think it’s a very interesting project and I’d like to keep working on it regularly since I think there’s much we can offer there. Of course my work on Muon hasn’t been limited to creating Discover, but I’ve also pushed many different internal changes in order to get different backends. Backends for OCS/KNS and Bodega, will be available from the next Muon version.
Furthermore, I’ve tried most of all to help KDE wherever I could. We organized the Pineda sprint, I’ve worked on bringing life to Plasma wallpapers, I’ve committed many fixes in the lower stack of KDE and Plasma Components to make sure everything worked and I put my grain of sand to push the People Framework.

All in all, I’m happy of what we’ve been doing from BlueSystems. I think it’s just starting, we’re doing great work, so keep tuned!

**sigh** When you have fun, time flies!

Cheers, and have happy holidays if you’re having them!

PS: … and this was only what I worked on while sponsored, it’s been a great year indeed. 🙂

Changing point of views, the Commit Digest

15 October 2012 / apol / 1 Comment

I’ve usually contributed to KDE by developing software itself, I’ve done other things from KDE Spain as well, as many presentations but that’s not really my focus.

What I’d like to discuss today is my experience with the commit digest. Since before I even had a KDE svn account, I started following commit digest. For those who don’t know about it, the commit digest is a service that with the help of some editors, it gathers what KDE commits have been interesting during a week and posts them together in a nice web page.

I’ve always liked it. Enthusiasts have few ways of following the KDE development: the Planet KDE, KDE News, some mailing lists. But all those refer mostly refer to things that are quite close to be usable or just discussions but little actual work. Those are great, but some of us like to see how those come together, like in a crystal ball. Here’s where the commit digest helps a lot, because it puts some interesting specific modifications and fixed bugs that have happened in our code base for the reader to see what has been going on. I think it’s fantastic!

In any case, a couple of weeks ago I saw some of the editors asking for help and I decided to contribute to it. Getting started is easy, you just go to the enzyme web and apply for the role you’d like to do and then you’ll receive an e-mail with the mailing list and a wiki page discussing the guidelines.

From there you can start contributing from a nice interface such as this:
enzyme review screenshot

There you just press the cross or the tick if the commit should proceed or not. I recently found out that the keyboard can be used for that as well; you can do so by pressing the Right Arrow key for jumping to the next entry and space whenever you find a commit relevant, this will mark the current commit as good, so that it can be classified afterwards.

All in all, I think that the Commit Digest is a very nice way to contribute to KDE. It’s easy to get started with it and I think it pays off. Also you get to see how most people work inside KDE.

Hope you find this interesting like I did!