RMLL 2011 à Strasbourg

Rencontres Mondiales du Logiciel Libre 9 au 14 juillet 2011 Strasbourg Comme l’année dernière je suis allé au RMLL et je suis revenu avec quelques histoires à partager avec la communauté. Je ne vais pas répéter ce que j’ai déjà dit l’année dernière à propos de KDE car ceci est toujours applicable. Néanmoins, la situation avec les environnements de bureau est maintenant très différente de celle de l’année dernière. La disponibilité de Gnome 3 et du nouvel environnement de bureau par défaut d’Ubuntu, Unity, change la vision qu’on les gens de KDE. Ceci entraîne une redistribution des cartes pour les utilisateurs. Un fait indéniable est le très mauvais accueil de Unity de la part des utilisateurs traditionnels de logiciels libres. Cela se traduit par une perte d’intérêt criante d’Ubuntu pour beaucoup d’entre eux et donc la recherche de nouvelles solutions. D’autre part, la réception de Gnome 3 est inégale. Si certains utilisateurs traditionnels de Gnome apprécient toujours le nouveau look et la nouvelle approche, certains autres ne l’aiment pas vraiment. Bien d’autres encore pensent que le nouveau bureau n’est pas fini, comparant parfois avec l’état inachevé qui était attribué à KDE 4.0 quand il est sorti il y a maintenant quelques années. Mais il y a aussi quelques utilisateurs de KDE (il faut avouer qu’ils sont peu nombreux) séduient par le nouveau (et quelque peu inhabituel) look and feel de Gnome 3.

À propos de KDE directement, les utilisateurs sont généralement plus satisfaits par l’environnement et la qualité de la compilation de logiciels qu’ils ne l’étaient l’année dernière, et nous avons eu assez peu de remarques négatives (sauf évidemment celles peux constructives de ceux qui ne l’utilise pas…) . Les plus négatives qui viennent encore et fréquemment, concernent l’utilisation de nouvelles fonctionnalités. Permettez-moi de développer ce point …

Je vais prendre un exemple : les « Activités ». Cette fonctionnalité est très puissante, mais une question récurrente était : « C’est quoi ? Pourquoi devrais-je l’utiliser ? ». Une fois que je fait la démonstration, ils ont rapidement compris combien cette nouvelle fonctionnalité est pratique. Mais ceci montre un vrai problème de communication : les utilisateurs ne savent pas comment utiliser une nouvelle fonction ou pire ne comprenne pas de quoi il s’agit (quand ils savent que ça existe) ! Lorsque je demandais comment résoudre ce problème, la réponse était claire : chaque fois qu’une mise à jour de l’environnement KDE est faite (en particulier KDE-base), nous devrions afficher une fenêtre « Quoi de neuf ? » avec (et ceci semblait important) des liens vers la vidéo de démonstration. Ceci pourrait être généralisé pour chaque logiciel important.

Une préoccupation plus technique est la possibilité de nettoyer les fichiers de configuration de KDE des entrées ou clés obsolètes, évitant ainsi la nécessité d’effacer le répertoire .kde de l’utilisateur de temps en temps (environ tous les deux ans ou un an avec des systèmes mis à jour fréquemment).

Le dernier (mais non des moindres) point concerne la communication de KDE en France. En parlant avec certains contributeurs français de KDE (ou des contributeurs d’autre projets qui aime KDE), le problème de mauvaise représentation de KDE en France est très important. Nous avons besoin de plus d’événements KDE donc plus de personne pour travailler sur la communication (et pas besoin de compétences techniques donc tout fan de KDE peut le faire). Le nouvel évènement Akademy-fr calqué sur le concept espagnol Akademy-es est un bon début mais nous avons besoin de perpétuer l’événement et ce n’est pas encore gagné !

Get Hot New Stuff pour Yakuake

