Et Borland créa Kylix...

AVERTISSEMENT

La version de Kylix utilisée pour cet article est une version Béta. Toutes les opérations décrites ici sont suceptibles d'être modifiées dans la version finale.

Il y a des jours où le préposé des postes est attendu comme le messie. Ca fait déjà un an que j'attends ce moment. Enfin, elle est là, cette petite galette de plastique. Cela fait déjà plusieurs mois que j'attends son arrivée. Depuis, je me suis familiarisé avec Linux. J'ai installé plusieurs distributions, je me suis battu avec les fichiers de configuration, j'ai acheté quelques bouquins, beaucoup lu sur Internet ou ailleurs.

L'apprentissage fut dur au début, mais globalement, et contrairement aux idées reçues, je dirais que Linux n'est pas plus compliqué à apprendre que Windows. Il faut faire l'effort, c'est sur, mais la découverte d'un nouveau système est très exitant. Surtout avec Linux, car il fourmille de diversité. On est si loin de l'uniformité de Windows !

Après avoir essayé plusieurs distributions, j'ai adopté la Mandrake. Elle s'installe facilement et les outils fournis par MandrakeSoft sont très utiles, en particulier DiskDrake qui permet de partitionner les disques.

J'allume donc mon ordinateur. Lilo, le LInux LOader affiche les différents systèmes installés sur ma machine. Pas besoin d'abandonner Windows pour essayer Linux. Ce dernier fournit tous les outils pour une cohabitation pacifique.

Après une courte phase de démarrage en mode texte, le bureau de KDE apparait. KDE est une des interfaces graphiques disponibles sous Linux. Elle est basée sur QT, le ToolKit sur lequel repose également CLX, la nouvelle bibliothéque de composant de Kylix. Les utilisateurs de Windows se retrouvent ici dans un monde connu. Il y a une barre des taches, un menu K qui se subtitue au menu Démarrer.

J'introduit dans mon lecteur le CD-Rom. Je clique sur l'icône correspondante du bureau KDE. Kfm (K File Manager), l'équivalent de l'explorateur de Windows se lance. Ce dernier affiche alors le répertoire /mnt/cdrom. Sous Linux, l'arborescense des fichiers est légérement différente de celle de Windows. Il n'y a pas plusieurs lecteurs logiques repérés par des lettres (C:, A:). En fait, le système de fichier peut être représenté comme un arbre où la racine (root en Anglais) se nomme /. L'accès au CD-Rom se fait par le chemin /mnt/cdrom. Comme vous pouvez le constater, Linux utilise le / comme séparateur dans les chemins, et non pas le \ comme dans Windows et DOS. Dans le répertoire mnt (pour Mount, Monter en Français), on trouve tous les périphériques de stockage amovibles comme la disquette ou le CD-Rom.

Dans le CD se trouve un fichier README sans extension. Sous Unix, et donc sous Linux qui s'en inspire, on donne rarement des extensions aux noms de fichiers . Pour reconnaitre le type d'un fichier, on utilise un utilitaire nommé "file". Par l'analyse du fichier, de son entête lorsqu'il en dispose, on peut déterminer son format.

D'un clic sur ce fichier, je l'ouvre dans le visualisateur intégré de Kfm. J'apprends alors qu'il faut mettre à jour une des bibliothèques les plus importantes de Linux, la Glibc. Le G indique que cette bibliothèque est un outil G.N.U. (Gnu is Not Unix). Le G.N.U est un organisme chargé de promouvoir la création de logiciels libres. Il est à l'origine de nombreux programmes, qui avec le noyau développé initialement par Linus Torvalds forme le coeur de Linux.

Un peu plus loin dans ce fichier, j'apprends que des versions spéciales de cette Glibc sont disponible pour ma Mandrake 7.2. Je me rends alors dans le répertoire patches du CD. J'y trouve plusieurs fichiers au format RPM (Red hat Package Manager). Sous Linux, l'installation et la désinstallation des logiciels reposent sur la notion de package. L'utilitaire RPM, développé par la société Red Hat, gére les dépendances, c'est à dire qu'il vérifie si tous les fichiers nécessaires au bon fonctionnement du programme sont présent sur le disque. Il met à jour une base de données, qu'on peut consulter pour savoir quels sont les programmes installés.

