Un aperçu du futur : KDE 2.0

Avec le succès de KDE 1.1, l'environnement de bureau choisi par la plupart des distributions Linux et récompensé au CeBIT, on aurait pu croire que les développeurs KDE se seraient arrêtés là avec le sentiment d'avoir rempli leur contrat : un environnement intuitif, stable et facile à utiliser, basé sur le modèle de développement OpenSource.

Au contraire, le développement repart de plus belle avec la préparation de KDE 2.0, que cet article va détailler.

Afin de respecter la réputation de stabilité de KDE, KDE 2.0 sera une version aussi stable que possible, mais pour les impatients et les aventureux, des versions alpha puis bêta seront disponibles auparavant.

Les enjeux de cette évolution sont majeurs et ambitieux. Parmi eux, on trouve : permettre une internationalisation encore plus générale, continuer l'intégration du bureau, permettre la personnalisation des composants graphiques (styles de widgets), améliorer l'architecture générale de KDE ainsi que l'inclusion de nouvelles applications, dont la suite bureautique koffice.

Pourquoi une évolution non progressive ?

La raison principale de cette évolution brutale de KDE, au lieu d'une évolution progressive comme cela a été le cas jusqu'à présent, est le passage à Qt 2, qui entraîne un certain nombre de changements radicaux, mais c'est aussi l'occasion de retravailler l'architecture de KDE.