Internet IconEn résultat à la KDE Release Party de Toulouse, j’ai décidé de m’engager dans le code source de KDE. Vu que je ne suis pas familié avec, je devait commencer avec quelque chose de simple. Un bon début était d’intégré une fonctionnalité « Get Hot New Stuff » (c’est à dire obtenir des nouveautés) à la page de configuration des thèmes de Yakuake. Yakuake est un terminal déroulant inspiré par la console de Quake 3 et « Get hot new stuff » (le lien vous mènera à la documentation développeur en anglais) est un moyen simple d’installer graphiquement des éléments supplémentaire aux applications KDE.

Le patch est maintenant prèt et ressemble à ça :

diff --git a/app/CMakeLists.txt b/app/CMakeLists.txt
index 9b34cf3..f46592e 100644
--- a/app/CMakeLists.txt
+++ b/app/CMakeLists.txt
@@ -33,7 +33,7 @@ kde4_add_app_icon(yakuake_SRCS "icons/hi*-app-yakuake.png")

 kde4_add_executable(yakuake ${yakuake_SRCS})

-target_link_libraries(yakuake ${KDE4_KPARTS_LIBS})
+target_link_libraries(yakuake ${KDE4_KPARTS_LIBS} ${KDE4_KNEWSTUFF3_LIBS})

 if(Q_WS_X11)
   target_link_libraries(yakuake ${X11_X11_LIB})
@@ -42,3 +42,5 @@ endif(Q_WS_X11)
 install(TARGETS yakuake ${INSTALL_TARGETS_DEFAULT_ARGS})

 install(PROGRAMS yakuake.desktop DESTINATION ${XDG_APPS_INSTALL_DIR})
+
+install(FILES config/yakuake.knsrc DESTINATION ${CONFIG_INSTALL_DIR} )
diff --git a/app/config/appearancesettings.cpp b/app/config/appearancesettings.cpp
index 7ae00e9..a4b645c 100644
--- a/app/config/appearancesettings.cpp
+++ b/app/config/appearancesettings.cpp
@@ -37,6 +37,8 @@

 #include 

+#include 
+
 AppearanceSettings::AppearanceSettings(QWidget* parent) : QWidget(parent)
 {
     setupUi(this);
@@ -55,7 +57,10 @@ AppearanceSettings::AppearanceSettings(QWidget* parent) : QWidget(parent)
     connect(skinList->selectionModel(), SIGNAL(currentChanged(const QModelIndex&, const QModelIndex&)),
         this, SLOT(updateRemoveSkinButton()));
     connect(installButton, SIGNAL(clicked()), this, SLOT(installSkin()));
+    connect(getnewButton, SIGNAL(clicked()), this, SLOT(getnewSkin()));
     connect(removeButton, SIGNAL(clicked()), this, SLOT(removeSelectedSkin()));
+
+    getnewButton->setIcon(KIcon("get-hot-new-stuff"));

     m_selectedSkinId = Settings::skin();

@@ -223,6 +228,17 @@ void AppearanceSettings::installSkin()
         failInstall(i18nc("@info", "The installer was given a directory, not a file."));
 }

