BerndPol développement &UNIX; développement historique langages de scriptage &UNIX; historique &UNIX; tube &UNIX; shell shell &UNIX; Dès le début, &UNIX; a maintenu deux paradigmes de développement très différents. L'un est le monde des langages de programmation de systèmes et d'applications, dans lequel du code source est traduit en code machine par un programme de traduction, le plus souvent un compilateur ou un interpréteur. Le langage de programmation C en est un exemple. UNIX a été le premier noyau de système d'exploitation à être écrit dans un langage de si haut niveau au lieu d'un assembleur strictement orienté machine, qui était courant avant cette époque. (En fait, le langage C aurait même été inventé pour écrire le noyau UNIX et les programmes associés sur un ordinateur PDP-11 DEC.) L'autre paradigme est le monde des langages de scriptage. Cet univers a évolué avec l'invention du shell &UNIX; qui était l'interface de l'utilisateur au système d'exploitation — et en même temps, un langage de programmation de très haut niveau. Un script shell est constuit à partir d'un ensemble de petits programmes utilitaires comme &pex; grep, sed ou find. Chaque utilitaire de ce type est conçu pour une tâche rigoureusement définie. L'astuce est qu'un tel utilitaire peut être connecté à un autre via un mécanisme de transport simple, appelé tube, qui dirige la sortie de l'utilitaire précédent vers l'entrée de l'utilitaire traité ensuite. Ce mécanisme crée un outil de programmation très puissant et extrêmement souple. Au fil du temps, les deux mondes ont évolué. Tandis qu'on utilise encore le C comme langage de programmation système, le C++, en tant que variante du C enrichi par les extensions orientées objet et génériques, a trouvé sa place dans le développement d'applications complexes dans les années 1990. Il y a de nombreux autres langages de programmation, même de plus anciens restent d'actualité — FORTRAN77 et Ada &pex;, défendent toujours leurs positions dans le secteur des applications numériques. Dans le domaine du scriptage, on a connu la mise à l'écart du shell, qui souffre de problèmes de portabilité, vers des langages qui unifient toute la fonctionnalité habituellement nécessaire dans leurs bibliothèques standard, bien qu'il soit toujours capable d'interfacer vers l'extérieur via des tubes en cas de nécessité. Tous ces langages de scriptage ont en commun d'être extrêmement portables entre les variantes &UNIX;, Microsoft &Windows;, &Mac; OS, voire VMS. En outre, tous offrent des implémentations largement dstribuables. Perl langages de scriptage Perl &perl; est un langage d'admnistration système et de traitement de texte. Dans les débuts du World Wide Web, les scripts CGI écrits en &perl; étaient une méthode largement utilisée pour créer des pages web dynamiques à partir de bases de données. Aujourd'hui, cette méthode a été remplacée en grande partie par le module externe mod_perl pour le serveur web &apache;. Parmi les atouts de &perl;, citons sa gestion intégrée de la correspondance des expressions rationnelles et ses abondantes archives de modules librement distribués. Pour plus d'informations, visitez le site web Comprehensive Perl Archive Network (CPAN). Python langages de scriptage Python &python; brille par l'élégance de son système de classes ainsi que la facilité et la souplesse avec laquelle des bibliothèques externes peuvent être encapsulées de telle manière qu'elles apparaissent comme des classes et des fonctions &python; standard. Contrairement à &perl;, &python; a une API d'intégration claire et concise, qui en fait le langage de choix pour créer des programmes C et C++ sous forme de scripts. PHP langages de scriptage PHP &php; a été inventé en tant que langage directement intégrable dans des pages &HTML; et a en conséquence ses principales utilisations se situent dans la production de contenu dynamique sur le Web. Les applications &UNIX; de niveau plus élevé font habituellement l'impasse sur la vitesse et la souplesse des mécanismes traditionnels du scriptage shell orienté caractères. Ce comportement est particulièrement vrai dans le monde des interfaces graphiques utilisateur (&GUI;) comme &pex; &kde;. Il y a eu des tentatives visant à proposer des mécanismes similaires qui fonctionnent sur un niveau d'application plus élevé, le plus notable étant CORBA et, dans l'environnement &kde;, &DCOP;. CORBA langages de scriptage CORBA communication CORBA CORBA (Common Object Request Broker Architecture) est une tentative pour faire interagir des applications informatiques sur des réseaux. Il a été élaboré par le comité de standardisation OMG (Object Management Group) composé de fabricants privés, indépendants. Les programmes basés sur CORBA utilisent le protocole standard IIOP pour communiquer. Les implémentations basées sur IIOP sont disponibles sur un large éventail de systèmes d'exploitation, de langages de programmation, sur les réseaux et sont donc hautement portables. Le principal inconvénient de CORBA réside dans sa vitesse plutôt réduite. Bien que cela puisse être admissible pour les réseaux, c'est un véritable obstacle pour les communications inter-applications dans un environnement non géré par réseau tel que &kde; fonctionnant sur un seul ordinateur. DCOP langages de scriptage DCOP communication DCOP Une autre évolution sur le scriptage de type &UNIX; est le protocole DCOP mis au point pour la communication entre les applications &kde; pour venir à bout des limitations de CORBA. DCOP signifie Desktop Communication Protocol et est implémenté à titre de mécanisme IPC/RPC simple construit pour agir sur des sockets. En effet, celui-ci offre des fonctions similaires au mécanisme traditionnel des tubes &UNIX;. Le scriptage shell traditionnel est basé sur de petits programmes utilitaires conçus pour fonctionner sur une base strictement textuelle. &DCOP; permet d'élaborer des programmes graphiques pour communiquer d'une manière assez similaire. Ceci permet &pex; à un programme &kde; d'envoyer des messages à un autre programme &kde; ou d'en recevoir des données pour ses propres objectifs. Il y a des inconvénients, cependant. Pour utiliser &DCOP;, un programme doit être conçu pour contenir une interface &DCOP; spéciale. De plus, le processus de communication &DCOP; s'exécute assez lentement (bien qu'il soit beaucoup plus rapide que CORBA). Mais il renvoie une grande partie de la puissance et de la souplesse du scriptage &UNIX; aux programmes de haut niveau basés sur une interface graphique utilisateur. Pour plus d'informations, lisez l'article DCOP: Desktop COmmunications Protocol ou la référence à l'&API; The &DCOP; Desktop Communication Protocol library de la bibliothèque dcop de &kde;. Sauf dans des cas très simples, un projet de programmation se compose d'un grand nombre de blocs de code source placés chacun dans un fichier séparé pour faciliter la maintenance. Pour que ceci fonctionne, il faut en effet traduire tous ces éléments en quelques unités de langage machine, dans un format approprié permettant au système d'exploitation de charger et d'exécuter le programme. Pour ce faire, les outils de base nécessaires sont un éditeur de texte pour écrire les fichiers de code source, un programme de traduction, habituellement un compilateur pour transformer le code source en fichiers objets, un gestionnaire de bibliothèques qui collecte des fichiers objets dans les bibliothèques pour les réutiliser aisément sans qu'il soit nécessaire de recompiler, un éditeur de liens qui associe plusieurs fichiers objets et les bibliothèques en un exécutable, un système make qui fournit un moyen de gérer tous ces éléments et — sans oublier un débogueur pour (si tout se passe bien) trouver toutes les erreurs dans le programme et éventuellement quelques autres outils de diagnostic pour arriver à ce que tout fonctionne parfaitement. Lorsque vous avez un gros projet se composant peut-être de centaines de fichiers de code source, le processus de compilation peut devenir assez laborieux. Vous ne voulez pas recompiler tous les fichiers chaque fois que vous n'en avez changé que quelques-uns. À la place, vous souhaitez uniquement compiler ces fichiers qui sont modifiés par les changements. En général, il n'est pas toujours facile de voir lesquels parmi les fichiers doivent être recompilés. Quand &pex; vous changez un prototype de fonction dans un fichier d'en-tête, vous devez compiler chaque fichier incluant ce fichier d'en-tête. Si votre projet contient un grand nombre de fichiers de ce type, il est facile d'en sauter un ou deux si vous devez effectuer cette tâche manuellement. Par conséquent, un moyen d'automatisation est nécessaire. make Makefile règle recompilations cible dépendances commandes Un outil qui se charge des recompilations est make. Il garde la trace de l'ensemble du travail grâce à un ensemble de règles décrivant ce qu'il faut faire au cas où un élément d'information (habituellement un fichier de code source ou objet) a été modifié. Toutes les règles appartenant à un projet donné sont enregistrées dans ce qu'on appelle unMakefile, qui est traité par make chaque fois que vous souhaitez mettre à jour votre travail. Chaque règle se compose de plusieurs blocs de construction, à savoir une cible, &cad; le fichier à construire un ensemble de dépendances, essentiellement les noms de ces fichiers dont la cible est tributaire (&pex;, le nom d'un fichier source, dans lequel la cible sera le nom du fichier objet à construire) et les commandes qui doivent être exécutées pour créer (en anglais, make) la cible (&cad; pour la compiler ou l'associer à d'autres fichiers objets pour construire un fichier de programme exécutable). Avant tout, la commande make lit les règles l'une après l'autre, vérifie chaque fichier dans la liste des dépendances d'une cible donnée et crée cette cible à nouveau si l'un quelconque de ces fichiers a changé, à l'aide des commandes répertoriées dans cette règle. Il y a plusieurs autres possibilités de contrôler un processus « make » de ce type, et un Makefile peut ainsi prendre de l'ampleur, jusqu'à devenir très complexe. Nous ne pouvons pas entrer dans les détails ici. Cependant, nous vous recommandons de vous habituer à la syntaxe de make. Même si vous ne l'utilisez en principe pas directement, une compréhension des fondamentaux du système de construction a son utilité. Reportez-vous au « GNU Make Manual » pour plus d'informations. Pour plus de détails spécifiques à &tdevelop;, consultez le chapitre Construction et gestion de projets de ce manuel. Il y a plusieurs tutoriels disponibles : reportez-vous aux références dans le chapitre Construction et gestion de projets. interface graphique utilisateur interface graphique utilisateur interface utilisateur interface graphique utilisateur Les développeurs d'applications sont encore plus gênés d'avoir non seulement à créer des bibliothèques et une logique de programme, mais aussi de fournir une interface utilisateur sur mesure facile à utiliser, qui soit à la fois intutive et fonctionnelle. La plupart des programmeurs reçoivent peu, voire aucune formation concernant le développement d'interfaces graphiques et, par voie de conséquence, les interfaces utilisateur sont souvent mal conçues. Au fil des ans, certains principes de conception communs ont évolué. Il est vivement conseillé d'y adhérer. Ainsi, vos interfaces utilisateur conserveront une apparence (un look and feel) que les utilisateurs de votre application apprécieront énormément. Un guide de style est disponible pour le développement d'interfaces graphiques &kde;. Vous le trouverez dans les &kde; User Interface Guidelines, sur la page Developer's Corner de &kde;. Vous trouverez une courte introduction aux principes communs de conception des interfaces graphiques ici. EDI environnement de développement intégré développement EDI environnement EDI Il existe des outils séparés disponibles pour pratiquement toutes les étapes du processus de programmation — planification, édition, gestion des fichiers et processus de compilation, débogage, et autre documentation. Cependant, dès lors que les projets se développent, les processus de programmation deviennent presque à coup sûr entrêmement volumineux. La conception, la compilation et le débogage d'un programme nécessite beaucoup de travail répétitif. Une grande partie de ce travail peut être enregistrée à l'aide de modèles et de scripts. En outre, une autre partie non négligeable peut l'être en gardant ces outils facilement disponibles et capables de communiquer l'un avec l'autre sous une interface graphique utilisateur commune. Par exemple — ne serait-ce pas pratique si un débogeur était capable d'ouvrir le fichier source en question dans un éditeur et de placer le curseur directement à la position du bogue que vous venez de découvrir ? Pour y parvenir plus aisément, on a mis au point les environnements de développement intégrés (en anglais &IDE;s, Integrated Development Environments). Un &EDI; de ce type intègre dans un seul environnement tous les modèles, outils et scripts qui sont généralement nécessaires lors du processus de développement. &tdevelop; est un EDI de ce type pour la plate-forme &kde;. Il fournit une large palette d'outils qui facilitent le développement et la maintenance des programmes, même pour des langages de programmation différents et des plates-formes diverses. &tdevelop; fonctionnalités fonctionnalités Gère tous les outils de développement requis pour la programmation en C++, comm un compilateur, un éditeur de liens, un débogueur et un système de compilation. Fournit un assistant d'applications qui génère des exemples d'applications complets, prêts à fonctionner. Permet à l'utilisateur de choisir un éditeur intégré basé sur l'éditeur &kwrite; du programmeur &kde;, QEditor de Trolltech, ou autres. Un générateur de classes, pour créer de nouvelles classes et les intégrer dans le projet en cours. Une gestion de fichiers pour les sources, les en-têtes, la documentation &etc; à inclure au projet. Une assistance lors de la création de manuels utilisateur des applications écrits avec les outils &kde;. Une documentation de l'&API; automatique en &HTML; des classes d'un projet avec des références croisées aux bibliothèques utilisées. Une prise en charge de l'internationalisation, permettant aux traducteurs d'ajouter aisément leur langue cible à un projet, y compris la prise en charge de &kbabel;. Un support pour la gestion d'un projet via un ou plusieurs systèmes de suivi de versions (&pex;, &CVS;) en proposant une interface facile à utiliser pour la plupart des fonctions nécessaires. Une interface de débogage intégrée. Un émulateur de console de shell intégré. Une coloration syntaxique dans les textes sources. Une capacité d'auto-complétement du code des variables de classes, des méthodes de classes, des arguments de fonctions, &etc;. Des modèles pour créer divers projets (modules &kcontrol;, applets de &kicker; (tableau de bord), KIOSlaves, modules externes (plugins) de &konqueror; et styles du bureau). Quatre vues arborescentes de l'affichage pour naviguer aisément entre les fichiers sources, les fichiers d'en-tête et la documentation, évitant la nécessité d'un gestionnaire de fichiers externe. Une prise en charge de la compilation croisée, avec la possibilité de spécifier différents compilateurs, drapeaux de compilateurs, architectures cibles, &etc; Une prise en charge des projets Qt/Embedded (tels que le Zaurus et l'iPAQ). Une inclusion de tout autre programme dont vous avez besoin pour le développement, en l'ajoutant au menu Outils en fonction de vos besoins individuels.