The Graphic User Interface Development

Introduction

La création de GUI a été et reste un problème relativement complexe à gérer. Une des principale contrainte est le lien souvent étroit entre l’interface et les fonctionnalités développées. Souvent l’ajout ou la modification entraînent un changement radicale de l’interface et nécessite une refonte complète du code. De là, l’idée de scinder la couche présentation (GUI) de la couche métier.

Reste que les mécanismes pour permettre le liens entre ces deux mondes restent laborieux suivant les technos et framework utilisés . A cela viens se rajouter le liens fort qui existe entre l’interface utilisateur et l’OS du à l’utilisation de l’API propriétaire correspondant.

Alors comment choisir ? Utiliser le framework “livrer” avec  l’OS, utiliser un framework cross-plateforme, ou créer sa propre librairie ?

 

Les principaux moyens de création d’un GUI

0
Visual Factory 1.00 – Imalogic 1996 – Simple Interface Utilisateur développé en C

En 1996, lors du développement de Visual Factory 1.0, le choix s’est porté sur un mix entre utilisation de FLTK et un framework fait maison pour la gestion des boutons/fenêtres basé sur des skins (images).

skindown4
Image Skin “Down”
skinup4
Image Skin “Up”

 

 

 

 

 

 

La problématique a gérer était l’intégration d’un GUI dans un environnement basé sur DirectX. Avec cet environnement, les fonctionnaliste de base de l’OS (widget) ne sont pas accessible. Il a donc fallu développer une couche interface graphique propriétaire.

A l’époque, les carte graphiques ne permettant pas l’accélération 3D, tout les effets était réalisé en software rendering. Le logiciel ouvrait, via directx deux buffer 16bit  pour le double buffering. Pour accéléré le processus de rendu, on utilisait des tables de précalculée pour la gestion de la transparence notamment. Les routines d’affichages étaient réalise en assembleur 80×86.

L’interface et les effets visuels étaient rendu en temps réel dans ces buffers et ensuite envoyés vers la carte graphique.

La méthode la plus simple pour réaliser l’interface (boutons) était basé sur l’utilisation de deux images représentant l’interface selon deux état (activé/ non activé) ; dans le code on testait ou se trouvait le pointeur de la souris et suivant la zone délimité sélectionnée (représentant un bouton ou en endroit “clickable”) on activait la fonctions spécifiques associées.

Durant cette période, Borland avait sorti C++ Builder, une petite révolution dans la création d’interface logiciel basé sous un environnement Windows, une alternative à MFC, permettant de réduire la programmation par l’utilisation d’un système “drag & drop” de widget sur des zones représentant les fenêtre de l’applications. Le code métier étant alors associé a une action définie sur un widget.

De nos jours, ils existent des d’outils de création de GUI basé sur des environnements différentier, plus ou moins portable.

De C++ Buidler on a vu se créer des solutions x-plateforme pour mobile (Embarcadero). Sur PC le créateur de C++ Builder est parti chez Microsoft pour développé le RAD tools .Net basé sur C#.

Chaque système d’exploitation (Windows, Mac OS X, Linux…) propose au moins un moyen de créer les interfaces utilisateurs. Sur une “console texte”, l’expérience utilisateur se restreint à l’affichage de texte et à l’utilisation du clavier.

EN générale, les OS mettent à disposition un framework propriétaire permettant d’améliorer l’expérience utilisateur. Ces framework permettent de réaliser des interfaces homme machine’ (IHM) ou Graphic User Interface (GUI).

Un des problèmes, c’est que ces framework sont liés à l’OS et ne sont pas portable, le programme créé uniquement pour Windows ne pourra fonctionner que sous Windows et pas ailleurs.

Du point de vue de l’interface d’un logiciel :

  • soit on écrit son application spécialement pour l’OS qu’on veut, mais le programme ne sera pas portable ;
  • soit on utilise une bibliothèque qui s’adapte à tous les OS, c’est-à-dire une bibliothèque multiplateforme et on pourra plus « facilement » la distribuer sur d’autres OS.

La seconde solution est en général la plus souple. Mais elle a comme désavantage (pour certains puristes) de ne pas utiliser le look & feel de l’OS, et de proposer son « propre look ». D’un autre coté , elle garanti une cohérence visuelle entre un produit tournant sur des plateformes (OS) différents, et du point de vue du développement, ces framework proposent des architectures et des fonctions de haut niveau qui aident à la l’évolution et à la maintenance de l’application.

Je vais dans un premier temps présenter des bibliothèques propres aux principaux OS, à titre d’information.

Ensuite, je verrais quelles sont les principales bibliothèques multiplateformes existantes.

Les bibliothèques propres aux OS