+void AppearanceSettings::getnewSkin()
+{
+  KNS3::DownloadDialog dialog("yakuake.knsrc", this);
+  dialog.exec();
+  KNS3::Entry::List entries = dialog.changedEntries();
+    if (entries.size() > 0) {
+      populateSkinList();
+    }
+
+}
+
 void AppearanceSettings::listSkinArchive(KIO::Job* /* job */, const KIO::UDSEntryList& list)
 {
     if (list.count() == 0) return;
diff --git a/app/config/appearancesettings.h b/app/config/appearancesettings.h
index 1363f70..02397ec 100644
--- a/app/config/appearancesettings.h
+++ b/app/config/appearancesettings.h
@@ -70,6 +70,7 @@ class AppearanceSettings : public QWidget, private Ui::AppearanceSettings
         void updateSkinSetting();

         void installSkin();
+       void getnewSkin();
         void listSkinArchive(KIO::Job* job, const KIO::UDSEntryList& list);
         void validateSkinArchive(KJob* job);
         void installSkinArchive(KJob* deleteJob = 0);
diff --git a/app/config/appearancesettings.ui b/app/config/appearancesettings.ui
index a951568..fa7754a 100644
--- a/app/config/appearancesettings.ui
+++ b/app/config/appearancesettings.ui
@@ -6,8 +6,8 @@
    
     0
     0
-    307
-    355
+    467
+    435
    
   
   
@@ -154,17 +154,7 @@
       Skin
      
      
-      
-       
-        
-         Qt::NoContextMenu
-        
-        
-         Qt::ScrollBarAlwaysOff
-        
-       
-      
-      
+      
        
         
          true
@@ -174,7 +164,7 @@
         
        
       
-      
+      
        
         
          false
@@ -184,13 +174,30 @@
         
        
       
-      
+      
        
         
          false
         
        
       
+      
+       
+        
+         Get New Skin...
+        
+       
+      
+      
+       
+        
+         Qt::NoContextMenu
+        
+        
+         Qt::ScrollBarAlwaysOff
+        
+       
+      
      
     
    
@@ -198,15 +205,15 @@
  
  
   
-   KColorButton
-   QPushButton
-   
kcolorbutton.h
-
- KLineEdit QLineEdit
klineedit.h
+ + KColorButton + QPushButton +
kcolorbutton.h
+
kcfg_TerminalHighlightOnManualActivation @@ -214,6 +221,7 @@ kcfg_Translucency kcfg_BackgroundColorOpacity skinList + getnewButton installButton removeButton kcfg_Skin

Un fichier appelé yakuake.knsrc doit être ajouté au répertoire app/config du répertoire source de Yakuake. Voici son contenu :

[KNewStuff3]
ProvidersUrl=http://download.kde.org/ocs/providers.xml
Uncompress=always
TargetDir=yakuake/skins
Categories=Yakuake Skin

J’espère que cela sera bientôt ajouté au code source officiel de Yakuake. Pour l’instant vous pouvez essayer d’appliquer le patch et de compiller et installer Yakuake si vous voulez « Get Hot New Stuff » avant que la prochaine version de Yakuake ne sorte. Pour le faire, essayez ceci :

git clone git://anongit.kde.org/yakuake
cd yakuake
wget http://www.geoffray-levasseur.org/files/yakuake-gethotnewstuff.patch
wget http://www.geoffray-levasseur.org/files/yakuake.knsrc
mv -fv yakuake.knsrc app/config/
patch -Np1 -i yakuake-gethotnewstuff.patch
mkdir build && cd build
cmake ./ ../ -DCMAKE_INSTALL_PREFIX=$KDEDIR
make
su -c "make install"

Assurez-vous d’abord que le paquet Yakuake de votre distribution est désinstallé et que la variable d’environnement KDEDIR pointe correctement vers votre préfixe d’installation de KDE (la plupart du temps /usr ou /opt/kde4). Vous devrez taper votre mot de passe root après avoir validé la dernière ligne. Amusez-vous !

De retours des RMLL 2010

Rencontres Mondiales du Logiciel Libre 6 au 11 juillet 2010Il y a un mois environ, j’étais à l’édition 2010 des RMLL se déroulant à Bordeaux. J’étais l’un des types qui représentait KDE dans le village associatif. Ce billet vous racontera ce qu’il c’est passé et mes impressions. Les RMLL sont le plus grand rassemblement concernant le logiciel libre en dehors de Paris. Pour cet évènement, KDE était représenté pour la première fois. Tout ceci s’est tenu du 6 au 9 juillet 2010 à l’université de Bordeaux à Talence et les 10 et 11 juillet sur les quais de la Garonne au centre ville de Bordeaux (près du skate park pour ceux qui connaissent).

Personne présente

Malheureusement, l’aKademy 2010 se déroulant à Tampere, en Finlande avait lieu au même moment, ce qui ne nous à pas permit d’avoir de développeurs pour les RMLL. En fait nous n’étions que des traducteurs de KDE et des passionnés. Le staff était donc :

Staff du stand KDE des RMLL

Nom Présent du Au Rôle au sein de KDE
Geoffray Levasseur Lundi 5 Juillet Dimanche 11 Juillet Traduction, beta-test et rapport de bogue
Hélène Dervillez Lundi 5 Juillet Jeudi 8 Juillet Utilisateur
Ludovic Grossard Mercredi 7 Juillet Vendredi 9 Juillet Coordinateur de traduction des documentations
Philippe Nenert Lundi 5 Juillet Jeudi 8 Juillet Utilisateur

Je souhaite remercier Jimmy Pierre et l’ensemble de personnes du stand OpenSuse qui m’ont beaucoup aidé le weekend aux moments ou j’avais besoin de quitter le stand.

Ce que les gents qui n’utilisent pas KDE pensent

Il y a trois types de personne qui n’utilise pas KDE. Ceux qui n’utilisent toujours pas de système libre, utilisant principalement Windows ou Mac-OS, ceux utilisant un autre environnement de bureau et ceux qui utilisaient autrefois KDE et qui ont changés pour un autre environnement de bureau.

Les personnes qui n’ont jamais utilisé Linux ou BSD sont toujours très impressionnées par la qualité de l’environnement et surpris par le nombre d’applications disponibles, particulièrement les utilisateurs de Windows. La plupart ne connaissaient rien à propos de KDE mais étaient intéressé par les logiciels libres. Le multi-bureaux, les plasmoïdes et les effets graphiques en 3D sont considérés bien plus impressionnant que ceux qu’ils peuvent voir dans Windows, cassant quelques mythes, du genre « Linux c’est moche »… Donc, pas mal de bons points mais le mythe « Linux c’est compliqué » est plus difficile à dissiper. Pour la démonstration des logiciels, ils sont d’accord pour reconnaitre la facilité et la puissance globale des applications mais des questions comme « je pourrais installer le logiciel XXX que j’aime » et que je réponds que non mais que l’application YYY existe et fait la même chose (le plus souvent en mieux d’ailleurs) ils sont alors effrayés du changement. Le plus souvent ils sont d’accord pour essayer (ils seraient pas la sinon) car les avantages sont visible, principalement financier, l’argument philosophique étant considéré comme un bonus. Les propositions de live CD ont eu plus de succès que celle du dual-boot même si tout le monde le voit comme une bonne idée.

Les personnes utilisant déjà Linux et/ou BSD connaissent bien mieux KDE. Il y a cependant une exception : les utilisateurs récemment convertis. Voila mon coup de gueule : j’ai un problème avec certains LUGs qui ne demande pas son avis à l’utilisateur et leur installe toujours une p****n d’Ubuntu de m****e pendant les installe-party ! C’est pourquoi beaucoup de nouveaux utilisateurs de Linux ne connaissent rien à propos des autres distributions Linux et rien à propos de KDE (ou de n’importe quel autre environnement de bureau). Ils font, ainsi, la même erreur que les vendeurs d’ordinateurs qui de la même façon ne donne pas le choix en imposant un système d’exploitation bien trop connu. Néanmoins, ces personnes sont souvent satisfaites par l’environnement de KDE pendant les démonstrations et beaucoup disent qu’ils essayeront en installant les paquets nécessaires ou même en essayant une autre distribution (OK, j’admet que mon effort de promotion était très orienté OpenSuse ou Mandriva, plutôt que Kubuntu mais pour une bonne raison : de bien meilleures intégrations de KDE). L’utilisateur expérimenté connais toujours KDE, l’a essayé, et fait son choix en fonctions de ses gout et priorité. Ce type d’utilisateur est toujours d’accord pour reconnaître la qualité de certaines de nos applications notamment K3b (presque toujours en fait), Amarok, digiKam et la suite PIM.

Les cas les plus délicats sont les personnes qui utilisait KDE 3.5 et ont cessé de l’utiliser après la sortie de KDE 4. La plupart d’entre eux ont essayé KDE 4.0 or 4.1 et furent énormément déçu par le nouveau bureau considéré à l’époque lourd et très instable et plus encore que cela, ils n’ont pas accepté la perte de certaines fonctionnalité et / ou applications. La plupart du temps ils regrettent leur ancien bureau et ne sont pas pleinement satisfait de leur environnement de bureau actuel (Gnome le plus souvent) car en attente de quelque chose de proche de KDE 3.5. En réalité, il y a un cruel manque de communication de notre part car beaucoup d’idée fausse courrent : Konqueror ne peut plus être l’outil universel car ce n’est plus le gestionnaire de fichier, je ne veux pas ou je n’ai pas besoin des effet 3D, je n’aime pas le nouveau menu/bureau, ou sont les icônes du bureau…. J’ai entendu tout ceci régulièrement. Pourquoi ne pas créer un thème KDE 3.5 qui ravira ces personnes ? C’est simple: faire de Konqueror le gestionnaire de fichier par défaut, désactiver les effets 3D, placer l’ancien menu comme menu par défaut et activer le modèle en icônes de bureau de Plasma. Je fus capable de monter un tel bureau et tous ceux qui se plaignaient de KDE 4 ont adorés. Je leur ai conseillé de choisir quelque chose comme Mandriva pour laquel les paramètres par défaut font beaucoup penser à KDE 3.5. Á propos de la perte de fonctionnalité et des problèmes de stabilité et de performances j’ai pu leur faire remarquer que ces problèmes étaient en grande partie réglés.

Utilisateurs de KDE

Inutile de précher un convaincu… Curieux de savoir ce que ces convaincus aiment ou pas, quel sont leurs applications favorites ou détestées, j’ai posé beaucoup de questions. Les résultats étaient très cohérent. Ce qu’ils aiment du bureau est la cohérence globale entre les applications KDE et le bureau, les jolies choses efficaces qu’il peuvent avoir avec Plasma et KWin (je met ça dans la même catégorie que l’opportunité d’épater les copains qui sont encore sous Windows ;)) et la très bonne qualité des applications. En parlant des applications, les plus plébicités sont K3b (je fus impressionné par sa popularité même avec des utilisateurs non-KDE), Amarok, digiKam, Gwenview et la suite PIM (praincipalement KMail).

