Category: KDE (Page 5 of 11)

Taking advantage of OpenGL from Plasma

4 August 2014 / apol / 12 Comments

I’m excited, and I hope you’ll be too.

David Edmundson and I have been working hard the last weeks. It’s not that we don’t usually work hard, but this time I’m really excited about it.

A bit of context: in Plasma an important part of the system drawing is painting frames (others are icons, images and the like). Those are in general the elements that are specified in the Plasma themes. These will be buttons, dialog backgrounds, line edit decorations, etc.

So far, to paint those we were assembling the full image in the CPU and then sending it over to OpenGL as a full texture, then we would do the composing of all the different frames, according to the information provided by QtQuick, through the Qt Scene Graph. There are 2 main problems in the current approach.

We were maintaining huge textures in memory. Every frame was completely stored in memory and gpu memory. Which means that the bigger the dialogs are, the more memory we consume, even though the texture is flat.
Every time we resize the frame, we have to re-assemble the frame in CPU memory and upload it again.

First: The 9-patch approach

First we made it possible to have the frames to be rendered by each different parts and assembled by the GPU. This wasn’t possible, because Plasma themes are quite complex, so now we have 2 different paths. If the theme element can take advantage of the optimization, it will use the new code, otherwise it will stay working beautifully on the former, thorough implementation [1].

Therefore, instead of rendering all the frame now we’ll be uploading 9 textures to the GPU, and let it either tile or stretch depending on the settings in the theme. This way:

we are uploading 9 tiny textures rather than a big texture.
when the frame is resized, we tell the nodes to resize and the GPU does the job [2].

Second: Caching the textures

Now everything was in place, we’d have many times the small 9 elements but we kept uploading them to the GPU over and over. It’s little textures, but it’s still better if we get to re-use what we already have. To do so, we’ve placed a little hash table that keeps track of the already created textures to re-use them. This way, we get to tell the Qt Scene Graph to use a texture that has already been uploaded rather than a new one. We’ve run some tests, here’s the result:

In PlasmaShell we get 342 miss and 126 hits, so roughly 25% of bandwidth and memory improvement
In KRunner we get 108 miss and 369 hits, so roughly 350% improvement on memory and bandwidth improvement.

Future, further work

Sadly enough, raw memory usage is still quite high, when running plasma shell on massif, we are still reported as most of the memory usage being in the GPU graphics card (or rather i965_dri.so), so we’ll have to dig it [3]. We’ve found some ways to improve this, for example by enforcing OpenGLES 2, but this requires Qt 5.4 which is due October. I implemented it nevertheless, and it works fine.

Being more precise, a big offender is using a wallpaper image. We’ve looked into it, the code looks fine, but then it makes a big difference, so big that I still don’t understand how it can be. A good suggestion if you’re testing Plasma 5 on a system low on memory, is to run it with the plain color wallpaper. We can save up to 30% of memory consumption, no kidding (it actually depends on who you ask, either massif, htop or ksysguard; but they all agree it’s a big deal). We’ve investigated a bit and found ways to improve the situation there, but if you are interested, feel free to join!

Finally, another problem with regards to memory consumption is QML. We make heavy usage of it and it shows memory-wise. We should see if we can adopt any optimization to stream-line our usage, but admittedly it’s much better than one would have expected.

Testing

If you want to give it a try, you can already find most of this in master, and it will be available from the next KDE Frameworks 5.1 release which will be available by the second week of August.

Hope you liked it, it was a great exercise to investigate all this! I learned a lot and gained quite some respect for the Qt Scene Graph and QML development teams. Keep rocking!

[1] More precisely, at the day, when there’s no hint-compose-over-border or mask-*-overlay elements

[2] an exception for it being (hint-stretch-borders and hint-tile-center hints, where we’ll have to re-render on resize it).

[3] David, Vishesh and I we all have Intel drivers, but I guess it’s a good card to test-case on, given how mainstream it is, currently.

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

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.