DEC
29
2010

Season of KDE 2010

This year was the 4th Season of KDE. Season of KDE (SoK) allows KDE to help support students and worthwhile projects who didn't manage to get one of the limited places in the Google Summer of Code program. Each SoK student works on their chosen project with a mentor from KDE with experience in that area to help and guide them.

We had seven successful students working on six different projects and five different programs. Let's have a look at them.

Hariom Balhara worked on a plugin for the smokegen tool called Documentation Extractor. The plugin will parse header and source files extracting documentation comments and converting them Ruby. It converts its input to a format understandable to Rdoc, which then creates the Ruby documentation.

Kunal Ghosh's effort was to bring QtScript integration to Digikam. This works as a plugin mechanism to further expand the capabilities of the the Batch Queue Processor (BQP) of the photo management application. BQP allows one to apply a sequence of transformations to a group of images. The plugin enables BQP to understand scripts written in QtScript scripting language based on the ECMA Script standard.


Cantor plotting

Miha Čančula integrated Octave into the KDE mathematical frontend Cantor. Miha's work passes commands from Cantor's worksheet to Octave's process, and also implements some convenience functions. Quoting Miha: “The most notable is probably plotting, for which Cantor has a special menu option”. Miha added shortcuts for the most common matrix and vector operations as many people use Octave in numerical linear algebra. Syntax highlighting, code completion (both are dynamically updated when the user defines new variables or functions), help and an integrated script editor have been implemented with Octave-specific options. The syntax help can be displayed either in the sidebar or in a pop-up. Miha didn't seem to feel his work had been enough because he and his mentor Alexander then went on to improve the script editor, general highlighting code and backend tests, which benefit all of Cantor's backends.

Aditya Patawari and Maxime Côté both worked on an ownCloud syncing client. The primary goal was to synchronize selected files on a computer, and update them at a defined interval (hours, days, weeks, months, years or custom). The next step was to sync files between two different machines. The final effort was selected syncing from one to many machines, which is useful in projects where many people need the latest files available. It was important to the project to optimize bandwidth usage by using a version control system; git seemed to be the best choice. Meanwhile Owncloud saw many changes on its codebase and, therefore, the students had to update the code on the client as well. They had to overcome some difficulties, the biggest of which was communication; the two students and the mentor are all from different regions and timezones and have different mother tongues. Highlighting one of the keys to open source success, Aditya comments: “We learned how to collaborate as well as code. This was an experience I will always cherish”.

V. Ramachandran worked on an ownCloud-related project too. His aim was to write a photo gallery plugin that would help users share their photo galleries without the need for any online photo service. The plugin reads the photo files from any folder on an ownCloud server and automatically creates different beautiful galleries, saving them via webdav under categories such as family, friends, office, and the like.


Thank you gifts from KDE

Finally, Yuvraj Tomar worked on analyzing and improving KDE startup time. The first step was to analyze what was slowing down startup. When the research and analysis was done, he had some discussions with his mentors and with KWin and kdm developers, and then started coding. His results are pretty clear: on a test machine, startup went from about 30 seconds to barely 19. That's a remarkable improvement!

The work from these projects is not yet available in the latest releases, but it will be soon. KDE continues to improve in many different ways, in coding and in community as well. Season of KDE doesn't provide the same benefits as Google Summer of Code, but it offers valuable mentoring, along with a vibrant and friendly environment. SoK allows us to attract more new contributors, and help them take their first steps developing KDE software and becoming worthy members of the KDE community.

Many thanks to the 2010 Season of KDE students! We appreciate your creativity, intelligence, effort and partnership. Please enjoy the gifts from KDE and Google commemorating your contributions. They will be sent to you soon.

Comments

We could raise money and pay students to find bottlenecks and otherwise useless parts of KDE and try to remove them. The one who removes the most lines of code would also get a special prize.


By trixl.. at Wed, 2010/12/29 - 12:27pm

But what would be really interesting is what code made it into trunk, what code is nearly sure to get into trunk and what not? it seems like quite often those student projects are done in branches that are never merged into truck.


By Beat Wolf at Wed, 2010/12/29 - 8:35pm

Most of our Season of KDE and Google Summer of Code projects are actually merged into trunk. That's one of the things we're aiming for in KDE in these programs.
If you are interested in an individual project you'd need to ask the student or mentor. They know the current status best.


By Lydia Pintscher at Thu, 2010/12/30 - 9:44am

Good work all!


By Matt Williams at Wed, 2010/12/29 - 12:33pm

>> His results are pretty clear: on a test machine, startup went from about 30 seconds to barely 19. <<

A great improvement sure but what does your startup time include?


By renox at Wed, 2010/12/29 - 2:59pm

Startup of KDE, of course.

It was not his job to speed up the whole operating system's startup but KDE's. The timings are from the moment you login to the moment everything is working.

Regards


By Marc Deop at Wed, 2010/12/29 - 3:55pm

Thanks for your reply, but if it's only KDE startup then the timing is still not very impressive, even with this great improvement: I remember that with BeOS the startup time from Lilo to a fully responsive desktop was 14s(*).

*: On a Celeron 333 !!!


By renox at Thu, 2010/12/30 - 9:25am

Is this research available anywhere publicly? I'd certainly be interested in knowing what is involved in boot, and what the bottlenecks are.


By David Edmundson at Thu, 2010/12/30 - 12:25am