Ce qu’ils n’aiment pas c’est la lourdeur du bureau et le manque de stabilité de KWin et Plasma (trop de crash que je n’ai pu démentir en ayant subi moi-même) [ndlr : corrigé avec KDE 4.6] , un suivit de dévellopement des Plasmoïdes trop alléatoire (principallement des exotiques disponible dans OpenSuse ou Mandriva issus de Playground). Concernant les applications qui ont besoin d’amour (et oui, je lis parfois les interviews des développeurs), la plus cité est Kopete (surtout la prise en charge audio/vidéo) et Dolphin et Konqueror (surtout leur stabilité, et la gestion très aléatoire de Flash/AJAX dans Konqueror). Certains développeurs (qui ne font même pas de Qt) m’ont dit que KDevelop 4 avait une très mauvaise intégration des systèmes de controle de révision (CVS / Mercurial / Git). Une fonctionnalité qui manque cruellement aux adeptes de KDE 3.5, est la possibilité de se connecter en tant qu’administrateur grâce à un bouton dans certain modules de configuration du centre de contrôle. Enfin certains regrette la disparition de Quanta.

Ce que je fais ces derniers temps…

News iconJe sais que j’ai été absent pendant un moment, mais c’était pour de très bonnes raisons. Je travaille beaucoup sur de gros articles et projets, et vous en aurez les résultats très bientôt. Pour les plus impatients voici la feuille de route :

  • YaPeTaVi est actuellement dans une phase de transformation importante. Je travail sur de gros changements structurels du projet qui mèneront à de très bonnes améliorations. D’abord, la page de configuration des filtres va changer totalement. Le système actuel va disparaitre au profit d’un système de liste et de fiches contextuelles. En plus, beaucoup d’autres informations seront disponible telles que les énergie de seconde et troisième ionisation, une toute nouvelle liste des découvreur avec une courte biographie, des images avec descriptions pour chaque éléments (photo en bitmap et configuration électronique en SVG). Enfin mais non des moindre, une interface plus agréable, avec un nouveau système d’aide contextuelle. Bien plus est encore à venir.
  • La partie II de l’article « Construire KDE 4 depuis trunk » est en phase de préparation. Après des essais et beaucoup d’heure de compilations, j’ai changé ma première idée qui était d’envoyer un nouvelle article sur ce blog avec des informations mises à jour. Vu les immenses possibilités et mes bonnes expériences, je travail sur un gros et complet tutoriel alternatif à celui donné sur le site officiel techbase de KDE. Malheureusement, vu que je travail essentiellement sur une Debian, le tutoriel risque d’être un peut spécifique à Debian. C’est pourquoi, cette page sera mise à jour régulièrement en fonction de vos retours et conseils.
  • Enfin vous vous rappelez probablement de mon article à propos de la création d’un routeur avec une vielle machine et un Linux. Une mise à jour est à venir avec la prise en charge de l’uPnP (universal plug and play) qui est une méthode très pratique et sure de configurer votre routeur en fonction des applications que vous utilisez. Malheureusement, ceci prend du temps puisqu’il me faut faire beaucoup de recherches pour le faire correctement.