Sous KDE, il existe une version graphique de rpm, nommée KPackage. J'ouvre donc chaque fichier, puis les installe d'un simple clic.

Le moment est venu d'installer Kylix. le fichier README précise qu'il faut lancer un script nommé setup.sh. J'ouvre alors un terminal (l'équivalent d'une fenêtre DOS sous Windows), pour visualiser les éventuels messages émis par ce dernier. Je tape ./setup.sh à l'invite du prompt (indiqué par un signe $, au lieu du > du DOS). Remarquez le point qui précéde le / dans ma commande. Sous Linux, lorsqu'on tape une commande, ce dernier ne recherche par l'exécutable dans le répertoire courant. Il faut lui indiquer explicitement son emplacement. Le point indique le répertoire courant (comme sous DOS d'ailleurs).

Après avoir vérifié la version de mon kernel et de différentes librairies, une fenêtre graphique s'affiche. Elle semble avoir été écrite avec le ToolKit Gtk (un concurrent de Qt). Je dis bien elle semble, car sous Linux existe la notion de thèmes, un peu comme les skins qu'on voit apparaitre sous Windows, qui permettent de modifier l'apparence d'une application. Après avoir survolé l'accord de license, je clique sur "I agree" (pour l'instant la version Française n'existe pas encore). Une deuxième fenêtre apparait, avec une série d'options. La première d'entre elle permet de préciser le répertoire d'installation. Le chemin proposé par défaut m'intrigue un peu. On me propose de copier les fichiers dans le répertoire /root/kylix. Le répertoire root est le répertoire personnel de l'administateur du système. Linux est un système sécurisé, qui gére les notions d'utilisateurs. L'utilisateur root est le seul a avoir les pleins pouvoirs. Les autres utilisateurs ne peuvent accéder qu'aux fichiers pour lesquels ils ont des autorisations. Par exemple, si j'ai un utilisateur nommé Marc, il ne pourra pas accéder aux fichiers de l'utilisateur Sophie (et réciproquement). Le répertoire root, n'est donc accessible qu'à l'utilisateur root. Sur mon ordinateur, je me connecte sous le login root pour installer des logiciels ou modifier la configuration. Pour une session de travail normale, je me connecte sous un autre nom d'utilisateur. Le système est ainsi protégé des mauvaises manipulations, des virus et autres chevaux de Troie (peu de virus existe sous Linux, mais on ne sait jamais...). Le fait d'installer kylix dans /root me forcera à travailler en tant que root. Ca me géne un peu, mais bon comme le programme est encore en version Béta, je ne vais pas tenter le diable, et je conserve donc le chemin proposé.

Dans le reste de la fenêtre, on peut spécifier les composants à installer. Tout est sélectionné. Finalement, le programme me propose de créer des éléments de menu dans KDE et Gnome (autre environnement graphique). Je valide mon choix en cliquant sur "Begin install".

En moins d'une minute, l'installation est terminée. Un répertoire Kylix, de 220 Mo environ est créé sur mon disque. Kylix n'apparait pas dans mon menu K, je décide donc de me déconnecter puis de me reconnecter pour qu'il se mette à jour. Ceci fait, une nouvelle ligne intitulée Borland Kylix fait son apparition.

Je m'empresse de cliquer sur Kylix. Une mystérieuse boite de dialogue apparait alors. Un énigmatique message indique "Font matrix generation". L'opération terminée, un magnifique logo apparait sur mon écran, puis... Kylix montre son vrai visage.

Et là... Rien de révolutionnaire, Kylix ressemble à... Delphi ! De la boite de dialogue d'ouverture des fichiers jusqu'au fichier d'aide, c'est une copie conforme. Les gens habitués à Delphi ne seront pas dépaysés et retrouveront immédiatement leur repère.

Immédiatement, je lance une compilation. Et ça marche ! Une fiche vide apparait. L'exécutable généré (sans extension .exe) fait environ 380 Ko.

Je décide alors d'expérimenter le fameux "Hello Word". Je place un bouton sur la fiche, et je double-clique dessus. L'éditeur de code apparait. Je tape le code suivant :

ShowMessage('Hello word !');

Je relance la compilation par un appui sur F9. Tout fonctionne. En cliquant sur le bouton, j'obtient la fenêtre suivante (fig. 1).

Figure 1 - Hello world !

Par la suite, j'ai rapidement créé un éditeur basique, en plaçant un mémo sur ma fiche et en créant un menu avec quelques commandes. Tout, absolument tout, est similaire à la version Windows.

Au niveau du code, les seules différences se situent aux niveaux des clauses uses. De nouvelles unités font leur apparition : QForms, QControls, QGraphics... La directive {$R *.dfm} est remplacée par {$R *.xfm}.

Je décide alors d'essayer d'importer un embryon de projet de la version Windows de Delphi. Linux supporte les systèmes de fichier FAT32, ce qui me permet d'accéder à ma partition Windows. Après avoir copié mes fichiers .dpr, .pas, .dfm et .res, j'ouvre mon projet dans Kylix.

Un premier message m'indique que la classe TPrintDialog n'a pas été trouvée. Je choisit d'ignorer l'avertissement. C'est alors au tour de la classe TPrintDialogSetup. J'ignore à nouveau. Et là... ma fiche principale apparait, absolument identique à sa version Windows. Je décide alors de vérifier les deux autres fiches. L'une d'entre elles, une boite de dialogue, pose problème. La propriété BorderStyle n'est pas reconnue. J'ignore une fois de plus l'avertissement, et ma boite de dialogue apparait. La police est un peu plus grande, et je dois redimensionner certains contrôles.

Je lance la compilation. L'IDE m'informe que certaines déclarations ne sont pas rattachées à un composant (les composants de type TPrintDialog et TPrintDialogSetup que j'ai choisi d'ignorer). J'accepte donc la proposition de l'IDE qui m'invite à les supprimer.

Une erreur plus sérieuse survient : Forms.dcu non trouvé. Je cherche un peu et je me rapelle alors les conseils de Borland. Je remplace Forms dans la clause uses par QForms. C'est maintenant l'unité Windows qui pose problème. Ne sachant pas par quoi la remplacer, je choisis de la commenter. Suivent Messages, Graphics, Controls...etc. Pour finir, je ne conserve que SysUtils et Classes. Au passage, je remarque que Kylix a ajouté un certain nombre d'unités à mes clauses uses, toutes commençant par Q. J'ai un problème avec un composant personnalisé que j'ai oublié de copier. Après copie dans le répertoire de mon projet, tout rentre dans l'ordre.

Certains identificateurs ne sont pas reconnus. J'appelle alors l'aide contextuelle pour connaitre l'unité dans laquelle ils sont définis, puis je les ajoute à mes clauses uses. Le copier-coller fonctionne correctement entre le navigateur d'aide et l'IDE Delphi (ce n'est pas toujours le cas sous Linux, car le presse-papier est implémenté de différentes façons sous les environnements graphiques).

