Sortie de Gambas 3.3

Gambas est un langage de programmation orienté objet, basé sur un interpréteur BASIC, et une plate‐forme de développement complète. Il comporte, entre autres, un compilateur, un interpréteur, un tas de modules complémentaires (appelés composants) et un environnement de développement intégré. Le tout est distribué sous licence GNU GPL v2 ou supérieure.

Gambas 3 est sorti le 31 décembre 2011, il y a maintenant neuf mois.

Profitons donc de la sortie de Gambas 3.3 pour faire un point sur les nouvelles fonctionnalités de ce langage de programmation.

Pour plus d’informations sur Gambas, la lecture de la précédente dépêche est vivement conseillée, ainsi que la consultation du site du logiciel.

Sommaire

• Compilation à la volée (just‐in‐time)
• Profileur
• Gambas 3 tourne sur Raspberry Pi
  • ...et sur MK802
• Pages HTML dynamiques dans le style de PHP ou ASP
• Réécriture du composant XML
• Composant multimédia basé sur la bibliothèque GStreamer
• Bibliothèque scientifique GNU
• Composant POP3 et MIME basé sur la bibliothèque gmime
• Composant NCurses
• Tâches d’arrière‐plan
• Empaquetage des projets
• Environnement de développement
  • 1. Déclaration automatique des variables locales
  • 2. Amélioration de l’éditeur de formulaires
  • 3. Liste automatique de notes de commentaires
  • 4. Historique des déplacements
  • 5. Autres améliorations
• Interpréteur et compilateur
  • 1. Nouvelles instructions
  • 2. Avertissements
  • 3. Optimisation de la pile
  • 4. Optimisations UTF-8
  • 5. Support des nombres complexes
• Composants graphiques
  • 1. Prise en charge des tablettes graphiques
  • 2. Réécriture du contrôle GridView en Gambas
  • 3. Améliorations et optimisation du composant GTK+
  • 4. Gestion des thèmes d’icônes
  • 5. Autres améliorations diverses
• Conclusion
  • Coup de gueule № 1
  • Coup de gueule № 2
  • Coup de gueule № 3

Compilation à la volée (just‐in‐time)

L’évolution majeure depuis la version 3.2 est le compilateur à la volée (en anglais just in time), qui consiste à traduire le code d’une fonction en assembleur au moment de sa première exécution, et à exécuter le code assemblé à la place du code interprété.

Les meilleurs gains de performances sont obtenus dans les calculs de bas niveau et dans le déroulement du flot de contrôle. Il n’y a bien sûr aucune amélioration pour le code des composants écrits en C ou en C++.

Il y a donc tout intérêt à cibler précisément ce qui doit être compilé dans un projet, car la compilation a un coût en mémoire et en temps (la première fois que la fonction est exécutée). Par exemple, il n’y aurait aucun gain significatif à compiler intégralement l’environnement de développement.

Pour indiquer qu’une classe doit être compilée à la volée, il suffit d’ajouter le mot‐clef FAST en début de classe.
Pour ne compiler qu’une fonction, il suffit d’ajouter le mot‐clef FAST en début de déclaration de fonction.

FAST Private Sub FastDrawFractalRect(hImage As Image, XO As Float, YO As Float, SF As Float, X As Integer, Y As Integer, W As Integer, H As Integer)

  Dim I, J, K, C, CC As Integer
  Dim XF, YF, XF0, YF0, XF1, YF1 As Float

  ...

End

La compilation à la volée est ainsi utilisée par l’environnement de développement pour accélérer l’analyse du profilage (voir le paragraphe suivant).

Elle permet aussi à l’exemple Fractal de tourner quasiment en temps réel sur mon double cœur :

Voici les résultats de trois bancs d’essai écrits en Gambas, en Python et en Perl :

		┌	──────────	┬	──────────	┬	──────────	┬	────────────────	┐
		│	Python	│	Perl	│	Gambas	│	Gambas + JIT	│
┌	───────────	┼	──────────	┼	──────────	┼	──────────	┼	────────────────	┤
│	Polynom	│	133 s	│	319 s	│	100 s	│	9,20 s	│
│	Primes	│	27,6 s	│	43,0 s	│	20,4 s	│	5,95 s	│
│	N-Body	│	22,4 s	│	33,3 s	│	20,8 s	│	3,07 s	│
└	───────────	┴	──────────	┴	──────────	┴	──────────	┴	────────────────	┘