Voici donc un programme énorme et très intéressent, donc, à très bientôt…

Construction de KDE 4 depuis trunk : Partie 1

KDE LogoIl y a plusieurs mois j’utilisais une Debian Lenny / Sid et j’avais l’habitude d’utiliser KDE 3.5.x. KDE 4.0 était sur le point d’être lancé, mais il n’était pas utilisable pour la production. J’ai donc décidé d’utiliser KDE 4, d’après les instructions du site TechBase. Aujourd’hui, je suis sous KDE 4.2.4 depuis les dépôts de Debian Sid. Néanmoins, le support de KDE 4 sous Debian est toujours un affreux désordre. De nombreux logiciels ne sont pas encore disponibles pour KDE 4 même si une version stable existe (par exemple, Amarok ou Kile). En plus, la stabilité du bureau de base est horrible et de nombreux bugs sont spécifiques à Debian (la version OpenSuse est très stable). Je ne veux pas quitter Debian car mon système est encore assez rapide et plus fiable que dans le passé avec openSUSE.

Un autre point est que j’ai besoin d’une version de développement (à partir de SVN) de KDE 4 et d’être en mesure de faire quelques tests. Après discussion avec de nombreux développeurs sur le canal IRC de KDE, j’ai été convaincu que la version SVN de KDE 4 (l’actuel trunk est la future version 4.4) est assez stable pour être utilisée pour la production.

