Développement/FAQs/FAQ générale

Jump to: navigation, search
This page is a translated version of the page Development/FAQs/General FAQ and the translation is 61% complete.

Other languages:
Ελληνικά • ‎English • ‎français • ‎日本語 • ‎Nederlands • ‎polski • ‎português do Brasil • ‎Türkçe • ‎中文(中国大陆)‎

Je veux commencer cette nouvelle application. Que me conseillez-vous ?

Nous sommes tous d'accord qu'il y a plein d'applications KDE à écrire. Mais il y a aussi beaucoup d'applications KDE existantes qui réclament votre assistance.

Pour voir les domaines qui ont besoin d'aide, allez voir cette page.

Avant de démarrer une nouvelle application, il est toujours bon d'aller voir sur KDE-Apps.org et sur d'autres services d'hébergement de logiciels en sources libres comme GitHub, Google Code, et SourceForge pour voir la liste des applications existantes et de demander à la liste de diffusion du developpement KDE si quelqu'un travaille déja sur un projet similaire.

Je suis un développeur, comment puis-je contribuer au logiciel KDE ?

Calligra et KDevelop, bien qu'étant très populaires, ont très peu de développeurs , vous pourriez donc aller voir là-bas. Il n'est pas utile d'être un développeur d'espaces de travail KDE ou de bibliothèques pour la plateforme KDE pour apporter votre aide. L'éventail complet du logiciel KDE est très modulaire et donc vous pouvez parfaitement améliorer un domaine sans connaître le fonctionnement des autres.

Vous pouvez aussi demander sur kde-devel si quelqu'un a besoin d'aide sur une application. Utilisez la dernière version de votre logiciel KDE favorit et identifiez les besoins nécessaires. Un générateur de thème ? Un éditeur de schema en mode console ? Améliorer un jeu ? Il y a toujours un petit détail qui manque. Allez-y et implémentez-le !

Etes-vous familier ou attiré par un domaine spécifique ? Regardez s'il existe une application qui pourrait requierir votre aide. Ou écrivez-en une. KDE accueille plus d'applications qui n'émanent pas de férus.

Je ne suis pas développeur, comment puis-je aider ?

Il existe de nombreuses tâches ne réclamant pas les talents de développeur. Ecrire des articles sur les applications pour promouvoir KDE (voir la liste de diffusion kde-promo) , aider l'équipe de documentation (voir i18n.kde.org/doc), aider aux traductions (voir i18n.kde.org), aider à filtrer les bogues signalés (voir bugs.kde.org).

Où puis-je trouver des images de Konqi le dragon ?

Le Konqi pour quelques personnes SDK se trouve sur ftp.kde.org/pub/kde/devel/konqi_sdk.tar.bz2
Il a été déposé sur artist.kde.org avant que ce site n'ait cessé d'être mis à jour.

Les images suivantes sont sur KDE merchandise. Vous pouvez trouver aussi quelques images Konqi non officielles sur Créer Konqi avec Krita Contest et le jeu SuperTuxKart .

Quel est le niveau requis pour contribuer à KDE ? Que devrais-je apprendre ? Que devrais-je lire ?

Vous devez connaître le C++. Lisez le tutoriel Qt et parcourez la documentation Qt pour être familier avec ce qui est disponible dans Qt. Ensuite lisez les tutoriels KDE et parcourez l'architecture et la documentation. Vous pouvez aussi lire le livre KDE, ça ne peut pas faire de mal. Mais vous ne devez pas être familier avec toute l'architecture de KDE pour être un développeur KDE. Utiliser les technologies KDE est très facile, aussi concentrez vous sur ce dont vous avez réellement besoin, vous pourrez apprendre les autres choses plus tard. KDE TechBase et doc.qt.digia.com (aussi dans votre $QTDIR/doc/html) sont des ressources inestimables, tirez-en avantage. Ensuite, ouvrez les sources, cherchez les répertoires d'exemples, regardez comment les autres ont codé leurs applications. Lire et écrire du code est le meilleur moyen d'apprendre.

Comment obtenir le logiciel KDE à partir des dépôts Git KDE ou SVN ?

Voyez la section Ecrire et exécuter du logiciel KDE à partir des sources sur la page Pour commencer .

Puis-je accéder en ligne au code source KDE source ?

Oui. Il y a plusieurs manières de faire cela :

Que dois-je mettre dans mon .subversion/config ?

You need to add the ignore list to the [miscellany] group in your ~/.subversion/config:

[miscellany]
global-ignores = *.moc *.moc.cc *.moc.cpp config.log config.status \
config.cache *.gmo .deps .libs SunWS_cache *.lo *.la *.rpo *.la.closure \
*_la_closure.cpp *_la_closure.cc *_la_closure.cxx *.all_cc.cc *.all_cpp.cpp \
*.all_C.C *.all_cxx.cxx *_meta_unload.cc *_meta_unload.h *_meta_unload.cpp \
*_meta_unload.C *_meta_unload.cxx index.cache.bz2 .memdump Makefile.rules.in \
Makefile.calls.in Makefile.rules Makefile.calls autom4te.cache *.kidl \
*.o *.lo *.la #*# .*.rej *.rej *.pyc

Et pour demander à svn diff d'ignorer les espaces,et d'imprimer les noms des fonctions :

[helpers]
diff-cmd = /usr/local/bin/_svndiff

avec la suite dans /usr/local/bin/_svndiff:

#!/bin/sh
exec /usr/bin/diff -b -u -p "$@"

N'oubliez pas de rendre /usr/local/bin/_svndiff exécutable.

Je voudraits mettre mon application dans KDE

Il existe trois conditions :

  • Votre application doit compiler avec la dernière version de KDE (git branche master ou SVN trunk).
  • Votre application doit être stable.
  • Votre application doit être maintenue. Vous aurez certainement un bon paquet de rapports d'erreurs et de demandes de souhaits. Les gens s'attendent à ce que vous corrigiez les bogues et implémentiez les souhaits qui ont un sens.

Voyez également la question suivante.

Est-il préférable de développer dans ou en dehors de KDE ?

En tant que dévoloppeur du coeur Waldo Bastian explique dans un courriel patenté:

Faire partie de KDE c'est travailler ensemble avec les autres. Ce type de coopération apporte à la longue des avantages mais implique également des responsabilités.

Quelques uns de ces avantages sont: votre code de retrouve dans toutes les distributions, les gens peuvent corriger vos fautes, vous obtenez des traductions gratuites ainsi que la documentation, vous recevez des tonnes de rapports de fautes.

D'un autre côté, il y a des inconvénients et des responsabilités: vous devrez communiquer avec d'autres développeurs au sujet de votre travail, d'autres personnes pourraient apporter des modifications à votre code, vous devrez respecter les gels de versions, corrigez-les aussi (que fument-ils?), les gens s'attendent à ce que vous gardiez votre code à jour.

Vous ne pouvez pas choisir les avantages et ignorer les responsabilités qui vont avec, c'est un paquetage complet, c'est tout ou rien.

In general it should be the author of a piece of software that chooses to put his application in KDE's repositories. We usually don't put software in KDE's repositories unless the author wishes to do so. The other way around, if the author prefers to work on his application elsewhere then that's his right as well. Unless there is a split in the actual group of people working on the application it makes no sense to fork the development of an application because of that.

BUT... by putting your code under and open source license and putting it in a KDE repository you give the world at large, as well as KDE in particular, the irrevocable right to use your code. And KDE will use that right at its discretion to protect the interests of KDE, even if that goes against the wishes of the author at that point in time.

It is important to know that but don't be afraid. Usually, things work very well. In 5 years, it has only happened once that a developer had his work put kept in KDE while he wanted to remove it.

Comment avoir accès en écriture sur les dépôts KDE ?

Voir l'article complet sur Obtenir un compte de contributeur KDE.

Allez sur KDE Identity, remplissez le formulaire et décrivez pourquoi vous avez besion d'un accès en écriture. Assurez-vous d'avoir bien marqué votre nom et votre adresse courriel.

Please also include the name of your bugs.kde.org account, if non-existent please create one so that it can be given usual developer rights. Closing bugs.kde.org reports with keywords in commit comments only works if the email address of your KDE Identity and bugs.kde.org accounts match. You can change your bugs.kde.org address in the Bugzilla user settings.

Git requires use of an ssh key, and new accounts for SVN must also choose the svn+ssh protocol. Send a public ssh key (e.g. ~/.ssh/id_dsa.pub)

See also #How do I create a SSH key?

If you are contributing to an application that is not yours, it is a good idea to first submitting your coding as patches to the author and let him apply them. If the author is not maintaining his application, you might become the new maintainer...

Although there are few restrictions on repository commit rights, we expect you not to disrupt other developers' code without their consent. You must also respect the feature freezes of the release schedule (published on Schedules page)

Une liste détaillée des règles à suivre lorsque vous validez dans les dépôte KDE sont énumérées dans la police KDE de validation.

Mon application n'est pas stable mais je voudrais l'avoir dans KDE

As a first step, we can put it in playground, which is essentially "kde-alpha". Develop it there and when it is ready, request that your app to be moved to the appropriate KDE package or the extragear module.