Pour plus de détails sur ces bancs d’essai, veuillez consulter le wiki de Gambas.

Ce compilateur « à la volée » a été écrit par le Suédois Emil Lenngren. Il se base sur LLVM 3.1 ou toute autre version postérieure. Il fonctionne sur les architectures i386 et x86_64, mais pas encore sur ARM à cause de bogues dans LLVM.

À ma connaissance, aucune distribution n’utilise pour l’instant LLVM 3.1, mais cela ne saurait tarder. En attendant, sur Ubuntu 12.04, il vous faudra compiler LLVM 3.1 à la main, sachant que toute utilisation combinée avec OpenGL plantera, car celui‐ci essaiera d’utiliser LLVM 3.0. Visiblement, il n’a pas été prévu de pouvoir utiliser deux versions différentes de LLVM dans le même processus. :-)

Profileur

Un profileur a été ajouté à l’environnement de développement dans la version 3.2.

Lorsque le mode « profilage » est activé, le débogueur intégré de Gambas 3 mémorise le temps d’exécution de chaque ligne de code interprétée. Une fois l’exécution terminée, le résultat du profilage est affiché dans une fenêtre similaire à ce qu’on peut trouver dans kcachegrind.

Les temps d’exécution reportés sont basés sur l’horloge réelle, et non sur le temps processeur utilisé par le processus, comme peut l’indiquer un outil comme Valgrind ou la commande time du shell.

Si quelqu’un a une solution pour pouvoir mesurer le temps processus de manière précise…

Gambas 3 tourne sur Raspberry Pi

Après de très longues heures de compilation sous l’émulateur ARM de QEMU et quelques corrections de bogues, Gambas tourne sur Raspberry Pi.

Remerciement à Wally pour la photographie ci‐dessus (NdM : l’auteur de l’article ne possède pas de Raspberry Pi).

…et sur MK802

Et, ne faisons pas de jaloux, merci à joem pour cette photographie‐là.

Pages HTML dynamiques dans le style de PHP ou ASP

Gambas possède un composant gb.web depuis la version 2. Ce composant permet de transformer un projet Gambas en script CGI. Il offre un ensemble de classes permettant de décoder une requête HTTP, de forger la réponse, et de gérer les sessions.

Depuis Gambas 3.2, la génération de pages HTML dynamiques dans le style des pages PHP ou ASP a été ajoutée.

Il s’agit de pages HTML normales au milieu desquelles on peut insérer du code Gambas, à l’aide de balises spéciales. En voici un exemple, tiré d’une capture d’écran de l’éditeur de l’environnement de développement :

Voici la signification de quelques balises :

Balise	Signification
<%…%>	Imbriquer un code Gambas quelconque.
<%=…%>	Insérer le résultat d’une expression dans le flux HTML. L’expression est correctement échappée grâce à l’instruction Html$().
<<Page>>	Inclure la WebPage Page à l’intérieur de la WebPage courante.
<%/%>	Insérer la variable CGI SCRIPT_NAME.

Ces pages dynamiques sont transformées par le compilateur en une unique méthode Render(). Cette méthode exécute le code imbriqué tel quel, et envoie la partie HTML directement vers la sortie standard.

Ce composant va continuer à évoluer afin d’offrir de plus en plus de facilités pour le développement d’applications Web en Gambas.

Un serveur HTTP embarqué est prévu pour la prochaine version, afin de faciliter le débogage de ce genre d’applications, et, pourquoi pas, permettre de réaliser un site complet autonome avec un serveur Web en un seul fichier exécutable. :-)

Réécriture du composant XML

Dans la version 3.2 de Gambas, le composant XML a fait peau neuve. Le changement le plus flagrant est sans doute la nouvelle interface DOM. L’ancienne version possédait une interface DOM très incomplète, si bien que personne ne l’utilisait, les utilisateurs devant alors se rabattre sur l’interface SAX.

À présent, le composant XML présente une nouvelle interface, se rapprochant autant de l’esprit KISS « Gambassien » que de la norme W3C.

Elle vous permet, entre autres, de naviguer et de rechercher dans votre arbre XML, au moyen des classiques relations parent‐enfants, mais aussi via des expressions régulières ou même des règles CSS. Les classes peuvent également être héritées pour vous permettre de gérer vos documents et vos nœuds à votre sauce.