Maintenant, voici mes projets…

La version de Qt fournis par Debian (4.5.1) a des dépendances avec Phonon, et j’ai besoin de construire une version SVN de Phonon (la version de Debian est trop ancienne). J’ai donc besoin de supprimer tous les logiciels dépendant de Qt, en utilisant aptitude ou synaptic sous une session non KDE (j’utilise Xfce pour ça). Notez tous les logiciels basé su Qt ou KDE doivent être fermées avant la désinstallation, sinon, vous pourriez avoir une étrange réaction de votre système. Lorsque aptitude ou synaptic vous montre la liste des logiciels qu’il est sur le point de désinstaller, il est préférable de le noter pour être capable de récupérer tout ce dont vous avez besoin. Vous aurez à compiler et installer tous ces logiciels manuellement.

Le site Web TechBase de KDE fournis de très bonnes instructions de compilation et d’installation, mais il propose de l’installation sous un compte utilisateur spécial ce que je ne veux pas. Je vais devoir faire autrement. D’abord, le meilleur moyen pour fixer des variables d’environnement pour tous les utilisateurs est de créer un script d’initialisation. Je décide de l’exécuter principalement dans le niveau d’exécution 3 car le serveur X peut être exécuté manuellement toute façon, même si nous ne sommes pas en niveau 5. J’ai donc créer le fichier « /etc/rc3.d/S40kde4 »:

# Begin /etc/rc3.d/S40kde4
if [ ! -d /tmp/${USER}-kde4 ]; then
mkdir /tmp/${USER}-kde4
fi
export KDEDIR=/usr/
export KDEDIRS=$KDEDIR
export KDETMP=/tmp/$USER-kde4
export STRIGI_HOME=${KDEDIR}
export QT_PLUGINS_DIR=$KDEDIR/lib/kde4/plugins:$QTDIR/lib${QT_PLUGINS_DIR+:}$QT_PLUGINS_DIR
export PATH="${PATH}:${KDEDIR}/bin"
export PKG_CONFIG_PATH="${PKG_CONFIG_PATH}${PKG_CONFIG_PATH+:}${KDEDIR}/lib/pkgconfig"

# End /etc/rc3.d/S40kde4

Vous pouvez modifier le chemin de base si vous le voulez, mais celui que j’utilise, respecte les directives Debian. Notez que la variable KDEHOME est définie par Debian dans un autre script. Il n’est donc pas sûr de la redéfinir. Lorsque le fichier est enregistré (vous devez être root), vous devez le rendre exécutable et il est aussi plus sûr de copier ce script pour l’exécuter dans certains autres niveau. Ceci est réalisé en exécutant les commandes suivantes en tant que root:

chmod -v +x /etc/rc3.d/S40kde4
cp -v /etc/rc3.d/S40kde4 /etc/rc2.d/
cp -v /etc/rc3.d/S40kde4 /etc/rc4.d/
cp -v /etc/rc3.d/S40kde4 /etc/rc5.d/

Il n’est pas utile de le copier dans les répertoires de niveau d’exécution 0, 1 ou 6 (respectivement arrêt, mono-utilisateur et redémarrer). Ensuite, vous devez mettre à jour votre profil général et la session utilisateur, si vous ne voulez pas redémarrer:

/etc/rc3.d/S40kde4
source /etc/profile

Avant de continuer sur l’une des prochaines étapes, vous devez installer toutes les dépendances de construction en suivant les étapes indiquées ici.

Si vous avez un message d’erreur à ce stade, vous devriez vérifier votre configuration et les étapes précédentes. Une fois ceci fait, vous êtes prêt à compiler, mais pour rendre la tache plus facile, il est préférable de créer un script de compilation automatique. J’ai fait celui-ci, appelé «kdemake.sh »:

# Begin /usr/bin/kdemake.sh
if test -n "$1"; then
                # Source folder is defined via command line argument
                srcFolder="$1"
        else
                # srcFolder is the current dir
                srcFolder=`pwd`

# default build directory is a build subdir inside the source folder
# -DCMAKE_INSTALL_PREFIX is forcing install prefix to the above definition
# -DKDE4_BUILD_TESTS=TRUE is optional and build test suite
# -DCMAKE_BUILD_TYPE=debugfull is optional and build full debugging information
cmake ${srcFolder} ${srcFolder}/build/ -DCMAKE_INSTALL_PREFIX=$KDEDIR -DKDE4_BUILD_TESTS=TRUE -DCMAKE_BUILD_TYPE=debugfull
cd ${srcFolder}/build/

# nice make -j3 force make à utiliser deux processeur (pour les dual core) remplacer par -j2 si vous avez un système mono-processeur
nice make -j3 && sudo make install
# note that sudo will ask you root password to install

# End /usr/bin/kdemake.sh

Rendre le script exécutable avec:

chmod -v +x /usr/bin/kdemake.sh

Si vous exécutez ce (très simple) script, il est supposé que tous les répertoires de construction ont été créées comme des enfants des répertoires contenant les sources… Alors, voici un exemple pour la compilation du paquet kdelibs:

svn checkout svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs
cd kdelibs
mkdir build
kdemake.sh

Ceci ne sera fait que la première compilation, ensuite, il vous suffira de mettre à jour et compiler ce qui est nécessaire (c’est pourquoi cmake est tellement bon), en faisant ceci:

cd /kdelibs
svn up
kdemake.sh