Le premier changement apporté par Qt est le passage à l'Unicode, qui permet une internationalisation non limitée aux alphabets composés de caractères 8 bits. Il sera ainsi possible de traduire KDE dans toutes les langues, en particulier le chinois et le japonais. Du côté de KDE, cela implique que les classes Qt, qui intègrent l'Unicode, doivent être utilisées partout où des chaînes de caractères sont traduites et affichées (pas forcément pour celles liées au fonctionnement interne de l'application).

Une seconde révolution apportée par Qt 2 est le support des "styles" de composants graphiques (widgets). Alors que Qt 1.x ne permet de choisir qu'entre les widgets Windows et les widgets Motif, il est possible avec Qt 2 de définir son propre style de composants graphiques. De nombreux styles sont déjà disponibles : style Mac, style NeXT, style gold...

Les styles Qt font partie, pour l'utilisateur, des "thèmes" KDE, qui incluent beaucoup plus. Si l'utilisateur choisit le thème "Mac" par exemple, tout le bureau est transformé pour ressembler à un Mac : les styles de widgets, mais aussi les couleurs, la barre de menu commune aux applications, la bordure des fenêtres, voire les raccourcis claviers...

Pour cela, la configuration de l'ensemble du bureau sera regroupée dans le gestionnaire de thèmes.

Enfin, il faut noter que Qt 2 constitue aussi la fin des réticences de certains puristes concernant KDE : Qt 2 est entièrement OpenSource, car distribué sous la licence QPL.

Nouvelle architecture

L'un des problèmes architecturaux de KDE 1.x est l'omniprésence de kfm : comme nous avons vu avec la partie 2 du didacticiel sur la programmation KDE, il est nécessaire que kfm soit lancé pour que la transparence réseau puisse fonctionner. De même, la gestion des types de fichiers (MIME) est centralisée dans kfm, ce qui a posé problème pour d'autres applications voulant utiliser cette fonctionnalité (kmail par exemple).

La solution était évidente : il a fallu "éclater" kfm, en rendant les classes qui le composent aussi indépendantes que possible et en déplaçant la majorité d'entre elles dans les bibliothèques KDE (kdelibs), afin de partager ces fonctionnalités avec d'autres applications. C'est ainsi qu'est née, par exemple, la bibliothèque "kio" gérant la transparence réseau, "kded", qui centralise la gestion des types de fichiers et applications associées...

L'utilisateur pourra aussi apprécier l'effort de standar disation : KDE 2 augmente la compatibilité avec les autres environnements. En effet, avec l'utilisation de XDND, il sera possible d'effectuer des glisser / déplacer entre applications KDE et applications non KDE. D'autre part, le format des fichiers de configuration des programmes est maintenant normalisé entre GNOME et KDE. Les .desktop de l'un et les .kdelnk de l'autre sont donc fusionnés, en conservant le nom .desktop, plus générique. Ainsi, l'utilisateur pourra utiliser indifféremment GNOME ou KDE et cependant configurer une seule fois les applications, disponibles pour les deux environnements.

La nouvelle architecture inclut de nombreuses autres améliorations, résultat d'un effort à la fois de réduction de l'occupation de la mémoire et de plus grande configurabilité.

Nouvelles technologies (Corba/ Kom/Open parts)

Pendant très longtemps, la communication entre programmes a été un problème difficile à résoudre, bien que le problème se soit fait sentir très tôt. Un exemple simple de l'utilité de la communication entre programmes est celui d'un notificateur de mail (dans le tableau de bord, comme kbiff ou korn) et d'un lecteur de mail (comme kmail). Pour éviter au second de dupliquer le travail du premier, il suffit que le notificateur informe le lecteur de mail. Cet exemple simple a plusieurs solutions, mais qui sont toutes bas niveau et non-objets (messages X, IPC, sockets Unix, ...), difficiles à mettre en oeuvre, à étendre et à maintenir.

L'utilisation de Corba permet de définir une API (interface de programmation) objet et complète, pour chaque application, et d'y accéder depuis d'autres applications. Ainsi, le notificateur de mail, après obtention de l'objet représentant l'interface de kmail, peut déclencher un traitement dans ce dernier par un simple appel de méthode distribuée.

La technologie KOM/OpenParts, basée elle aussi sur Corba, permet beaucoup plus. Cette technologie, comparable à ActiveX de Microsoft, définit un modèle de composants objets pour le développement d'applications distribuées. C'est cette technologie qui permet l'intégration d'un document de koffice dans une autre application de koffice (un diagramme ou une feuille de calcul dans un document texte par exemple). Après l'expérience acquise par l'utilisation d'OpenParts dans koffice, OpenParts peut désormais être déployé sur l'ensemble de KDE, à la hauteur du besoin des applications bien sûr.

Nouvelles applications

Parmi les applications utilisant OpenParts, on trouve konqueror, le remplaçant de kfm (petite anecdote sur le nom du programme : "konqueror" est le troisième dans la série Explorateur - Navigateur - Conquérant).

L'utilisation d'OpenParts dans konqueror permet une très grande flexibilité pour l'utilisateur et le programmeur. En effet, l'idée générale de konqueror est la suivante : bien plus qu'un gestionnaire de fichiers et navigateur web - les éléments principaux de kfm -, konqueror est un navigateur généralisé. Il permet de visualiser non seulement des répertoires et des fichiers HTML, mais aussi des images, des fichiers textes, des dossiers de mail ... la liste est extensible autant que l'on veut. Les visualiseurs sont soit intégrés à konqueror (comme pour les répertoires et fichiers HTML), soit des programmes externes, qui définissent des composants OpenPart, utilisés par konqueror.

Prenons l'exemple du visualiseur d'images. Il n'est pas redéveloppé pour konqueror. C'est le programme KDE actuel, kview, qui, doté d'une interface CORBA, permet à konqueror de visualiser des images dans ses propres fenêtres. Par exemple, lorsque l'utilisateur clique sur un fichier JPEG, konqueror détermine le type de fichier (type MIME), puis consulte les applications qui gèrent ce type de fichier, ici JPEG, en utilisant le mécanisme des fichiers .kdelnk actuel. Parmi ces applications, il choisit celle qui correspond à la préférence de l'utilisateur : lancement standard (le visualiseur apparaît dans une fenêtre séparée) ou lancement incorporé (konqueror utilise OpenParts pour lancer le visualiseur et incorporer la fenêtre de celui-ci dans konqueror).

Dans le deuxième cas, les fonctionnalités du visualiseur sont disponibles dans les menus de konqueror, qui peut même héberger les barres d'outils des applications qui en disposent.

Des photos d'écrans de konqueror sont disponibles sur

http://www.insa-lyon.fr/People/AEDI/dfaure/french.html

D'un point de vue développeur, c'est l'architecture de composants objets distribués qui gère la communication entre processus (Corba), l'activation d'événements entre les processus (KOM) et le partage des ressources (OpenParts). La seule tâche de l'application est de gérer la configuration utilisateur et l'interface graphique de la fenêtre principale, mais elle doit être architecturée pour pouvoir incorporer des composants OpenParts.

D'autres applications, trop nombreuses pour être détaillées ici, feront aussi partie de KDE 2.

Conclusion

KDE 2 constitue un challenge encore plus grand que la série des KDE 1. L'utilisateur appréciera les nombreuses améliorations présentées ci-dessus, dont l'accroissement des possibilités de configuration et la meilleure intégration des applications entre elles. Le développeur, quant à lui, appréciera, en plus du fait de participer à ce formidable projet, l'utilisation de technologies modernes et reconnues dans l'industrie, dont C++ et Corba.

Si vous aussi voulez contribuer (ceci ne concerne pas que le développement, d'ailleurs !), consultez

http://www.kde.org /fr/maman.html. Si vous voulez simplement tester les évolutions de KDE régulièrement, consultez

http://www.kde.org/fr/cvsup.html pour un accès aux sources CVS de KDE et procurez-vous un accès CVS ou des 'snapshots' de Qt 2, en attendant sa sortie officielle.