|
|
<appendix id="unixdev">
|
|
|
|
|
|
<appendixinfo>
|
|
|
<authorgroup>
|
|
|
<author><firstname>Bernd</firstname><surname>Pol</surname></author>
|
|
|
<!-- ROLES_OF_TRANSLATORS -->
|
|
|
</authorgroup>
|
|
|
</appendixinfo>
|
|
|
|
|
|
<title>Développement sous &UNIX;</title>
|
|
|
|
|
|
<indexterm zone="unixdev"><primary>développement</primary></indexterm>
|
|
|
<indexterm zone="unixdev">
|
|
|
<primary>&UNIX;</primary>
|
|
|
<secondary>développement</secondary></indexterm>
|
|
|
|
|
|
<sect1 id="history">
|
|
|
<title>Quelques remarques d'ordre historique</title>
|
|
|
|
|
|
<indexterm zone="history"><primary>historique</primary></indexterm>
|
|
|
<indexterm zone="history"><primary>langages de scriptage</primary></indexterm>
|
|
|
<indexterm zone="history">
|
|
|
<primary>&UNIX;</primary>
|
|
|
<secondary>historique</secondary></indexterm>
|
|
|
<indexterm zone="history">
|
|
|
<primary>&UNIX;</primary>
|
|
|
<secondary>tube</secondary></indexterm>
|
|
|
<indexterm zone="history">
|
|
|
<primary>&UNIX;</primary>
|
|
|
<secondary>shell</secondary></indexterm>
|
|
|
<indexterm zone="history">
|
|
|
<primary>shell</primary>
|
|
|
<secondary>&UNIX;</secondary></indexterm>
|
|
|
|
|
|
<para>Dès le début, &UNIX; a maintenu deux paradigmes de développement très différents. L'un est le monde des <emphasis>langages de programmation de systèmes et d'applications</emphasis>, dans lequel du code source est traduit en code machine par un programme de traduction, le plus souvent un <emphasis>compilateur</emphasis> ou un <emphasis>interpréteur</emphasis>. 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.) </para>
|
|
|
<para>L'autre paradigme est le monde des <emphasis>langages de scriptage</emphasis>. 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; <command>grep</command>, <command>sed</command> ou <command>find</command>. 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 <emphasis>via</emphasis> un mécanisme de transport simple, appelé <emphasis>tube</emphasis>, 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. </para>
|
|
|
<para>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. </para>
|
|
|
</sect1> <!-- history -->
|
|
|
|
|
|
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
|
|
|
|
|
|
<sect1 id="unixdev-scripting-languages">
|
|
|
<title>Langages de scriptage contemporains</title>
|
|
|
<para>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 <emphasis>via</emphasis> des tubes en cas de nécessité. </para>
|
|
|
<para>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. </para>
|
|
|
|
|
|
<sect2 id="unixdev-SL-Perl">
|
|
|
<title>&perl;</title>
|
|
|
|
|
|
<indexterm zone="unixdev-SL-Perl"><primary>Perl</primary></indexterm>
|
|
|
<indexterm zone="unixdev-SL-Perl">
|
|
|
<primary>langages de scriptage</primary>
|
|
|
<secondary>Perl</secondary></indexterm>
|
|
|
|
|
|
<para><ulink url="http://www.perl.com">&perl;</ulink> 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 <command>mod_perl</command> 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. </para>
|
|
|
<para>Pour plus d'informations, visitez le site web <ulink url="http://cpan.org"> Comprehensive Perl Archive Network (CPAN)</ulink>. </para>
|
|
|
</sect2> <!-- unixdev-SL-Perl -->
|
|
|
|
|
|
<sect2 id="unixdev-SL-Python">
|
|
|
<title>Python</title>
|
|
|
|
|
|
<indexterm zone="unixdev-SL-Python"><primary>Python</primary></indexterm>
|
|
|
<indexterm zone="unixdev-SL-Python">
|
|
|
<primary>langages de scriptage</primary>
|
|
|
<secondary>Python</secondary></indexterm>
|
|
|
|
|
|
<para><ulink url="http://www.python.org">&python;</ulink> 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. </para>
|
|
|
</sect2> <!-- unixdev-SL-Python -->
|
|
|
|
|
|
<sect2 id="unixdev-SL-PHP">
|
|
|
<title>PHP</title>
|
|
|
|
|
|
<indexterm zone="unixdev-SL-PHP"><primary>PHP</primary></indexterm>
|
|
|
<indexterm zone="unixdev-SL-PHP">
|
|
|
<primary>langages de scriptage</primary>
|
|
|
<secondary>PHP</secondary></indexterm>
|
|
|
|
|
|
<para><ulink url="http://www.php.net">&php;</ulink> 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. </para>
|
|
|
</sect2> <!-- unixdev-SL-PHP -->
|
|
|
</sect1> <!-- unixdev-scripting-languages -->
|
|
|
|
|
|
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
|
|
|
<sect1 id="unixdev-hl-script">
|
|
|
<title>Scriptage de niveau plus élevé</title>
|
|
|
|
|
|
<para>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;. </para>
|
|
|
<para>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 <link linkend="unixdev-corba">CORBA</link> et, dans l'environnement &kde;, <link linkend="unixdev-dcop">&DCOP;</link>. </para>
|
|
|
|
|
|
<sect2 id="unixdev-corba">
|
|
|
<title>Le protocole CORBA</title>
|
|
|
|
|
|
<indexterm zone="unixdev-corba"><primary>CORBA</primary></indexterm>
|
|
|
<indexterm zone="unixdev-corba">
|
|
|
<primary>langages de scriptage</primary>
|
|
|
<secondary>CORBA</secondary></indexterm>
|
|
|
<indexterm zone="unixdev-corba">
|
|
|
<primary>communication</primary>
|
|
|
<secondary>CORBA</secondary></indexterm>
|
|
|
|
|
|
<para><ulink url="http://www.omg.org/gettingstarted/corbafaq.htm">CORBA</ulink> (<emphasis>Common Object Request Broker Architecture</emphasis>) est une tentative pour faire interagir des applications informatiques sur des réseaux. Il a été élaboré par le comité de standardisation <ulink url="http://www.omg.org">OMG</ulink> (Object Management Group) composé de fabricants privés, indépendants. </para>
|
|
|
<para>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. </para>
|
|
|
<para>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. </para>
|
|
|
|
|
|
</sect2> <!-- unixdev-corba -->
|
|
|
|
|
|
<sect2 id="unixdev-dcop">
|
|
|
<title>L'interface &DCOP;</title>
|
|
|
|
|
|
<indexterm zone="unixdev-dcop"><primary>DCOP</primary></indexterm>
|
|
|
<indexterm zone="unixdev-dcop">
|
|
|
<primary>langages de scriptage</primary>
|
|
|
<secondary>DCOP</secondary></indexterm>
|
|
|
<indexterm zone="unixdev-dcop">
|
|
|
<primary>communication</primary>
|
|
|
<secondary>DCOP</secondary></indexterm>
|
|
|
|
|
|
<para>Une autre évolution sur le scriptage de type &UNIX; est le protocole <ulink url="http://developer.kde.org/documentation/library/kdetqt/dcop.html"><emphasis>DCOP</emphasis></ulink> mis au point pour la communication entre les applications &kde; pour venir à bout des limitations de CORBA. </para>
|
|
|
<para>DCOP signifie <emphasis>Desktop Communication Protocol</emphasis> 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;. </para>
|
|
|
<para>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. </para>
|
|
|
<para>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. </para>
|
|
|
<para>Pour plus d'informations, lisez l'article <ulink url="http://developer.kde.org/documentation/library/kdetqt/dcop.html">DCOP: Desktop COmmunications Protocol</ulink> ou la référence à l'&API; <ulink url="http://developer.kde.org/documentation/library/cvs-api/dcop/html/index.html">The &DCOP; Desktop Communication Protocol library</ulink> de la bibliothèque dcop de &kde;. </para>
|
|
|
</sect2> <!-- unixdev-dcop -->
|
|
|
|
|
|
</sect1> <!-- unixdev-hl-script -->
|
|
|
|
|
|
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
|
|
|
|
|
|
<sect1 id="unixdev-buildsystems">
|
|
|
<title>Systèmes de construction</title>
|
|
|
|
|
|
<para>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. </para>
|
|
|
<para>Pour ce faire, les outils de base nécessaires sont <itemizedlist>
|
|
|
<listitem><para>un <emphasis>éditeur de texte</emphasis> pour écrire les fichiers de code source, </para></listitem>
|
|
|
<listitem><para>un programme de traduction, habituellement un <emphasis>compilateur</emphasis> pour transformer le code source en fichiers objets, </para></listitem>
|
|
|
<listitem><para>un <emphasis>gestionnaire de bibliothèques</emphasis> qui collecte des fichiers objets dans les bibliothèques pour les réutiliser aisément sans qu'il soit nécessaire de recompiler, </para></listitem>
|
|
|
<listitem><para>un <emphasis>éditeur de liens</emphasis> qui associe plusieurs fichiers objets et les bibliothèques en un exécutable, </para></listitem>
|
|
|
<listitem><para>un <emphasis>système make</emphasis> qui fournit un moyen de gérer tous ces éléments et — sans oublier </para></listitem>
|
|
|
<listitem><para>un <emphasis>débogueur</emphasis> 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. </para></listitem>
|
|
|
</itemizedlist>
|
|
|
</para>
|
|
|
|
|
|
<para>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. </para>
|
|
|
<para>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. </para>
|
|
|
|
|
|
<sect2 id="unixdev-buildsystems-make">
|
|
|
<title>Le processus make</title>
|
|
|
|
|
|
<indexterm zone="unixdev-buildsystems-make">
|
|
|
<primary>make</primary></indexterm>
|
|
|
<indexterm zone="unixdev-buildsystems-make">
|
|
|
<primary>Makefile</primary></indexterm>
|
|
|
<indexterm zone="unixdev-buildsystems-make">
|
|
|
<primary>règle</primary></indexterm>
|
|
|
<indexterm zone="unixdev-buildsystems-make">
|
|
|
<primary>recompilations</primary></indexterm>
|
|
|
<indexterm zone="unixdev-buildsystems-make">
|
|
|
<primary>cible</primary></indexterm>
|
|
|
<indexterm zone="unixdev-buildsystems-make">
|
|
|
<primary>dépendances</primary></indexterm>
|
|
|
<indexterm zone="unixdev-buildsystems-make">
|
|
|
<primary>commandes</primary></indexterm>
|
|
|
|
|
|
<para>Un outil qui se charge des recompilations est <command>make</command>. Il garde la trace de l'ensemble du travail grâce à un ensemble de <emphasis>règles</emphasis> 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 un<filename>Makefile</filename>, qui est traité par <command>make</command> chaque fois que vous souhaitez mettre à jour votre travail. </para>
|
|
|
<para>Chaque règle se compose de plusieurs blocs de construction, à savoir <itemizedlist>
|
|
|
<listitem><para>une <emphasis>cible</emphasis>, &cad; le fichier à construire </para></listitem>
|
|
|
<listitem><para>un ensemble de <emphasis>dépendances</emphasis>, 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 </para></listitem>
|
|
|
<listitem><para>les <emphasis>commandes</emphasis> qui doivent être exécutées pour <quote>créer</quote> (en anglais, <emphasis>make</emphasis>) la cible (&cad; pour la compiler ou l'associer à d'autres fichiers objets pour construire un fichier de programme exécutable). </para></listitem>
|
|
|
</itemizedlist>
|
|
|
</para>
|
|
|
<para>Avant tout, la commande <command>make</command> 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. </para>
|
|
|
<para>Il y a plusieurs autres possibilités de contrôler un processus « make » de ce type, et un <filename>Makefile</filename> 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 <command>make</command>. 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 <ulink url="info://make/Top"> « GNU Make Manual »</ulink> pour plus d'informations. </para>
|
|
|
<para>Pour plus de détails spécifiques à &tdevelop;, consultez le chapitre <link linkend="project-management">Construction et gestion de projets</link> de ce manuel. </para>
|
|
|
<para>Il y a plusieurs tutoriels disponibles : reportez-vous aux <link linkend="automake-references">références</link> dans le chapitre Construction et gestion de projets. </para>
|
|
|
</sect2> <!-- unixdev-buildsystems-make -->
|
|
|
|
|
|
</sect1> <!-- unixdev-buildsystems -->
|
|
|
|
|
|
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
|
|
|
|
|
|
<sect1 id="unixdev-guidevelopment">
|
|
|
<title>Développement d'interfaces graphiques</title>
|
|
|
|
|
|
<indexterm zone="unixdev-guidevelopment">
|
|
|
<primary>interface graphique utilisateur</primary></indexterm>
|
|
|
<indexterm zone="unixdev-guidevelopment">
|
|
|
<primary>interface graphique utilisateur</primary></indexterm>
|
|
|
<indexterm zone="unixdev-guidevelopment">
|
|
|
<primary>interface utilisateur</primary>
|
|
|
<secondary>interface graphique utilisateur</secondary></indexterm>
|
|
|
|
|
|
<para>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. </para>
|
|
|
<para>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 <emphasis>look and feel</emphasis>) que les utilisateurs de votre application apprécieront énormément. </para>
|
|
|
<para>Un guide de style est disponible pour le développement d'interfaces graphiques &kde;. Vous le trouverez dans les <ulink url="http://developer.kde.org/documentation/standards/kde/style/basics/index.html">&kde; User Interface Guidelines</ulink>, sur la page Developer's Corner de &kde;. </para>
|
|
|
<para>Vous trouverez une courte introduction aux principes communs de conception des interfaces graphiques <ulink url="http://axp16.iie.org.mx/Monitor/v01n03/ar_ihc2.htm">ici</ulink>. </para>
|
|
|
|
|
|
</sect1> <!-- unixdev-guidevelopment -->
|
|
|
|
|
|
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -->
|
|
|
|
|
|
<sect1 id="unixdev-ide">
|
|
|
<title>Intégration de concepts et d'outils — l'EDI</title>
|
|
|
|
|
|
<indexterm zone="unixdev-ide">
|
|
|
<primary>EDI</primary></indexterm>
|
|
|
<indexterm zone="unixdev-ide">
|
|
|
<primary>environnement de développement intégré</primary></indexterm>
|
|
|
<indexterm zone="unixdev-ide">
|
|
|
<primary>développement</primary>
|
|
|
<secondary>EDI</secondary></indexterm>
|
|
|
<indexterm zone="unixdev-ide">
|
|
|
<primary>environnement</primary>
|
|
|
<secondary>EDI</secondary></indexterm>
|
|
|
|
|
|
<para>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. </para>
|
|
|
<para>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. </para>
|
|
|
<para>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 ? </para>
|
|
|
<para>Pour y parvenir plus aisément, on a mis au point les environnements de développement intégrés (en anglais &IDE;s, <emphasis>Integrated Development Environments</emphasis>). 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. </para>
|
|
|
<para>&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. </para>
|
|
|
|
|
|
<sect2 id="unixdev-ide-tdevelop">
|
|
|
<title>Fonctionnalités de base de la &kdevrelease; de &tdevelop;</title>
|
|
|
|
|
|
<indexterm zone="unixdev-ide-tdevelop">
|
|
|
<primary>&tdevelop;</primary>
|
|
|
<secondary>fonctionnalités</secondary></indexterm>
|
|
|
<indexterm zone="unixdev-ide-tdevelop">
|
|
|
<primary>fonctionnalités</primary></indexterm>
|
|
|
|
|
|
<!-- ### copied from web page, needs to be updated -->
|
|
|
|
|
|
<itemizedlist>
|
|
|
<listitem>
|
|
|
<para>Gère tous les <emphasis>outils de développement</emphasis> requis pour la programmation en C++, comm un compilateur, un éditeur de liens, un débogueur et un système de compilation.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Fournit un <emphasis>assistant d'applications</emphasis> qui génère des exemples d'applications complets, prêts à fonctionner.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Permet à l'utilisateur de choisir un <emphasis>éditeur intégré</emphasis> basé sur l'éditeur &kwrite; du programmeur &kde;, <application>QEditor</application> de Trolltech, ou autres.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Un <emphasis>générateur de classes</emphasis>, pour créer de nouvelles classes et les intégrer dans le projet en cours.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Une <emphasis>gestion de fichiers</emphasis> pour les sources, les en-têtes, la documentation &etc; à inclure au projet.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Une assistance lors de la <emphasis>création de manuels utilisateur des applications</emphasis> écrits avec les outils &kde;.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Une <emphasis>documentation de l'&API;</emphasis> automatique en &HTML; des classes d'un projet avec des références croisées aux bibliothèques utilisées.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Une <emphasis>prise en charge de l'internationalisation</emphasis>, permettant aux traducteurs d'ajouter aisément leur langue cible à un projet, y compris la prise en charge de &kbabel;.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Un support pour la gestion d'un projet <emphasis>via</emphasis> un ou plusieurs <emphasis>systèmes de suivi de versions</emphasis> (&pex;, &CVS;) en proposant une interface facile à utiliser pour la plupart des fonctions nécessaires.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Une interface de <emphasis>débogage</emphasis> intégrée.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Un émulateur de <emphasis>console de shell</emphasis> intégré.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Une <emphasis>coloration syntaxique</emphasis> dans les textes sources.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Une capacité d'<emphasis>auto-complétement du code</emphasis> des variables de classes, des méthodes de classes, des arguments de fonctions, &etc;.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Des <emphasis>modèles pour créer divers projets</emphasis> (modules &kcontrol;, applets de &kicker; (tableau de bord), KIOSlaves, modules externes (<emphasis>plugins</emphasis>) de &konqueror; et styles du bureau).</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Quatre <emphasis>vues arborescentes de l'affichage</emphasis> 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.</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Une <emphasis>prise en charge de la compilation croisée</emphasis>, avec la possibilité de spécifier différents compilateurs, drapeaux de compilateurs, architectures cibles, &etc;</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Une prise en charge des <emphasis>projets Qt/Embedded</emphasis> (tels que le Zaurus et l'iPAQ).</para>
|
|
|
</listitem>
|
|
|
<listitem>
|
|
|
<para>Une <emphasis>inclusion de tout autre programme</emphasis> dont vous avez besoin pour le développement, en l'ajoutant au menu <guimenuitem>Outils</guimenuitem> en fonction de vos besoins individuels.</para>
|
|
|
</listitem>
|
|
|
</itemizedlist>
|
|
|
|
|
|
</sect2> <!-- unixdev-ide-tdevelop -->
|
|
|
|
|
|
</sect1> <!-- unixdev-ide -->
|
|
|
|
|
|
</appendix> <!-- unixdev -->
|
|
|
|
