If you want to develop a KDE project (Plasma applet, runner, GUI app,  Akonadi resource, Qt only app, ...) you can use KAppTemplate to generate a basic template for such a project. KDevelop also uses those templates and provides you with a full IDE while after generating the template with KAppTemplate you are left with using your terminal and editor (Kate does both by the way ;)

Recently I added 2 new projects templates: a Plasma QML based applet and a Qt5 - QtQuick2 application. Here are previews of those new additions:

This is the Plasma QML applet, displaying a SVG image (from Pairs, the kids love this pic) with a Plasma label below. From there you can start adding stuff and develop your own plasmoid!

This is the Qt5 and QtQuick2 application which is also fun to get you started with QtQuick 2 new classes. When you right click the background becomes green and when you left click the app quits.

Those templates are only a few lines of code but they should compile and run and when you achieved that you're all set for serious development!
Hope you'll have fun with those ready-made little projects which can become very big! This is how I started developing for KDE, some years ago, and did it become addictive!!!

KDE participe à Google Summer of Code 2013. Si vous êtes un étudiant francophone avec une bonne connaissance de l'anglais, vous pouvez peut-être passer l'été à coder pour KDE. Une page wiki http://community.kde.org/GSoC/2013/Ideas recense les idées proposées par les dévelopeurs KDE. Vous pouvez aussi établir votre proposition si vous trouver un tutor. Bonne chance !

De plus cette année KDE se joint au programme initié par GNOME et d'autres visant à permettre à plus de filles de contribuer aux projets libres en général et à KDE en particulier. Voir https://live.gnome.org/GnomeWomen/OutreachProgram. Des idées très intéressantes ont été proposées ici : http://community.kde.org/OutreachProgramForWomen. Là aussi vous pouvez soumettre votre proposition si vous trouvez un tutor. candidatures à soumettre avant le 1 mai, bonne chance !

Aujourd'hui a eu lieu l'Atelier KDE mensuel organisé à Toulouse. 9 personnes y ont participé plus 4 apprentis traducteurs recrutés par Xavier. 2 étudiants en master d'informatique à Toulouse nous ont présenté le matin leur travaux de contribution à Calligra Words et Author, ça m'a donné envie d'essayer la suite Calligra !
Pour moi ça a été l'occasion de me replonger dans KDE que j'avais bien négligé ces derniers mois. Il y a 2 semaines, j'ai installé openSuse 12.3 sur mon ordinateur portable et j'utilise kdesrc-build pour compiler le code du futur KDE 4.11. J'ai aussi commencé à compiler KDE frameworks en suivant la doc http://community.kde.org/Frameworks/Building qui est super.
J'ai ajouté cette semaine un modèle de projet d'applet Plasma QML dans l'application KAppTemplate. KappTemplate sert à générer des modèles de projets pour aider les futurs dévelopeurs à démarrer.
J'ai complété un fichier de traduction que j'ai envoyé à Sébastien et je vais léguer mes traductions à Xavier qui accomplit un travail remarquable pour la traduction francophone.
J'ai aussi corrigé 2 bugs dans les traductions cette semaines.
Bref, une reprise réussie dans le monde KDE ! Merci à Jean-Nicolas d'organiser ces ateliers et de m'avoir expliqué le fonctionnement des étiquettes dans Blogger !

