Organisation d'une bibliotheque multiplateforme

[Xavier Petit]

Bonjour,

Je m'appelle Xavier et je suis débutant autodidacte en Ada, c'est mon
premier message sur un groupe de discussion.

Je suis en train de développer une bibliothèque graphique
multiplateforme avec comme objectif de pouvoir faire du "dessin"
facilement, une application graphique minimale, voire une GUI.

Les trois idées directrices pour ce projet sont dans l'ordre :
simplicité, minimalisme, efficacité.

Multiplateforme signifie dans ce cas pouvoir fonctionner sur Linux,
Windows et Mac.

Seulement je me pose des questions sur l'organisation du code source et
si mes recherches internet m'ont aidé, je souhaiterais faire appel à vos
avis et expériences.

Actuellement la hiérarchie ressemble à ça :

- adada
- adada-linux (private)
- adada-window
- adada-window-draw
- adada-window-event

adada-linux est un paquetage privé qui est utilisé par les
implémentations de adada-window et de ses paquetages enfants.

Ainsi les spécifications de adada, adada-window, adada-window-draw et
adada-window-event sont identiques aux différentes plateformes et les
implémentations de adada-window, adada-window-draw et
adada-window-event diffèrent.

Si je m'autorisais à présenter des spécifications différentes d'une
plateforme à une autre au niveau de leur partie privée uniquement, je
pourrais supprimer le paquetage privé adada-linux (et ceux à venir).

Mais est-ce là une bonne pratique de programmation en Ada ? Écrire des
couples spécifications/corps différents pour chaque OS, avec seulement
la partie publique des spécifications commune..

En ayant structuré la bibliothèque adada en 3 paquetages enfants
(window, window-draw, window-event) et étant confronté au fait qu'ils
doivent faire appel aux mêmes données de l'API bas niveau des OS, il a
fallu rassembler et séparer ces données et sous-programmes, en
l'occurrence dans le paquetage privé linux.

J'aimerais aussi bien pouvoir me passer de gprbuild et des moyens
externes au langage de faire du développement multiplateforme (gprbuild
par exemple). J'en arrive à un bazar comme ça :

- adada
- linux
- linux-window
- linux-window-draw
- linux-window-event

adada.ads contient :
-- begin
with Linux;

package Adada renames Linux;
-- end

Mais le renommage peut aussi se faire au niveau du programme de
l'utilisateur, l'idée est qu'il n'y aurait ensuite qu'un ou deux mots à
changer dans les sources pour passer d'une plateforme à une autre (un
peu comme modifier un fichier gpr), bon ça ne reproduit pas le
comportement de l'appel d'un gprbuild qui détermine la plateforme.

L'ennui est entre autre qu'il y a visibilité sur les paquetages de
toutes les plateformes... Ça me semble contraire à la philosophie Ada.

J'aimerais bien des conseils, et savoir comment vous voyez les choses à
ce niveau là.

Si vous avez des questions concernant la bibliothèque elle-même, les
choix techniques, les API sous-jacentes, ce qu'elle ne permettra (pas)
de faire, n'hésitez pas à me les poser, ça me permettrait de remettre en
question certains choix assez drastiques que j'ai fait :

adada-window.ads ne contient que 10 lignes et va sans doute évoluer en
diminuant, il n'y a aucun appel de création/destruction de fenêtre, la
fenêtre ne se créée que lorsqu'on souhaite afficher du contenu (via
adada-window-draw) et sa destruction est automatique (via finalisation).
Le rafraîchissement et le tampon sont gérés en interne, on indique juste
où et de quelle couleur sont les pixels que l'on veut dessiner (le
dessin vectoriel, l'affichage de texte viendront ensuite).

adada-window-event.ads a une seule fonction (qui retourne le prochain
événement, à utiliser dans une "event loop").

Merci d'avance !

[Blady]

Bonjour Xavier,

Je m'intéresse aussi fortement aux bibliothèques graphiques Ada
multiplateformes.
Il n'en existe pas des masses en licence libre : GTKAda et Gnoga voire
QTAda.
GTKAda et QTAda sont des surcouches à des bibliothèques existantes en C
et C++. Leur évolution est donc contrainte par celles-ci.
Gnoga bien que reposant sur Javascript est une tentative plutôt réussie
de bibliothèque graphique multiplateforme.

Tu me vois venir avec ma question: qu'envisages-tu de ton côté ?

Pascal.
http://blady.pagesperso-orange.fr