Chaque OS propose au moins une bibliothèque qui permet de créer des fenêtres, boutons et autres widgets , un composant d’interface graphique, un élément visuel d’une interface graphique (bouton, barre de défilement, liste déroulante, etc. ).
Le défaut est qu’en général, cette bibliothèque ne fonctionne que pour l’OS pour lequel elle a été créée. Ainsi, si vous utilisez la bibliothèque de Windows, votre programme ne marchera que sous Windows.

  • Sous Windows : on dispose du framework .NET. C’est un ensemble très complet de bibliothèques utilisables en C++, C#, Visual Basic… Le langage de prédilection pour travailler avec .NET est C#. Il est à noter que .NET peut aussi être utilisé sous Linux (avec quelques limitations) grâce au projet Mono. En somme, .NET est un vrai couteau suisse pour développer sous Windows et on peut aussi faire fonctionner les programmes sous Linux, à quelques exceptions près.
  • Sous Windows en DirectX utilisé principalement pour les jeux et applications graphiques spécifiques, ce mode est un peu particulier car les bibliothèques standard de gestion de fenêtres et autres widget ne sont pas disponible. On dispose d’une librairie fort succincte livrée dans le SDK de Microsoft (DXUTILS) qui se compose de quelques widgets de base.

  • Sous Mac OS X : la bibliothèque de prédilection s’appelle Cocoa. On l’utilise en général en langage « Objective C ». C’est une bibliothèque orientée objet.
  • Sous Linux : tous les environnements de bureau (appelés WM pour Windows Managers) reposent sur X, la base des interfaces graphiques de Linux. X propose une bibliothèque appelée Xlib mais, sous Linux, on programme rarement en Xlib. On préfère employer une bibliothèque plus simple d’utilisation et multiplateforme comme GTK+ (sous Gnome) ou Qt (sous KDE).

Il y a en une bibliothèque « de base » pour chaque OS. Certaines, comme Cocoa, ne fonctionnent que pour le système d’exploitation pour lequel elles ont été prévues. Il est généralement conseillé d’utiliser une bibliothèque multiplateforme si votre logiciel doit être distribué sur différents environnements.

Les bibliothèques multiplate-formes

Les avantages d’utiliser une bibliothèque multiplateforme sont nombreux (même si vous voulez créer des programmes uniquement pour Windows).

  • Dans la majorité des cas, elles simplifient la création de l’interface utilisateur. Il faut généralement moins de lignes de code pour gérer l’interface utilisateur.
  • Elle doit permettre de scinder l’interface utilisateur du « code métier »
  • Ensuite, elles uniformisent le tout, elles forment un ensemble cohérent dans lequel il est facile de s’y retrouver.
  • Les noms des fonctions et des classes sont choisis de façon logique de manière à vous aider autant que possible.
  • Enfin, elles font abstraction du système d’exploitation mais aussi de la version du système. Cela veut dire que si demain Cocoa cesse d’être utilisable sous Mac OS X, votre application continuera à fonctionner car la bibliothèque multiplateforme s’adaptera aux changements.

Choisir une bibliothèque multiplateforme, n’est pas chose aisée, ce choix doit tenir compte des platesformes visées pour le déploiement, de la facilité d’utilisation, des tools associés(UI designer), …

Voici quelques-unes des principales bibliothèques multiplateforme à connaître, au moins de nom :

  • .NET (prononcez « Dot Net ») : développé par Microsoft pour succéder à la vieillissante API Win32. On l’utilise souvent en langage C#. On peut néanmoins utiliser .NET dans une multitude d’autres langages dont le C++. .NET est portable car Microsoft a expliqué son fonctionnement. Ainsi, on peut utiliser un programme écrit en .NET sous Linux avec Mono. Pour le moment néanmoins, .NET est principalement utilisé sous Windows.
  • GTK+ : une des plus importantes bibliothèques utilisées sous Linux. Elle est portable, c’est-à-dire utilisable sous Linux, Mac OS X et Windows. GTK+ est utilisable en C mais il en existe une version C++ appelée GTKmm (on parle de wrapper ou encore de surcouche). GTK+ est la bibliothèque de prédilection pour ceux qui écrivent des applications pour Gnome sous Linux, mais elle fonctionne aussi sous KDE. C’est la bibliothèque utilisée par exemple par Firefox, pour ne citer que lui.
  • Qt : Je vais le décrire plus en détail dans un prochain post. Sachez néanmoins que Qt est très utilisée sous Linux aussi, en particulier dans l’environnement de bureau KDE.  Qt offre des composants d’interface graphique (widgets), d’accès aux données, de connexions réseaux, de gestion des fils d’exécution, d’analyse XML, etc. ; par certains aspects, elle ressemble à un framework lorsqu’on l’utilise pour concevoir des interfaces graphiques ou que l’on conçoit l’architecture de son application en utilisant les mécanismes des signaux et slots par exemple.
  • wxWidgets : une bibliothèque objet très complète elle aussi, comparable en gros à Qt. Sa licence est très semblable à celle de Qt (elle vous autorise à créer des programmes propriétaires). Néanmoins, j’ai quand même choisi de vous montrer Qt car cette bibliothèque est plus facile pour la formation des débutants. Sachez qu’une fois qu’on l’a prise en main, wxWidgets n’est pas beaucoup plus compliquée que Qt. wxWidgets est la bibliothèque utilisée pour réaliser la GUI de l’IDE Code::Blocks.
  • FLTK : contrairement à toutes les bibliothèques « poids lourds » précédentes, FLTK se veut légère. C’est une petite bibliothèque dédiée uniquement à la création d’interfaces graphiques multiplateforme.

  • AntTweakBar est une petite librairie super utile pour manipuler de manière interactive les variables. La plupart du temps elle est directement utilisée dans des applis en C/C++. Je l’utilise pour mes projets 3D.