Ceci dit, l’interface SAX n’est pas non plus en reste, les classes Reader et Writer ayant, elles aussi, eu droit à leurs améliorations.

La plus notable est le remaniement de l’algorithme interne d’analyse syntaxique, permettant de travailler sur des documents XML incomplets, et donc sur n’importe quel flux Gambas contenant du XML (qui peut être un fichier, une connexion réseau TCP, une sortie de processus, un périphérique externe…), en entrée comme en sortie.

En outre, si vous utilisez l’interface de lecture SAX, vous pouvez désormais stocker les nœuds lus en mémoire pour y accéder plus tard via l’interface DOM.

Outre ces changements importants, un sous‐composant HTML a également fait son apparition, ré‐implémentant (ou surchargeant) les classes DOM XML afin de vous permettre de générer plus aisément vos documents XHTML/HTML5 (gestion des feuilles de style et scripts, des méta‐données…), et peut‐être dans le futur des éléments HTML complets, tels que les tableaux, les listes, les formulaires…

Composant multimédia basé sur la bibliothèque GStreamer

gb.media est un nouveau composant apparu dans la version 3.2. Il offre une interface simplifiée à la bibliothèque GStreamer.

GStreamer permet de construire un graphe d’éléments permettant de jouer n’importe quelle donnée multimédia gérée par ses greffons, et plein d’autres choses encore…

Le composant Gambas s’inspire fortement de ce qui précède. Il permet :

• de créer et de relier entre eux tout type d’élément GStreamer ;
• de regrouper un ensemble d’éléments dans un élément conteneur unique ;
• de créer un élément « lecteur multimédia » simplement par une classe dédiée offrant accès aux réglages audio, vidéo, aux sous‐titres et aux greffons de visualisation, etc. ;
• de récupérer les tags associés aux données multimédia en temps réel.

J’ai créé un lecteur multimédia (appelé de manière originale MediaPlayer) comme exemple d’utilisation de ce composant :

GStreamer a l’air assez sensible : la manipulation du graphe d’éléments pendant la lecture d’un fichier peut provoquer un plantage de l’application. Mais peut‐être les choses s’amélioreront‐elles lors du passage à GStreamer 1.0 ?

Bibliothèque scientifique GNU

La bibliothèque scientifique GNU offre toute une panoplie de fonctions permettant d’effectuer des calculs mathématiques.
Attention : cette bibliothèque ne permet pas de faire de calcul symbolique !

Comme la GSL est un gros monstre, seule une petite partie en a pour l’instant été implémentée dans le composant gb.gsl : il s’agit de la gestion des nombres complexes, des vecteurs, des polynômes et des matrices.

Ces quatre objets mathématiques sont intégrés au langage autant que possible :

• la conversion entre tableaux, vecteurs, polynômes et matrices est implicite ;
• les cœfficients des vecteurs, des polynômes et des matrices peuvent être indifféremment des nombres réels (Float) ou des nombres complexes. La conversion entre les différents types de données gsl sous‐jacents est transparente ;
• l’interpréteur a été modifié pour que les opérateurs arithmétiques standard puissent être utilisés sur les objets mathématiques ;
• la conversion d’un objet mathématique en chaîne de caractères génère une chaîne lisible ou bien une expression Gambas pouvant être utilisée par Eval() ;
• le compilateur a été modifié pour pouvoir saisir des nombres complexes sous la forme d’un nombre réel suivi de la lettre i. Le nombre i (i² = -1) doit être écrit 1i pour éviter de le confondre avec une variable de même nom.

Voici un petit exemple :

L’exécution de la fonction précédente donne :

P = 2x^3+x^2+2x+1
P(i+1) = -1+8i
P(x) = 0 => x = -0,5
V = [1 i]
iV = [i -1]
A = [[i 0][1 i]]
A(V) = [i 0]
A^2 =[[-1 0][2i -1]]

La bibliothèque GSL dispose de nombreuses autres fonctionnalités : permutations, calcul de valeurs propres, nombres aléatoires, fonctions statistiques, équations différentielles, interpolation, etc. Elles seront implémentées au fur et à mesure en fonction des besoins.