Un appel à l'API Win32 InvalidateRect pose problème. Je le remplace par la méthode du même nom de la classe TCustomControl. Je suis ensuite amené à commenter certaines parties du code qui pose problème. Mon application est une application MDI et les méthodes Tile, Cascade ne sont pas encore implémentées. De même pour le code qui faisait appel à l'objet TPrintDialog.

A présent, ce sont les fichiers .dfm et res qui manquent à l'appel. Après avoir un peu "bricolé", je trouve la source de l'erreur. Les directives {$R *.DFM} et {$R *.RES} doivent être changées en {$R *.dfm} et {$R *.res}. Eh oui, Linux fait la différence entre les majuscules et les minuscules !

Finalement mon application se compile, et ça fait un drôle d'effet de la voir fonctionner sous Linux. Bien sur, tout n'est pas parfait, en particulier la gestion MDI qui n'est apparemment pas complétement implémentée. Il faut savoir que les applications MDI sont une spécificité de Windows. Sous Linux, les applications qui gérent plusieurs documents en même temps ouvrent plusieurs fenêtres (comme GIMP), ou utilisent des classeurs à onglets (comme l'EDI de Delphi, bien que celui ci soit capable des deux approches).

Et voilà, c'est tout pour aujourd'hui. Mais comme dirait Neil, c'est un petit pas pour moi, mais un bond de géant pour Linux !