As you may know, we recently set up a Quality and Testing team within KDE. We prepared some wiki pages (http://community.kde.org/Getinvolved/Testing/Beta) and now that the Beta 1 is out, several people already joined this Testing phase.

How can you get involved?
Install the Beta 1 from your distribution, most known distributions provide packages for it.
After that, you can choose two ways of testing:
- either use the release as you would normally and look for regressions, bugs, crashes,... Please report them to bugs.kde.org (try to search if the bug was already reported, for a quicker result you can ask on IRC, freenode, in #kde-bugs), do not forget to set up the version in your bug report as well as the precise stps to reproduce the bug. If it is a regression, explain how it was before.
- or choose a specific component to test in a more thorough way. We focus in priority on new additions to this release, on changed components and on new features. You can therefore test applets (http://community.kde.org/Getinvolved/Testing/Beta/Plasma) or test full programs (http://community.kde.org/Getinvolved/Testing/Beta/4.9Applications) or new features (http://community.kde.org/index.php?title=Getinvolved/Testing/Beta/AreasToTest). Copy the proposed tests in a text file and add a note like "works" or "OK" after testing each proposed feature. Then send your text to the Quality Team (kde-testing@kde.org) with your name or nickname. You can also extend those tests if you find other things to test, that will be useful in the future and also when we will move to more automated tests. I believe testing an applet does not require much time while testing a full application is more time demanding.
There is something to work on for everyone!
Testing does not require any specific knowledge: install the Beta and have a bugzilla account are the only requirements.
Please do not hesitate to join this effort and raise the quality of this release. Developers will then get batches of bugs to fix, priority will be given to regression and blockers. Several bugs already have been fixed!

IRC channels on freenode are #kde-quality and #kde-bugs
Mailing list is https://mail.kde.org/mailman/listinfo/kde-testing

I'll carry on giving tips on how to make better bug reports but I would like to ask your participation at the bug squashing week which will start tomorrow and will last 7 days.

What is it? The aim is to detect and triage the more bugs possible so that the next beta already will benefit of an improved quality.

How? If you can install the beta, you have 2 possibilities: either run it in any possible way and report all the bugs you find. Or help triage and reproduce the bugs already reported.

Where? You can join on IRC Freenode #kde-bugs and you can ask there any question. There is also a Techbase Page to help you.

Following my last blog, I know that issuing bug reports is not easy. There's the matter of having an account and I also hate this (fortunately as a KDE developer I use my svn credentials so I remember those). Issuying a bug report takes time, it needs to be in English which might not be your main language. But it is really worth it. I know some reports have been around for years and not taken care of but they are a very small minority. When you read Planet KDE you can see how developers care: Aaron asked for help on multiple screens, VHanda asked feedback on the new Nepomuk kcm, John explained Localisation, and so on... (I only noted here the very last entries). So yes, it is worth the effort!

If you only have 4.5.X you can still help triaging and look on your system if the bug is present. Yesterday on #kde I met 2 fantastic users who took time to help pointing an issue about capital keyboard layouts in systray (fixed in 4.6 but present in 4.5). Those 2 users devoted several minutes to the issue and this is enough to help KDE. They were contributors and actors, not just consumers.

So if you have a few minutes to dedicate to KDE feel free to drop on IRC or issue a bug report or help triaging.
By the way if you are not sure whether your bug was already submitted it's better to issue a new report than none. If you find a duplicate for a bug you have, please add a comment like "I can reproduce on KDE from ".

Coincidently I'll be talking about the bug effort in KDE tomorrow in Toulouse in the KDE monthly workshop of our lug!

I hope to meet you on IRC #kde-bugs during the week! You are KDE!

From 6th to 11th July the RMLL will be in Bordeaux France. This is probably the biggest Free Software event in France. There is no proper "KDE France" but nevertheless we managed to get a KDE booth. Now we need people to staff the booth and demonstrate all the greatness of KDE.
If you are willing to help and can come 1 day or more, please add a comment to this blog or/and contact the French Events mailing list. Thanks in advance and see you there hopefully! I will arrange to either come during the week but with a few kids or for the week-end and alone but I need to check this with the rest of the family!

We have great tools in KDE to check our code but they are not all used the best they could. We also can go further in testing our software and deliver higher quality releases. This is why we decided to setup a Quality Assurance and Testing Team which will coordinate the efforts for testing better the next release, KDE SC 4.9 and the ones after it.
Here is a link to a document I wrote to expose some ideas in order to have a starting point to debate from: http://www.flootr.com/download.php?file=3374d1db022e34aa39083c22f06abc2e
(the source in .odt is available from my KDE git scratchpad).
The document outlines improvement in using existing tools or following existing policies (marked as "Reinforce") and new testing methods (marked as "New"). For the post 4.9 releases more new targets will be set.
So, what to do to participate? You can subscribe to the mailing list and also join the IRC channel  #kde-quality on Freenode and comment on the document or share your experience with testing software or present yourself and tell us you are interested in participating.
We are trying to assess and update the existing wiki resources and update them, this is done on the Community wiki: http://community.kde.org/Getinvolved/Testing. A page for brainstorming also exists if you have practical ideas on how to make this effort work: http://community.kde.org/Getinvolved/Testing/Brainstorming
We will use the beta phase to start testing, in coordination with distributions for providing packages, with the Bug Squad and with developers. Beta testers will be called for before the first beta and meantime we need to have all the documentation ready for them and specific goals set.
Hope you will join!

KDE 4.6 first beta is nearly out and the code is frozen for new features and strings. We are entering an intense debugging phase! You can help and the first thing to know is how to issue good and efficient bug reports. This small serie of posts will give you some hints on how to do that.

Reporting bugs is a small but valuable contribution to a project, it makes you actor, you get involved, you belong!

The first thing you need is to open an account to http://bugs.kde.org.

Usually bugs come in two flavours:

• you notice something which is not working properly or not working at all, a bad design, a missed functionality... Open the application Help menu

and Click on "Report Bug..." You will then be guided to http://bugs.kde.org. Some information will be automatically picked up like the application version number.

• the big ugly bug which is called a crash: your program disappears and another window appears named "The KDE crash Handler".

This is quite scary but you will be guided to efficiently report this crash. The link in the dialog "Learn more about bug reporting" will explain you the process. If you choose to report the problem, click on "Report Bug" and an assistant will guide you through the steps. The requisite to report a crash is to have your distribution debug packages installed in order to provide a valid backtrace.

I will write some more posts about Bugs in the next days, stay tuned!

We're at the end of post-beta 1 bug triaging week. When we triage, we first ensure the product (KDE program) and component (product sub area) are right for the bug report and that the title is accurate and in English.
A bug report goes through various stages until it is closed. First stage is UNCONFIRMED status. Bug squad people mainly try to reproduce your bug. When this is done, the report can move to the NEW status, a comment is added about the version on which it is reproduced on and the maintainer then knows that this is serious. The bug can also move from UNCONFIRMED to CLOSED as a duplicate. The bug number is added to the duplicate report in order to tell it that there was another person reporting it.
Sometimes the triager or the maintainer would like more information about the bug: the backtrace is not accurate enough because some debug packages are missing, the procedure to reproduce is not clear enough, a screenshot would show the problem better,... A comment is added to ask for more information and the bug is marked as WAITINGFORINFO. The reporter in most cases then adds the information so it's easier to understand the problem and the bug moves back to UNCONFIRMED or NEW.
Developers look at the problem and fix it if they reproduce it or if they find the cause. When it is fixed with a code change, the svn revision is included in the bug report which is then closed. Death of the bug!

Sometimes the bug is from third part components which were not updated correctly to the new libs version (some plasma applets for example that you get from kde-look.org) and the bug is closed as RESOLVED as DOWNSTREAM. You are then invited to report it to the author.

If you want to know more https://bugs.kde.org/page.cgi?id=fields.html describe those fields better.

As you know we are in the process of moving from svn to git. So there are already some KDE dependencies that are not in kdesupport svn anymore but instead they moved on KDE git server.

If you want to/are used to build KDE trunk by yourself, I am trying to keep the techbase doc up-to-date with all these moves. Please see http://techbase.kde.org/Getting_Started/Build/KDE4 and especially http://techbase.kde.org/Getting_Started/Build/KDE4/Prerequisites which deals with kdesupport dependencies.

Please mail me or amend the page yourself if you know of anything that is not written here yet! This is pretty much a day by day process at the moment so be sure to look at it very often!

Yesterday I indicated how one can participate to KDE 4.9 Beta 1 testing phase. There is indeed a Live CD available at http://susestudio.com/a/tAWYe6/kde-plasma-daily 

We are prioritizing the testing of new applets, new applications and new features and we have functional tests ready to be used. Please read my previous post to learn more about this. Janek was the first person doing a functional test of the Now Playing applet and sending a report to the Quality mailing list. He opened 2 bug reports following his tests. Thanks a lot Janek!

Testers test and report bugs. Reporting good bugs is compulsory if we want devels to fix them. We need to make the developers focus on the most important bugs. Stating the KDE version in the "Version:" field in a bug report is compulsory. If you identify a regression, you can add the word "regression" in the "keywords" field. This will help targeting specific bug reports as a priority to be fixed.
I am pleased to report that some bugs have already been fixed and we triaged lots of bug reports, especially in Plasma. I'd like to thank all the users who take time to report bugs and who took time to answer our questions about older reports. We were pleased to see that lots of bug reporters care enough to help us having precise bug reports which will lead to better and quicker fixes.

The Quality Team will conduct a bugzilla training this week-end on IRC in #kde-bugs (freenode) (June 9th and 10th). We will also be available to help people wanting to be part in testing in #kde-quality. Do not hesitate to join if you can spare a bit of time for KDE. I also invite all developers to join this training in order to use bugzilla more efficiently!

Following my last blog post I have been working with Romario, Farhad and Sinny to add the Apply button code in C++ applets: they added the applet they would work on on the wiki page with their name, publish the code on reviewboard , I would check it and test it and sometimes ask the maintainer to double check then they would push or I would if they don't have access. Nearly all the work is now done, thanks to them!

It allowed me to dive into the Git world. It's also amazing how Git experts are patient with us newbies and explain things clearly. So far I understand how to work on master. Next step will be branches!

Meanwhile in KDE-Edu we also are busy preparing the move to git. This also requires collaborative work. We will split the kdeedu module in git and we are preparing this right now in svn: all applications should build standalone. Meanwhile the kdeedu build itself might be a bit broken, you probably need to build and install the lib and then it'll build. Sorry about that. Thanks to Niko preparing the patch and to Jeremy applying it!
For the git move fortunately we have Ian and Nicolas checking all the rules. This is a tedious work as they need to ensure all branches history is also included. I am pleased to see that each application developer took time to check their rules and it shows how lively the KDE-Edu community is: when needed, people rally!

I'll be giving 2 talks at KDE conf.in in Bengaluru: one about how you can contribute to KDE-Edu with practical tips and some tasks to be done in various areas (development, yes, but also promotion, documentation, websites, ...) I plan to have slides (of course) but the slides themselves will be "light" so I'll release a PDF with precise details on what I said and which can't fit on slides! There will be also some wiki pages where people can apply for tasks. I blogged about Plasma Config dialogs in C++ applets to be adapted to suit the Apply button configuration: we coordinated this from a wiki page and 3 new developers stepped in to do the work, which is finished! I hope to generate the same interest about some KDE-Edu tasks.
The second talk will be about KDE documentation and to broaden it a bit, I'll talk about help in general: where can a user find help when she/he needs it in KDE? Again, the slides themselves will be "light" and I'll release a pdf (with sources of course, be LaTeX or .odt, I am not sure yet) which will have the details of what I said.
If you plan to go to the conf (and you should!) be sure to register now! See you there and come to my talks! Also don't miss the keynotes talks, they will be a blast and will give you deep insight about KDE! I can't wait to be there and I have to thank my husband who will be taking the week off to look after the children (it's holiday for the kids).

KDE-Edu is moving to git following kdelibs, kdebase and a bunch of leading projects already there. In git, we will split all KDE-Edu components so you will be able to build say KTouch standalone. We're working on the libs and also we are preparing this split in current trunk svn. That means you still can build kdeedu as a whole module in svn trunk but with building and installing the libkdeedu first. Sorry about that! You can also build components standalone. The move to git should have happened this week but hit some problems due to branches. Thanks to our awesome duo "eean" and "PovAddict" who are doing this work which is quite difficult and demanding. Stay tuned!

After India, there will be a release party in Toulouse for KDE 4.6 and nearly all the French KDE people will be there! We'll be having a general presentation on the Friday 18th followed with some drinks and on the Saturday afternoon we'll have 2 tracks of conferences: users-oriented and developers-oriented. Put this on your agenda and come! Thanks to our sponsors and to the efforts of the guys who made this happen! I'll talk about the KDE community, how we work together, what's the legal structure and so on, it'll be an insight from within KDE.

I have to say this out loud: I am VERY impressed with Google Code-In students. Some of them took videos tasks: KDE is not very good in promotion (to say the least) so we issued some YouTube screencast tasks. The results are very impressive and we get new videos:

• BlinKen on Windows
  
• KStars on Windows
  
• Install KDE on Windows
  
• Konqueror Rocks! very high quality work!

In KDE-Edu we get very dedicated students doing an amazing work! Thanks to them all :-)

Aaron implemented in plasma master (now kdeplasma-addons in in git) the functionality to use the Apply button in the C++ applets config dialogs: when you change a setting, Apply makes the setting visible without closing the configuration dialog.
So the changes were made in some plasma files and now all the C++ applets have to be ported. It's really a very easy job and I did it with the Picture Frame applet (so I could test my git skills and do my first push): you only need to connect all UI widgets in the configuration dialog to the slot SLOT(settingsModified())
Read the mail from Aaron
http://mail.kde.org/pipermail/plasma-devel/2011-February/014888.html
look at my commit for the Picture Frame applet
https://projects.kde.org/projects/kde/kdeplasma-addons/repository/revisions/2a2d1c167c51fd2694b5873665fd669515cc4732

Folderview also is already ported.

If you need help, we'll be happy to provide it on IRC in #plasma or using the plasma-devel mailing list.
You can either send me the patches or push yourself if you have an account.

Please remember to add the applet you are working on and your name on
http://community.kde.org/Plasma/Tasks#config_dialogs

Thanks a lot!

PS: my first problem with git was because my distro version (1.6.4.4) was too old to support separate urls so be sure to have a recent enough git version in order to be able to push. Again thanks to the 24/24 admin support (a Saturday morning!) the problem was quickly spotted! I built git from git and it's all OK now.

I should note that it requires master (as kdelibs and kdebase and kdeplasma-addons are on git). Master is the new term for "trunk".

I was putting together ideas for my talk at conf.kde.in about practical ways to contributing to KDE-Edu. In the process I was trying to list "qualities" that might be useful for new potential contributors and I was asking myself "what is the motivation for other people to contribute to KDE? what is my motivation?"

A few tips on how to write good bug reports:

• write in English: you can switch every KDE application to English in the Help menu. That can help you in explaining what happens.
• be specific: one bug per report only! Do not mix problems in the same report.
• be clear: explain the steps that lead to the bug so that we can reproduce them easily
• include screenshots: a picture is worth many words so attach a screenshot to the bug report (using KSnapshot for example). Do not link to an external web link which can expire, use the Attachments link at the bottom of the bug report.
• include the backtrace within the bug report as a comment, it makes it easier to find duplicates for us (do not attach the backtrace as a text file)
• clearly separate facts from speculation: only describe what happens. For a design problem, include a mock-up if possible.

If you are testing trunk or the beta, if you kept your precedent settings, sometimes you will want to check with a new user or by setings a new $KDEHOME (and restarting your user). Do not delete your $KDEHOME as you will maybe need the current files to compare with the new ones and also you would lose your settings!

The KDE forum has a new section about the Releases and in particular about the Betas for 4.6!

From 10am to 6pm CET on Saturday February 18 on IRC Freenode #kde-devel channel, you are invited to join core developers to contribute to the new KDE Frameworks. Tasks will be prepared, ranging from quite easy to more difficult.
Pre-requisites: Qt 4.8, a build of kdelibs frameworks branch (note the you will need cmake 2.8.7 for it or the cmake git version and a clone of extra-cmake-modules). It is prefered that you do not install Frameworks at the same prefix as your other KDE prefix.
You can also read the Frameworks Community wiki page in order to learn more about Frameworks internals.

Hope you'll join!