Composant POP3 et MIME basé sur la bibliothèque gmime

Deux nouveaux composants, gb.net.pop3 et gb.mime permettent de récupérer ses courriels depuis un serveur POP3.

gb.net.pop3 implémente la communication réseau et le protocole POP3 côté client, tandis que gb.mime décode la structure MIME d’un message et de ses pièces jointes.

Le client POP3 peut communiquer en clair ou bien par SSL en se basant sur le programme openssl.

gb.mime permet aussi de construire des messages MIME. Ceci sera utilisé par le composant gb.net.smtp dans une prochaine version de Gambas.

Composant NCurses

Le composant gb.ncurses introduit dans la version 3.3 est une interface à la bibliothèque ncurses. Il a été développé par Tobias Boege.

Ce composant est dans un état expérimental, mais il permet déjà de jouer à Pong !

Le but de Tobias est qu’à terme ce composant devienne similaire aux composants graphiques, en offrant un jeu de contrôles permettant de développer des interfaces complètes.

Tâches d’arrière‐plan

L’interpréteur Gambas n’est pas « multi‐threadé », car les ordinateurs sont des machines à états et les threads sont pour les gens qui ne savent pas programmer les machines à états.

Néanmoins, il y avait le besoin de pouvoir lancer des tâches d’arrière‐plan sans interrompre l’interface du programme principal. C’est ce qu’offre la nouvelle classe Task apparue dans la version 3.3.

Une tâche d’arrière‐plan est une classe héritant de Task et dont le code est implémenté dans une fonction publique Main. Elle est exécutée par un fork de l’interpréteur, et communique avec le programme principal par l’intermédiaire de ses sorties standard.

Empaquetage des projets

L’empaquetage des projets est maintenant beaucoup plus fiable depuis la version 3.3.

Les paquets générés ont des dépendances envers les paquets binaires Gambas de la distribution cible, et c’est là que commencent les problèmes !

En effet, beaucoup de distributions sont incapables d’empaqueter correctement Gambas en dépit des instructions disponibles sur le wiki.

En particulier pour OpenSUSE, Debian et Ubuntu. Il est impératif de ne pas utiliser les paquets officiels, et d’utiliser à la place les paquets réalisés par des utilisateurs de Gambas bienveillants.

Pour tenter de contourner ce problème, Sebastian Kulesz est en train de réaliser une sorte de make spécifique à Gambas qui permettra d’installer un programme écrit en Gambas n’importe où en lançant cette commande directement depuis une archive des sources.

Environnement de développement

Voici les améliorations principales de l’environnement de développement.

1. Déclaration automatique des variables locales

Lors de la frappe de la touche ENTRÉE, l’éditeur détecte l’affectation à une variable non déclarée. Dans ce cas, le type de l’expression affectée est calculé, puis utilisé pour ajouter automatiquement la déclaration de variable adéquate en début de fonction.

L’analyseur de type d’expression a encore quelques petits défauts. Par exemple, il ne prend pas en compte la structure WITH … END WITH.

2. Amélioration de l’éditeur de formulaires

Toute modification d’un formulaire (création de contrôle, destruction de contrôle, déplacement, changement de taille, modification d’une propriété) est maintenant annulable.

Le contrôle situé en‐dessous de la souris est maintenant mis en évidence par un cadre semi‐transparent. Ceci facilite les manipulations des contrôles qui n’ont pas de bordure.

Les contrôles peuvent être marqués individuellement comme non traduisibles. Ceci s’applique aux propriétés de texte.

3. Liste automatique de notes de commentaires

Les commentaires commençant par un des mots‐clefs TODO:, FIXME: ou NOTE: sont automatiquement répertoriés dans une liste.

4. Historique des déplacements

Les déplacements du curseur au sein d’un même fichier, ainsi que le passage d’un fichier à un autre, sont mémorisés dans un historique global qu’il est, bien sûr, possible ensuite de parcourir, un peu comme dans un navigateur Web.

Cette fonction n’est pas encore parfaite.

5. Autres améliorations

Voici quelques autres améliorations en vrac :

• il est possible de définir des signets dans chaque éditeur ;
• la recherche de chaînes de caractères dans l’ensemble du projet a été optimisée. Elle est maintenant beaucoup plus rapide ;
• il est possible de configurer le serveur mandataire du navigateur d’aide basé sur WebKit ;
• la boîte de dialogue de bienvenue a été simplifiée pour les petits écrans, et optimisée pour les processeurs lents (bienvenue aux ARM !).