Post by Xavier Petit
Bonjour,
Je m'appelle Xavier et je suis débutant autodidacte en Ada, c'est mon
premier message sur un groupe de discussion.
Je suis en train de développer une bibliothèque graphique
multiplateforme avec comme objectif de pouvoir faire du "dessin"
facilement, une application graphique minimale, voire une GUI.
simplicité, minimalisme, efficacité.
Multiplateforme signifie dans ce cas pouvoir fonctionner sur Linux,
Windows et Mac.

8<...>8

Post by Xavier Petit
Si vous avez des questions concernant la bibliothèque elle-même, les
choix techniques, les API sous-jacentes, ce qu'elle ne permettra (pas)
de faire, n'hésitez pas à me les poser, ça me permettrait de remettre en
adada-window.ads ne contient que 10 lignes et va sans doute évoluer en
diminuant, il n'y a aucun appel de création/destruction de fenêtre, la
fenêtre ne se créée que lorsqu'on souhaite afficher du contenu (via
adada-window-draw) et sa destruction est automatique (via finalisation).
Le rafraîchissement et le tampon sont gérés en interne, on indique juste
où et de quelle couleur sont les pixels que l'on veut dessiner (le
dessin vectoriel, l'affichage de texte viendront ensuite).
adada-window-event.ads a une seule fonction (qui retourne le prochain
événement, à utiliser dans une "event loop").
Merci d'avance !

[Xavier Petit]

Bonjour Pascal,

Post by Blady
Il n'en existe pas des masses en licence libre : GTKAda et Gnoga voire
QTAda.

En effet il n'existe à priori qu'une GUI libre (Lumen semble avoir été
avorté), multiplateforme écrite en Ada, c'est Gnoga qui dépasse même le
cadre d'une GUI, visant à être un framework et utilisant le web comme
interface.

Post by Blady
Gnoga bien que reposant sur Javascript est une tentative plutôt réussie
de bibliothèque graphique multiplateforme.

Cependant Gnoga repose sur les navigateurs internet qui pour
fonctionner implémentent le DOM.
Hélas le DOM est actuellement sous-performant, ce qui rend la navigation
dans une interface web extrêmement lourde, et donc des applications
Gnoga "natives" (dans un widget gtk webkit) seraient actuellement plus
lourdes et lentes encore que du GtkAda, avec cependant les avantages
(accessibilité) que l'on connaît du Web, et ses inconvénients (lourdeur,
incompatibilités entre navigateurs).

Lorsqu'ils règleront ce souci de performance du DOM, cela libérera la
vitesse du JS. Netflix utilise d'ailleurs OpenGl comme "solution" à ce
problème.

Post by Blady
Tu me vois venir avec ma question: qu'envisages-tu de ton côté ?
Pascal.
http://blady.pagesperso-orange.fr

Cela fait longtemps que je veux faire de la 2D simple (afficher un
cercle pixel par pixel, un rectangle plein) en Ada.
Je pense que tout débutant en programmation cherche un jour ou l'autre à
sortir des limitations du mode texte, mais j'ai constaté qu'en quittant
la console, on quittait aussi sa simplicité.

Et comme j'ai également pour projet de faire une GUI, ben je commence
par la base, pour l'instant je me cantonne à faire une bibliothèque
graphique 2D, pas encore d'interface utilisateur à proprement parler,
Mais je cherche à la rendre simple au possible. Un "hello world" devrait
ressembler à quelque chose du genre :

with Adada.Window.Draw;

procedure Main is
use all type Adada.Window.Draw.Color_Name_T;

begin
Adada.Window.Draw.Line (From => (1, 1),
To => (10, 10),
Color => Blue);

delay 6.0;
end Main;