Je ne veux pas perdre mon historique SVN.

Ceci n'est plus possible avec les sous-versions. Peut-être dans le futur, si le serveur est mis à jour et le permet. Notez que pour git ce n'est pas un problème.

Qu'est-ce que le kdebindings ?

It contains Qt bindings for Ruby, PHP, C# to use Qt classes with those langages, KDE bindings for Ruby, C#, python to use KDE classes with those langages, and XParts to embed non-KDE apps as a KPart. Check the binding page of TechBase.

Does the feature freeze apply to playground?

No, playground are not a released packages. The same is true for kdereview and extragear: they are not frozen and released. But if you want your app to move to a package, ask for it before the beta-release.

Puis-je avoir une version stable et une version instable de KDE sur le même ordinateur ?

Yes, check Building KDE Software from git.kde.org video series:

Comment savoir la version de Qt/KDE que j'utilise ?

kde-config et toutes les applications KDE acceptent --version comme argument.

Qt-copy or Qt de qt.digia.com: si on devait faire une compilation propre du tronc, que serait-il préférable ?

You can use either. They are binary compatible (forward and backward). There can be, however, a few bugfixes in qt-copy over the most recent Qt release. Especially if building from qt-copy, pay attention to the apply-patches script.

How can I checkout a single directory from a SVN module?

Checkout the top-level dir with 'svn co -N /modulename', 'cd modulename', 'svn up admin' to get the admin/ dir and then finally checkout the dir you want with 'svn up subdir'

For instance, to get only reaktivate from playground/utils: svn co -N /playground/utils; svn up reaktivate Then compile as usual.

The same answer applies to the question "How do I get a single language out of kde-i18n?".

If you don't know the name of the directory you want to check out, you can browse websvn.kde.org to find it.

How can I get one of the KDE application as a standalone tarball?

kdesdk/scripts/svn2dist is a script to extract an application from the KDE source tree and package it as a standalone application.

Comment fermer mes propres rapports de bogue ?

If you reported a bug that is fixed in a new release of KDE but is still reported as open, you can close it. It might happen because your bug is the same as another one, or simply because the developer fixed something without noticing that it would correct your bug.

You can do that from your Subversion commit. To do so, append to your commit message a line like this:

BUG: XXXXX where XXXXX is the bug report you want to close. If the report you're closing is adding a new feature, you can use FEATURE instead of BUG.

Managing a bug list is a huge task for the developers and they usually have a lot of bugs listed, some being fixed already without their knowledge, some being unreproducible, some without enough information to be corrected, etc. If you can help by managing and updating the list of outstanding bugs, you will be gladly welcome. And you will receive an even happier welcome if you provide a patch.

Comment créer une clé SSH ?

SSH makes use of two keys: a private key and a public key. You should keep the private key secret at all times and only place it on machines over which you have direct control. Public, shared, and community machines are not suitable environments to store SSH private keys. Take action to help prevent theft of your SSH private key data. Setting a password on your SSH private key will help reduce the risks involved with private key theft.

Generate a key pair for each major location you work from. This helps to reduce the impact when your key gets stolen. When someone obtains access to your private key, your key can be abused in attempts to compromise KDE servers. Well known open source projects have been compromised this way in the past, YOU must help us to make sure that this doesn't happen with KDE servers as well. For that reason it is important to notify sysadmin (at) kde (dot) org immediately when you notice that someone may have had access to your private key for example when a computer on which it was stored has been hacked or infected with a virus, worm or trojan.

If you choose to make a backup of your SSH private key data, please ensure that any such backup is stored in a secure manner as well.

For the practical part, the following command can be used to generate a SSH private/public key pair with ssh-keygen -t dsa This will create a private key as ~/.ssh/id_dsa and a public key as ~/.ssh/id_dsa.pub.

There are times when you may want to use a key of a different name to the default, perhaps to use separate keys for different projects. To let SSH know which key you want to use for KDE.org, you can keep a list of servers and their corresponding keys in ~/.ssh/config. For example,

Host svn.kde.org 
IdentityFile ~/.ssh/id_dsa_kde

In order to use SSH to access KDE servers you need to send your public key to sysadmin (at) kde (dot) org.

Comment monitorer les modifications faites par les autres ?

The kde-commits mailinglist carries automatic notifications for all changes made in the KDE repositories. The KDE-Commits mailinglist is very high traffic. An alternative is CommitFilter which allows you to get notification for only those areas that interest you.


This page was last modified on 22 May 2018, at 11:18. Content is available under Creative Commons License SA 4.0 unless otherwise noted.