Interpréteur et compilateur

1. Nouvelles instructions

• GOSUB : la fameuse instruction BASIC a finalement été ajoutée. Elle permet d’appeler une portion de code située à l’intérieur d’une fonction, et d’en revenir lorsque l’instruction RETURN est rencontrée. C’est assez moche, mais cela permet d’éviter un appel de fonction toujours coûteux en temps d’exécution.

• ON GOTO, ON GOSUB : il s’agit des instructions BASIC classiques permettant de se brancher sur une étiquette en fonction de la valeur d’une variable.

• Base64(), UnBase64() : ces deux fonctions permettent de coder une chaîne de caractères en base64 ou bien le contraire.

• CHMOD, CHOWN & CHGRP : ces trois instructions sont le pendant des commandes système de mêmes noms. Elles permettent respectivement de modifier les autorisations, le propriétaire et le groupe d’appartenance d’un fichier.

• Les fonctions MkBool$(), MkShort$(), MkInt$(), etc., font leur retour. La fonction Swap$() échange les octets contenus dans une chaîne de caractères. Cet ensemble de fonctions permet de transformer une suite de données binaires en chaîne de caractères, afin, par exemple, de l’envoyer sur une socket.

2. Avertissements

Le compilateur de la version 3.3 émet maintenant des avertissements lors des cas suivants :

• lorsqu’une variable locale, une variable privée, un argument de fonction, ou bien une fonction privée est inutilisée ;
• lorsqu’une variable locale ou un argument de fonction surcharge un symbole global.

L’environnement de développement affiche ces avertissements dans un onglet dédié du panneau d’information :

3. Optimisation de la pile

La pile de l’interpréteur est plus rapide : depuis la version 3.1, sur une idée d’Emil Lengrenn, la pile de l’interpréteur n’est plus allouée par malloc() mais par mmap(), exactement comme la pile du processus.

Par conséquent, elle grandit de manière automatique et les gains de performance sont conséquents, dès lors qu’on utilise beaucoup la récursivité !

4. Optimisations UTF-8

L’UTF-8, c’est génial. Celui qui l’a inventé aussi. Il n’y a qu’un seul problème, c’est lorsque vous devez trouver la position en mémoire d’un caractère à partir de son index.

Comme un caractère UTF-8 peut faire entre 1 et 4 octets, on est virtuellement obligé de parcourir toute la chaîne. Ce qui commence évidemment à poser problème lorsque la longueur de la chaîne de caractères est de plusieurs centaines de milliers d’octets.

Pour optimiser cela, la version 3.3 introduit un système de cache interne des dernières positions calculées dans la dernière chaîne de caractères UTF-8 traitée.

Cela permet d’accélérer grandement la coloration syntaxique de lignes très longues dans l’éditeur.

Pour information, la coloration syntaxique du code Gambas est faite en C. Toutes les autres (HTML, SQL, C, JavaScript, CSS) sont gérées par le composant gb.eval.highlight écrit en Gambas.

5. Support des nombres complexes

Si le composant gb.gsl n’est pas utilisé, et qu’un programme fait référence à un nombre complexe, le composant gb.complex est automatiquement chargé.

Ce composant offre une gestion complète de l’arithmétique des nombres complexes. Mais, contrairement à gb.gsl, il n’offre aucune fonction transcendantale complexe.

Composants graphiques

Les deux composants graphiques (gb.qt4 basés sur Qt 4 et gb.gtk GTK+ 2.0) sont sans doute les plus subtils. Plus d’une centaine de bogues ont été corrigés dans ces composants depuis la version 3.0, dont certains (trop !) sont des contournements de bogues présents dans les bibliothèques sous‐jacentes.

Par dessus ces deux composants graphiques « natifs », vous trouvez un ensemble de contrôles programmés intégralement en Gambas. Ils se situent dans les composants gb.form et gb.db.form, ce dernier regroupant les composants reliés à des requêtes de bases de données.

Les principales modifications apportées depuis la version 3.0 sont les suivantes :

1. Prise en charge des tablettes graphiques