Le programme Main affichant pendant 6 secondes une fenêtre appelée
automatiquement "Main" et mis à la bonne taille pour contenir une ligne
oblique bleue. Et je trouve ça encore trop compliqué (le "use all type"
suivi d'un nom assez long)...

En cherchant à faire de la 2D en Ada j'ai envisagé :
- Une librairie existante (SDL, SFML, Allegro, etc)
- L'API native de chaque OS (X11, Quartz, win32 + Direct2D)
- OpenGL avec une librarie associée (FreeGlut, GLFW)

Certaines librairies proposent trop de choses par rapport à ce que je
souhaitais faire, elles sont assez lourdes (on a encore rien fait que
300 000 allocations dynamiques sont réalisées, et prennent plusieurs
mégas de RAM).

Un moyen assez portable aurait été d'utiliser OpenGL + GLFW garantissant
du même coup des performances graphiques hors normes,
l'inconvénient est qu'OpenGL est une API 3D et non 2D, d'ailleurs plus
complexe à utiliser depuis sa version 3.3. Il existe plusieurs moyens
d'utiliser OpenGL pour faire de la 2D, mais plutôt ardus.

Je me suis donc rabattu sur les API natives des OS, enfin pas
exactement, j'utilise XCB pour Linux (et non directement X11) dont un
binding existe déjà (écrit par Ludovic Brenta).
Bien utilisées je pense que ces API fourniront les performances
suffisantes pour garantir un affichage fluide et stable.

Du côté de la bibliothèque j'ai finalement fait disparaître le paquetage
privé Linux et utilise les parties privées pour tout ce qui est lié à
l'implémentation. Ce n'est certainement pas la bonne façon de faire,
mais je m'attaquerai à ce problème juste avant de faire la version Windows.

Grâce au binding XCB j'ai une assez bonne gestion du clavier
(reconnaissance des touches) que j'essaie d'améliorer :
Dissocier la répétition des touches des évènements de pression et de
relâchement dans un évènement séparé (Key_Repeat).
Cela laisser le choix à l'utilisateur de tenir compte ou non, quand il
le souhaite, de la répétition automatique des touches.

Éviter certains phénomènes non gérés sur X11 : une touche ne peut être
relachée que si elle a été précédemment pressée et vice-versa, ainsi que
d'autres limitations liées aux keysyms.

Adada permet pour l'instant de faire des appels de ce genre (dans le
handler de Key_Press):

if Key.Combination (Ctrl + Alt + 0) then
null;
elsif Key.Name = Escape then
null;
elsif Key.Is_Printable then
Register (Key.Character);
end if;

D'ailleurs j'ai l'impression que je finirai en enfer à écrire des choses
comme ça :

generic
Quit : access procedure (Ready : out Boolean) := null;
Key_Press : access procedure (Key : Key_T) := null;
Key_Release : access procedure (Key : Key_T) := null;
Key_Repeat : access procedure := null;
Button_Press : access procedure (Button : Button_T) := null;
Button_Release : access procedure (Button : Button_T) := null;
Pointer_Motion : access procedure (X, Y : Length_T) := null;
Screen_Refresh : access procedure := null;
Window_Resize : access procedure (Width, Height : Length_T) := null;

package Adada.Window.Event.Handling is

Cela me permet d'instancier le paquetage en précisant uniquement les
events que je souhaite prendre en compte... Donc finalement il n'est
plus question de traitement par event loop.

Une fois que les évènements et dessins fonctionneront bien sur Linux, je
les porterai sur Windows, puis je créerai les sous-programmes de dessin
vectoriel et de texte (avec antialiasing obligatoire et propre).
J'espère avec cette surcouche pouvoir masquer le caractère pixelisé de
l'affichage et permettre leur utilisation exclusive.

[Blady]

Bonjour Xavier,

Merci pour Lumen, je ne connaissais pas mais effectivement il n'y a pas
eu de modif depuis 2013.

Pour des API graphiques basiques j'aime bien celles de feu TurboPascal.
Je les ai traduites en Ada avec en bibliothèque support GTKAda ou Gnoga:
http://blady.pagesperso-orange.fr/creations.html#ada_tp7

Il y a aussi le support du clavier et de la souris ;-)

Pascal.
http://blady.pagesperso-orange.fr

Le 16/10/2015 21:41, Xavier Petit a écrit :
<...>

Post by Xavier Petit
Cela fait longtemps que je veux faire de la 2D simple (afficher un
cercle pixel par pixel, un rectangle plein) en Ada.
Je pense que tout débutant en programmation cherche un jour ou l'autre à
sortir des limitations du mode texte, mais j'ai constaté qu'en quittant
la console, on quittait aussi sa simplicité.
Et comme j'ai également pour projet de faire une GUI, ben je commence
par la base, pour l'instant je me cantonne à faire une bibliothèque
graphique 2D, pas encore d'interface utilisateur à proprement parler,
Mais je cherche à la rendre simple au possible. Un "hello world" devrait

<...>

[Xavier Petit]

Bonjour Pascal,

Post by Blady
Pour des API graphiques basiques j'aime bien celles de feu TurboPascal.
http://blady.pagesperso-orange.fr/creations.html#ada_tp7
Il y a aussi le support du clavier et de la souris ;-)

Merci pour les liens, ça va me donner des idées !
Et désolé pour le mauvais formatage du précédent post, j'ai dû oublier
de faire des [CTRL]-[R] supplémentaires dans Thunderbird.