Contribute/fr

Cette page est un aperçu de la façon de participer au projet KDE en programmant. Pour plus d'informations sur les autres manières de participer, veuillez consulter le wiki de la communauté KDE et savoir comment vous impliquer.

Ressources : Actualités et courriels

La direction générale du projet KDE est déterminée par ceux qui font le travail - il n'y a pas de planification globale de ce que KDE deviendra dans le futur.

Si vous voulez savoir ce qui se passe en ce moment, il y a un certain nombre de ressources que vous pouvez utiliser :

Listes de diffusion

Sûrement la meilleure façon de se tenir au courant de ce qui se passe dans le développement de KDE. Une liste complète des listes de diffusion est disponible ici et les archives sont ici

CommitFilter

Recevez des notifications aux soumissions de nouveaux codes sources de KDE dans les sections des dépôts qui vous intéressent.

KDE Commit-Digest

Résumé hebdomadaire des soumissions des projets dans les dépôts de code source de KDE.

The Dot

Le site des actualités de KDE.

Reporter des bogues

La façon la plus facile de contribuer à KDE est de reporter tous les bogues que vous trouvez dans KDE en utilisant le Système de suivi de bogues de KDE (aussi connu sous le nom de Bugzilla).

Si l'application que vous utilisez, tombe en panne, alors l'utilitaire Dr Konqi apparaitra et vous guidera au travers du processus d'envoi des rapports de pannes. vers la communauté KDE. Pour en savoir plus, lisez Comment créer des rapports de pannes utiles.

Débuter en écrivant du code

Débuter en codant dans KDE consiste à chercher quelque chose à corriger, et à le corriger. Vous devriez consulter la description générale du module pour essayer de trouver ce que vous cherchez ; une fois la correction faite, vous pourrez l'envoyer sous forme d'un patch. Si vous faites cette opération régulièrement, vous pourrez obtenir un compte d'accès aux dépôts de KDE en tant que Contributeur KDE avec lequel vous pourrez faire vos corrections directement.

• Liste des modules de KDE
• Envoyer des patches
• Obtenir à un compte SVN de KDE
• Premiers pas avec votre nouveau compte SVN

C++

KDE est en grande partie écrit en C++. Si vous n'êtes pas familier avec le C++, vous devriez au moins faire quelques essais avec. Il y a de nombreux excellents ouvrages sur le sur C++ (quelques un en français, les meilleurs et ceux sus-cités sont cependant en anglais) - une source excellente est "Thinking in C++" de Bruce Eckel (en français "Penser en C++"), qui est disponible à la fois en téléchargement gratuit et en document imprimé. Il n'est pas essentiel de tout comprendre avant de commencer avec KDE, mais vous devrez comprendre la syntaxe et les opérations de base.

Qt

Pour devenir compétent en programmation KDE, vous devrez comprendre la boîte à outil Qt. Si vous ne connaissez pas bien Qt, il vous faudra travailler à l'aide des tutoriels inclus avec la documentation de référence pour Qt.

Si vous avez besoin d'une introduction à Qt plus en douceur, ou si vous souhaitez avoir un point de vue alternatif, alors vous pouvez jeter un œil aux fondamentaux du développement Qt.

Si vous préférez apprendre Qt en lisant des livres classiques, faites un tour sur la page des livres qui parlent de Qt. D'autres suggestions sur la manière de se familiariser avec Qt4 sont disponibles sur "Comment apprendre Qt".

KDE

Une palette d'informations sur les technologies de KDE est disponible dans la partie tutoriel. Notez que certains de ces tutoriels sont toujours orientés pour KDE3, cependant ils devraient être au moins partiellement applicables.

Vous trouverez aussi des informations utiles sur la programmation de KDE dans la partie des Foires Aux Questions. Les informations que vous y trouverez, pourraient également être quelque peu anciennes par rapport à KDE4, cependant la plus grande partie est largement applicable, même en dehors de KDE.

Vous pouvez aussi lire des livres sur la programmation de KDE.