Comme GTK+ impose l’activation explicite de cette prise en charge pour chaque widget, seul le contrôle DrawingArea peut capturer les événements générés par les périphériques d’entrée « étendus ». Pour ce faire, il faut explicitement définir sa propriété Tablet à TRUE.

Les événements tablette génèrent les mêmes événements que la souris, excepté qu’une nouvelle classe Pointer permet de récupérer les propriétés de l’événement : coordonnées fractionnaires, pression du crayon, etc.

Qt et GTK+ ne fournissent pas exactement les mêmes propriétés pour ce genre d’événements. Pourquoi ? C’est encore un mystère pour moi… Heureusement, Gambas essaie de cacher cette disparité.

2. Réécriture du contrôle GridView en Gambas

Le contrôle GridView a été intégralement récrit en Gambas pour les raisons suivantes :

• le contrôle natif de Qt est incapable de gérer un grand nombre de lignes ; le GridView en Gambas est plus rapide (si, si) et peut sans problème gérer plusieurs millions de lignes ;

• il n’est plus nécessaire de programmer un GridView dans le composant gb.gtk ; on économise du code, de la maintenance, et surtout le comportement du contrôle est quasi‐identique, qu’on utilise gb.gtk ou gb.qt4 ;

• il est maintenant possible d’ajouter des fonctionnalités au contrôle GridView qui étaient inexistantes dans le contrôle natif de Qt.

Les contrôles TreeView, ListView et ColumnView risquent eux aussi d’être récrits en Gambas dans une prochaine version.

L’intérêt est que, même si l’on perd légèrement en performances ou en consommation mémoire, l’écriture d’un composant graphique à l’interface identique, qui serait basé sur d’autres bibliothèques que Qt ou GTK+, sera beaucoup plus facile.

3. Améliorations et optimisation du composant GTK+

Dans les précédentes versions, chaque contrôle de gb.gtk était forcé d’avoir sa propre fenêtre X11, contrairement à gb.qt4 où, par défaut, tous les contrôles étaient natifs, c’est‐à‐dire sans fenêtre X11.

Désormais, le comportement par défaut de GTK+ prévaut. C’est‐à‐dire que les contrôles n’ont plus leur propre fenêtre X11 et se comportent visuellement comme les contrôles de Qt.

Malheureusement, certains widgets GTK+ continuent à utiliser des fenêtres X11 malgré tout (TextBox, TextArea…), ce qui pose des problèmes de superposition à l’écran (les contrôles sans fenêtre X11 sont toujours situés derrière les contrôles avec fenêtre X11).

La solution retenue est que les contrôles de type Panel dont la propriété Background (couleur d’arrière‐plan) est définie, ont leur propre fenêtre X11. Ce « truc » permet de contourner les problèmes de superposition et d’avoir un programme qui se comporte visuellement de manière identique, qu’il utilise gb.gtk ou gb.qt4.

Enfin, l’algorithme d’arrangement automatique des conteneurs a été corrigé pour éviter les déclenchements redondants et donc inutiles. L’amélioration des performances lorsqu’on redimensionne un formulaire compliqué sont visibles. Mais Qt reste encore le plus rapide.

4. Gestion des thèmes d’icônes

Gambas dispose d’une classe Stock permettant de manipuler un stock d’icônes prédéfinies à partir d’une clef (open, save, left, etc.) et d’une taille quelconque.

Avant la version 3.3, l’utilisateur avait la possibilité d’utiliser un thème natif stocké dans le composant gb.form.stock, ou bien le thème du bureau courant (KDE, GNOME, Xfce, Mate ou LXDE), ou bien le thème d’un bureau spécifié explicitement.

Depuis la version 3.3, il est possible d’utiliser n’importe quel thème d’icônes installé sur le système, en spécifiant le nom de son répertoire de stockage (oxygen, hicolor, Amaranth, etc.).

Voici par exemple un morceau de l’environnement de développement sous KDE utilisant le thème d’icônes GTK+ « Foxtrot » :

5. Autres améliorations diverses

• Les contrôles peuvent être exclus individuellement de la « chaîne de _focus_ », c’est‐à‐dire que l’appui sur la touche Tab les ignore.

• Le contrôle SidePanel peut avoir des bordures transparentes, comme par exemple les séparations de Thunderbird.

• Le composantgb.gtk.opengl permet d’utiliser OpenGL dans les applications GTK+.