Si, comme moi, vous préférez procéder manuellement, oubliez tout ceci. Par contre, c’est une bonne idée de créer une variable contenant les paramètres systématique de cmake (de cette manière vous pouvez passer d’autres paramètres comme vous le souhaitez). Pour moi, je l’appelle « CM ». L’autre chose très utile consiste à créer un alias pour make, appelée fmake pour « fast make », lui permettant d’utiliser les deux processeurs de votre dual core si vous avez un (le problème est que fmake n’acceptera pas d’autres paramètres comme le ferais make à cause de la commande nice qui les prendrais pour elle) :

export CM=-DCMAKE_INSTALL_PREFIX=$KDEDIR -DKDE4_BUILD_TESTS=TRUE -DCMAKE_BUILD_TYPE=debugfull
alias fmake=nice make -j3

Vous pouvez ajouter ces lignes dans le script d’initialisation ci-dessus, de cette façon ce qui y est déclaré sera toujours disponible. Ensuite vous pourrez faire le même boulot qu’au dessus, de cette façon:

svn checkout svn://anonsvn.kde.org/home/kde/trunk/KDE/kdelibs
cd kdelibs
mkdir ../build
cd ../build
cmake ../kdelibs $CM
fmake
make install

Le système minimum de KDE est kdesupport, kdelibs, kdepimlibs et kdebase. Vous devrez le compiler dans cet ordre en raison des dépendances. Pour installer le bureau KDE complet vous devrez compiler kdeadmin, kdeaccessibility, kdeartwork, addons kdebindings, kdeedu, kdegames, kdegraphics, kdemultimedia, kdenetwork kdepim, kdeplasma, kdesdk, kdetoys, kdeutils, KDevelop, kdevplatform et kdewebdev. Vous pouvez compiler certains de ceux-ci ou tout dans aucun ordre particulier. La seule exception est kdevplatform requis par KDevelop et kdewebdev qui doit être compilé en premier. Après cela, vous pouvez explorer le WebSVN de KDE pour trouver plus de logiciels qui pourrais vous intéresser. Vérifier les répertoires playground, extragear, koffice pour la suite bureautique de KDE et l10n-kde4 pour la localisation dans votre langue.
Quand tout sera construit pour moi, testé et approuvé, la deuxième partie sera là comme rapport de l’expérience (de même qu’avec les vôtres via vos commentaires) et correction des erreurs contenues dans ces instruction.
That’s all folks… pour le moment !

Site web de KDE : une nouvelle fonctionnalité ?

KDE LogoIl y a deux semaines, je parlais avec Anne-Marrie Mafhouf à propos d’une nouvelle fonctionnalité dans la zone de développement du site de KDE. Cette idée m’est apparue, quand quelqu’un m’a dit sur le canal IRC des développeurs KDE qu’il y avait problème avec un programme que je traduis, KDETV, parce que certains de ses principaux développeurs avais quitté le projet.

Peu importe si cette information est totalement vrai ou non mais je sais que certains projets ont été abandonnés dans le passé (KBabel par exemple) en raison d’un manque de développeurs. D’autres projets sont en croissance très lente en raison du manque d’éléments (graphiques, sons, fonctions essentielles…).

La solution consiste à créer une zone spéciale dans le site de développement de KDE pour centraliser les besoins des développeurs et utilisateurs. Je pense que c’est très bon pour beaucoup de raison:

  • Les nouveaux développeurs peuvent visiter cette zone et être guidés. Certains nouveaux développeurs sont parfois perdus, face à l’incroyable quantité de projets et de code source. Dans le même temps, si nous avons plus de nouveaux développeurs sur certains vieux projets au fur et à mesure qu’ils deviennent expérimentés, nous avons bien moins de chance de perdre un projet en raison d’un manque de développeurs.
  • Les développeurs peuvent donner quelques idées de nouvelles fonctionnalités qui pourraient être intéressantes dans le projet, à plus forte raison si ils ne savent pas vraiment comment les réaliser.
  • Les demandes de fonctionnalité des utilisateurs pourraient être concentré, fournissant un accès plus facile pour les responsables et les développeurs.

J’ai un peu de temps pour pouvoir gérer cette partie du boulot ;), et quelque chose comme un Wiki devrait être adaptés. Cher gourou de KDE, s’il vous plaît, dites-moi ce que vous penser.