Enfin, KDE est lié à des classes étendues (API - Application Programmer Interface - Interface de programmation d'application) qui sont documentées. Cette documentation est dans le Manuel de référence de l'API de KDE, qui contient aussi nombres de liens utiles sur la manière d'écrire ou de mettre à jour la documentation des classes. Vous pouvez aussi la générer sur votre machine, ou vous référer à une version en ligne plus à jour sur la documentation de référence des API, en anglais.

Une description plus détaillée des étapes ci-dessus est disponible dans notre guide du programmeur, en anglais.

Aide contextuelle: qu'est-ce que c'est

Context help is inseparable from the dialogs and widgets, as they are the target of the context help. In fact, in order to write context help, you have to touch programming or programming tools. Indeed, the context help is a property of widgets. In object oriented programming, a property can have different values, and behave differently depending on the value. In Qt/KDE programming, the name of the property is "whatsthis", and its value is the text the context help is going to display.

Fortunately, this task is usually not very difficult, as there are good tools to deal with user interface design, and better, you will use the knowledge acquired here later when dealing with user interface in general. Using the Qt framework (Qt is the base of KDE technology), it is possible to separate code and user interface. You have two basic cases here: the user interface is written with the general code of application (usually .cpp files) or in Qt Designer files (.ui files: it is a XML document). The second case is the best to start with, as it is simpler to work with. If you don't have Qt Designer installed, you can do so by installing the devel package of Qt from your distribution or the Qt Designer package (if your distribution has more fine grained packages).

Here you can find a detailed guide for writing whatsthis using Qt Designer and working directly with the source code: WhatsThis Tutorial, by Aaron J. Seigo.

Participer à la chasse aux bogues et à l'amélioration des applications

Il y a de nombreuses applications au sein de KDE, et nombre d'entre elles manquent d'un mainteneur dédié à la gestion des bogues et plus généralement à la gestion de tous les problèmes liés à la transformation d'un code fonctionnel en une application bien finalisée et bien intégrée.

If you are interested in helping out with KDE, but don't know where to start, becoming a member of the KDE Quality Team might appeal to you - see the Quality Team website for more information. Note that you do not need any programming skills to become involved. In particular developers regularly publish so-called Junior Jobs to encourage new contributions.

Bien sûr, vous pouvez vous investir dans la chasse aux bogues sans faire partie de l'équipe qualité de KDE - créez simplement un compte sur le système de suivi des bogues de KDE, et commencez à fouiner dans les rapports de bogues. Encore une fois, vous ne devez pas nécessairement avoir de compétence en programmation - cela aide beaucoup les programmeurs d'avoir une procédure qui permet à un bogue d'être reproduit avec fidélité.

La Brigade anti-bogue (Bugsquad) effectue un suivi des bogues logiciels de KDE et s'assure que les bogues valides sont pris en compte par les développeurs. Vous n'avez besoin d'aucune compétence en programmation pour faire partie de la Bugsquad ; en fait c'est une très bonne façon de contribuer à la communauté de KDE si vous ne savez pas programmer.

Interface Utilisateur

The KDE Visual Design group is the central studio for KDE user interface design. Their pages on the KDE Community wiki and the very active Visual Design forum are the central places to check out their work and contribute.

User interface is a very wide subject, and of course it is highly subjective. Something that seems obvious to you may seem absurd to others and vice versa. Before making a proposal or entering a discussion, make sure you are ready to state your reasoning clearly, and actively work toward finding common ground with others.

It is easy to perform a quick user interface analysis, but it is hard to convince people to change the interface. A good, convincing analysis can gain much if it incorporates information from the KDE guidelines, competing program and operational system analysis, general design principles found in many books, user testing or individual (anecdotal) feedback. It is a volunteer project, and even if everybody agree with you, someone has to implement it.

In addition to the Visual Design group, the KDE Usability Mailing List is very active and a good place for discussing usability concerns. Their homepage is at http://techbase.kde.org/Projects/Usability. If you are already an usability expert, please check OpenUsability.org, a project that brings open source developers and usability experts together, and is collaborating closely with KDE.

Some documents guiding documents include the KDE User Interface Guidelines (design standards) and KDE User Interface Guidelines (design principles).

Les projets d'analyse d'interface utilisateur peuvent inclure ; - Vérifier que les raccourcis clavier sont cohérents au travers de l'application KDE, être sûr que les dialogues sont en rapport direct avec l'interaction que l'utilisateur attendrait, et trouver des utilisateurs de logiciels KDE pour savoir comment ils effectuent les tâches courantes.

Obtenir des réponses à vos questions

If your question concerns KDE development, your options are pretty much the same general user ones, with some modifications:

• Read the Developer FAQ. Many common developer questions have been answered in the KDE Developer FAQ
• Search/browse KDE websites. A lot of questions can also be answered from the KDE websites, and the documentation included on it. You can search all the KDE websites on the homepage. In addition, you can browse the KDE TechBase website. And if possible, help edit it for clarity, and use the talk page if something is unclear.
• Search mailing lists. A lot of questions have already been answered on the KDE mailing lists, particular the lists kde-devel, kde2-porting, kde-core-devel, kde-games-devel, kfm-devel and koffice-devel. You can search these lists at lists.kde.org. You should always search for your answer before asking questions on the mailing lists. When you ask a question on a mailing list you are emailing thousands of people -- please do this only if the answer is not available through a simple search.
• Search engines. Do not forget about your favorite search engine. One of the best search engines is Google. With Google you can also search the great bulk of Usenet news sites, which is also particularly helpful, especially for general programming and gcc-related questions.

• Read the source code. http://websvn.kde.org and https://projects.kde.org/ are available to help browse code. Read some commit logs and diffs for the code you might want to work with, It adds perspective.
• Ask on KDE mailing lists. If you still do not have an answer, try asking your question on one of the KDE mailing lists.
• For general questions relating to core and third-party KDE development, your first choice is kde-devel (subscribe).
• For questions relating to Qt development, please use the fine Qt mailing lists.
• For questions relating to Konqueror development, your main choice is kfm-devel (subscribe)
• For questions relating to Calligra development, see calligra-devel (subscribe). Krita has a separate mailing list.
• For questions relating to games development, your main choice is kde-games-devel (subscribe)