• Le composant gb.gui.opengl a été ajouté. Il permet d’utiliser le composant OpenGL correspondant au bureau courant (gb.qt4.opengl ou gb.gtk.opengl), dans le même principe que gb.gui.

• Le composant gb.desktop qui sert d’interface aux fonctionnalités du bureau courant — tels que le gestionnaire de mots de passe, l’économiseur d’écran et le gestionnaire de fenêtres — est beaucoup plus fiable. La prise en charge de LXDE et de Mate a été finalisée. Une interface avec les associations entre les types MIME et les fichiers d’application *.desktop a été ajoutée.

Conclusion

Voilà, j’espère que ce petit tour aura éveillé l’intérêt de ceux qui ne connaissaient pas encore Gambas, ou fait découvrir des choses à ceux qui le connaissaient déjà.

Il y a eu, bien sûr, de très nombreuses autres modifications et corrections de bogues depuis la version 3.0, mais nous ne les aborderons pas toutes ici en détails.

Parlons maintenant un peu d’avenir, même si c’est toujours risqué :

• il va falloir passer à Qt 5 et à GTK+ 3 ;

• Wayland arrive beaucoup plus rapidement que prévu, cela nécessitera un profond nettoyage des composants graphiques afin d’en retirer toutes les spécificités X11 (coordonnées de souris globales, dialogue avec le gestionnaire de fenêtres, etc.). D’autre part, la « transparence réseau », introduite récemment dans Wayland, nécessitera la gestion simultanée de plusieurs pointeurs et curseurs dans la même fenêtre ;

• Gambas tourne de mieux en mieux sur les plates‐formes ARM ; le developpeur se demande comment il serait possible de le faire tourner sur Android ;

• amélioration à prévoir du composant Web de manière à rendre le développement d’applications Web en Gambas de plus en plus agréable.

Et pour terminer en beauté, le développeur qui, paraît‐il, est râleur, aimerait pousser trois petits coups de gueule :

Coup de gueule № 1

Je viens de lire que Qt 5 ne prendra plus en charge les tablettes — tandis que GTK+ 3, au contraire, va améliorer sa prise en charge des périphériques étendus.

J’espère qu’ils ne vont pas faire ça. Et plutôt que de supprimer une fonctionnalité essentielle, si la prise en charge du format SVG pouvait être déboguée, ça ne serait pas plus mal !

Coup de gueule № 2

En faisant tourner l’environnement de développement sous Valgrind, je me suis aperçu que 10 % du temps de démarrage étaient passés dans une unique fonction de la bibliothèque X !

Après analyse, il s’avère que l’initialisation des méthodes d’entrées X (X Input Method) doit analyser un fichier texte d’un demi‐mégaoctet, qui décrit toutes les possibilités de composition des touches du clavier.

Or, cette analyse se base sur les fonctions de flux standard de la libc (en particulier la fonction getc() qui est appelée pour chaque caractère lu !). Et les fonctions de flux de la libc sont très lentes.

C’est en les utilisant le moins possible que j’ai pu doubler la vitesse du compilateur de Gambas entre la version 2 et la version 3.

J’ai reporté le problème sur le _bugzilla de freedesktop.org, mais je n’ai pas de nouvelles depuis._

J’ai même corrigé la routine moi‐même, mais je n’ai pas réussi à compiler les bibliothèques X11. Trop de dépendances incompréhensibles…

C’est quand même dommage de dépenser autant de temps au lancement de chaque application Qt (et sans doute aussi GTK+) ! Mais notez que les applications KDE échappent sans doute à ce problème, vu qu’elles sont normalement lancées par le fork d’un unique exécutable.

Coup de gueule № 3

Dernier coup de gueule : que faut‐il faire pour espérer qu’un jour Debian, Ubuntu et openSUSE réussissent à empaqueter Gambas correctement ?

Je suis ouvert à toutes les solutions ! Excepté faire les paquets moi‐même, car je n’ai malheureusement pas le temps.

Voilà, j’ai râlé, je me sens mieux. Merci de votre attention, et vive le logiciel libre !

Aller plus loin

• LinuxFr.org : Gambas 3 est sorti le 31 décembre 2011 (287 clics)
• Site ouèbe de Gambas (758 clics)
• Le site de la communauté Gambas francophone (277 clics)