Solutions IHM pour Linux embarqué
Contact :Jérémy ROSEN - 01 42 68 28 04 - jeremy.rosen@openwide.fr
NOM
CLIENT
2
Programme
● Présentation d'Open Wide
● IHM et embarqué : spécificités
● Les approches possibles
● Xorg, Wayla...
NOM
CLIENT
3
Présentation Open Wide
● Entreprise créée en septembre 2001
● Environ 120 salariés sur Paris, Lyon et Toulous...
NOM
CLIENT
4
IHM et embarqué
● IHM = Interface Home Machine : affichage et saisies
● Ce fut longtemps un problème mineur c...
NOM
CLIENT
5
Particularité des IHM embarquées
● Contraintes classiques de l'embarqué
– Processeur
– RAM
– Carte vidéo, acc...
NOM
CLIENT
6
Plusieurs approches
● Développement d'une application embarquée
– Le cas général, proche du desktop Linux
– É...
NOM
CLIENT
7
Le framebuffer 1/2
● Pilotage de la carte directement par le noyau (/dev/fb0 → plus
de client/serveur)
● Mode...
NOM
CLIENT
8
Le framebuffer 2/2
● Exemples d'utilitaires/bibliothèques disponibles/compatibles
– Bas niveau → fbset, fbi, ...
NOM
CLIENT
9
X11, 1/2
● Linux est un UNIX
– Mode texte par défaut
– « X Window System » ou X11 à partir de 84
– Xorg à par...
NOM
CLIENT
10
X11, 2/2
● Initialement peu adapté à l’embarqué
● Retour grâce à plusieurs éléments :
– L'augmentation de la...
NOM
CLIENT
11
Wayland 1/3
● X11 a atteint ses limites
– Mauvaise intégration au kernel, drivers intégrés à X11
– Protocole...
NOM
CLIENT
12
Wayland 2/3
Protocole de communication client/compositeur
● Le client dessine dans des buffers mémoire
– Dem...
NOM
CLIENT
13
Wayland Architecture
● Architecures comparées X/Wayland
NOM
CLIENT
14
Wayland 3/3
● Déjà présent dans le monde de l'embarqué
– Genivi
– Sailfish OS
● Demande une version adaptée ...
NOM
CLIENT
15
Bibliothèques graphiques
● Se placent « au dessus » de X11, Wayland ou du framebuffer
● Deux catégories
– Le...
NOM
CLIENT
16
● Bibliothèque d’ « abstraction »
du framebuffer
● Fonctionne avec le
framebuffer Linux mais
également avec ...
NOM
CLIENT
17
Exemple DirectFB
NOM
CLIENT
18
Bibliothèque principalement concue pour le jeu vidéo et les besoins
que cela entraîne.
● Fournit des primiti...
NOM
CLIENT
19
Exemple SDL
NOM
CLIENT
20
Les « toolkits » graphiques
● Fournissent un ensemble d’objets graphiques
– Menus
– Boutons
– Boîtes de dial...
NOM
CLIENT
21
● Toolkit C++ publié par Trolltech en 1996 (X11)
● Outil multi-plateforme (Linux (X11, Wayland, DirectFB...)...
NOM
CLIENT
22
Qt sur Mini2440
NOM
CLIENT
23
EFL
● Toolkit C
● Avantages :
– Peu gourmand en ressources, rapide
– Taillé pour l'embarqué
– Esthétique, mo...
NOM
CLIENT
24
EFL au frigo
NOM
CLIENT
25
● Développé pour GIMP (Gimp ToolKit)
● Toolkit en C multiplateforme (Linux, Windows, MacOS X)
● Construit su...
NOM
CLIENT
26
La prochaine version de la norme HTML permettra de développer des
applications complètement offline et non p...
NOM
CLIENT
27
Android
● Android n'est pas une IHM, c'est un OS.
● Difficile à adapter à un HW spécifique, prévu pour des
t...
Questions?
Solutions IHM pour Linux embarqué
Contact :Jérémy ROSEN - 01 42 68 28 04 - jeremy.rosen@openwide.fr
NOM
CLIENT
2
Programme
● Présentation d'Open Wide
● IHM et embarqué : spécificités
● Les approches possibles
● Xorg, Wayla...
NOM
CLIENT
3
Présentation Open Wide
● Entreprise créée en septembre 2001
● Environ 120 salariés sur Paris, Lyon et Toulous...
NOM
CLIENT
4
IHM et embarqué
● IHM = Interface Home Machine : affichage et saisies
● Ce fut longtemps un problème mineur c...
NOM
CLIENT
5
Particularité des IHM embarquées
● Contraintes classiques de l'embarqué
– Processeur
– RAM
– Carte vidéo, acc...
NOM
CLIENT
6
Plusieurs approches
● Développement d'une application embarquée
– Le cas général, proche du desktop Linux
– É...
NOM
CLIENT
7
Le framebuffer 1/2
● Pilotage de la carte directement par le noyau (/dev/fb0 → plus
de client/serveur)
● Mode...
NOM
CLIENT
8
Le framebuffer 2/2
● Exemples d'utilitaires/bibliothèques disponibles/compatibles
– Bas niveau → fbset, fbi, ...
NOM
CLIENT
9
X11, 1/2
● Linux est un UNIX
– Mode texte par défaut
– « X Window System » ou X11 à partir de 84
– Xorg à par...
NOM
CLIENT
10
X11, 2/2
● Initialement peu adapté à l’embarqué
● Retour grâce à plusieurs éléments :
– L'augmentation de la...
NOM
CLIENT
11
Wayland 1/3
● X11 a atteint ses limites
– Mauvaise intégration au kernel, drivers intégrés à X11
– Protocole...
NOM
CLIENT
12
Wayland 2/3
Protocole de communication client/compositeur
● Le client dessine dans des buffers mémoire
– Dem...
NOM
CLIENT
13
Wayland Architecture
● Architecures comparées X/Wayland
NOM
CLIENT
14
Wayland 3/3
● Déjà présent dans le monde de l'embarqué
– Genivi
– Sailfish OS
● Demande une version adaptée ...
NOM
CLIENT
15
Bibliothèques graphiques
● Se placent « au dessus » de X11, Wayland ou du framebuffer
● Deux catégories
– Le...
NOM
CLIENT
16
● Bibliothèque d’ « abstraction »
du framebuffer
● Fonctionne avec le
framebuffer Linux mais
également avec ...
NOM
CLIENT
17
Exemple DirectFB
NOM
CLIENT
18
Bibliothèque principalement concue pour le jeu vidéo et les besoins
que cela entraîne.
● Fournit des primiti...
NOM
CLIENT
19
Exemple SDL
NOM
CLIENT
20
Les « toolkits » graphiques
● Fournissent un ensemble d’objets graphiques
– Menus
– Boutons
– Boîtes de dial...
NOM
CLIENT
21
● Toolkit C++ publié par Trolltech en 1996 (X11)
● Outil multi-plateforme (Linux (X11, Wayland, DirectFB...)...
NOM
CLIENT
22
Qt sur Mini2440
NOM
CLIENT
23
EFL
● Toolkit C
● Avantages :
– Peu gourmand en ressources, rapide
– Taillé pour l'embarqué
– Esthétique, mo...
NOM
CLIENT
24
EFL au frigo
NOM
CLIENT
25
● Développé pour GIMP (Gimp ToolKit)
● Toolkit en C multiplateforme (Linux, Windows, MacOS X)
● Construit su...
NOM
CLIENT
26
La prochaine version de la norme HTML permettra de développer des
applications complètement offline et non p...
NOM
CLIENT
27
Android
● Android n'est pas une IHM, c'est un OS.
● Difficile à adapter à un HW spécifique, prévu pour des
t...
Questions?
Prochain SlideShare
Chargement dans…5
×

Les technologies Open Source pour les interfaces graphiques embarquées

618 vues

Publié le

Publié dans : Ingénierie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
618
Sur SlideShare
0
Issues des intégrations
0
Intégrations
12
Actions
Partages
0
Téléchargements
21
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Les technologies Open Source pour les interfaces graphiques embarquées

  1. 1. Solutions IHM pour Linux embarqué Contact :Jérémy ROSEN - 01 42 68 28 04 - jeremy.rosen@openwide.fr
  2. 2. NOM CLIENT 2 Programme ● Présentation d'Open Wide ● IHM et embarqué : spécificités ● Les approches possibles ● Xorg, Wayland et le Framebuffer ● Les bibliothèques graphiques – DirectFB – SDL ● Les toolkits – Qt – EFL – GTK ● HMTL5 ● Android
  3. 3. NOM CLIENT 3 Présentation Open Wide ● Entreprise créée en septembre 2001 ● Environ 120 salariés sur Paris, Lyon et Toulouse ● Industrialisation de composants open source ● Quatre activités : – OW Système d'Information – OW Outsourcing: hébergement – OW Ingénierie: informatique industrielle – OW Technologies: composants Java
  4. 4. NOM CLIENT 4 IHM et embarqué ● IHM = Interface Home Machine : affichage et saisies ● Ce fut longtemps un problème mineur car peu utilisées dans l’embarqué – Système autonome sans affichage (RTOS) – Configuration par réseau (SNMP, HTTP…) ● Évolution des systèmes, passage du RTOS au multimédia – Set-top box – Smartphones – Industriel → début de l’utilisation d’Android ● L'IHM n'est (était) pas le sujet de prédilection des spécialistes du logiciel embarqué
  5. 5. NOM CLIENT 5 Particularité des IHM embarquées ● Contraintes classiques de l'embarqué – Processeur – RAM – Carte vidéo, accélération matérielle ● Contraintes sur les périphériques de sortie – Afficheur LCD – Écrans de téléphone mobile – Écrans normaux ● Saisie (et donc ergonomie) spécifique – Boutons/télécommandes/joystick/main sales – Touch-screen – Reconnaissance/saisie vocale ● Environnement de travail – Compétence des équipes – Travail déporté/sur émulateur/sans hardware
  6. 6. NOM CLIENT 6 Plusieurs approches ● Développement d'une application embarquée – Le cas général, proche du desktop Linux – Équipe applicatif et graphique similaire – Travail sur émulateur ou sur plateforme ● Sous-traitance de l'applicatif vers une technologie spécifique – Android/html5 – Framework très connu – Compétences faciles à trouver – Développement séparé du produit final – Ne dispense pas d'une équipe système – Pas toujours adapté aux spécificités de l'embarqué – Pas toujours adaptable aux périphériques spécifiques
  7. 7. NOM CLIENT 7 Le framebuffer 1/2 ● Pilotage de la carte directement par le noyau (/dev/fb0 → plus de client/serveur) ● Mode VGA, SVGA, VESA ou (parfois) accéléré ● Programmation très bas-niveau (pixel) $ cp /dev/fb0 copie_ecran.raw ● Avantages : – Léger (faible consommation RAM) – Démarrage rapide ● Inconvénients : – Pilote spécial → drivers/video – Peu standard par rapport à X11 sur desktop
  8. 8. NOM CLIENT 8 Le framebuffer 2/2 ● Exemples d'utilitaires/bibliothèques disponibles/compatibles – Bas niveau → fbset, fbi, fbdump, ... – SVGALIB → DOOM :-) – DirectFB (abstraction du FB) – EFL – SDL – QtEmbedded – X11 sur FB – ...
  9. 9. NOM CLIENT 9 X11, 1/2 ● Linux est un UNIX – Mode texte par défaut – « X Window System » ou X11 à partir de 84 – Xorg à partir de 2004 ● Créé au MIT ● Système graphique réparti, modèle client/serveur → XFree86 (x86), X.org ● Puissant mais lourd + API complexe (rendering) ● Approche répartie rarement utilisée Utilisation de X11 →
  10. 10. NOM CLIENT 10 X11, 2/2 ● Initialement peu adapté à l’embarqué ● Retour grâce à plusieurs éléments : – L'augmentation de la puissance des CPU embarqués – L'utilisation de l'Atom/x86 – Le pilote accéléré devient commun au desktop et à l'embarqué Qt, GTK Motif
  11. 11. NOM CLIENT 11 Wayland 1/3 ● X11 a atteint ses limites – Mauvaise intégration au kernel, drivers intégrés à X11 – Protocole réseau inutile – Protocole au niveau rendering (fonts, inputs, dessin) quasi inutilisé de nos jours – Pas de compositing, partage de GPU quasi impossible ● Wayland reconstruit sur les besoins modernes – XOrg a fait passé les drivers dans le noyau (GEM/KMS/DRM) – Wayland supporte toujours le protocole X via XWayland ● Principalement ce qu'on fait actuellement avec X11, mais sans couches intermédiaires
  12. 12. NOM CLIENT 12 Wayland 2/3 Protocole de communication client/compositeur ● Le client dessine dans des buffers mémoire – Demande des buffers au kernel – Utilise EGL si nécessaire – Dessine lui même les widget et les décorations (via des librairies) ● Le compositeur place les buffers à l'écran – Réécrit et redirige les inputs – Reçoit les demandes de refresh des clients – Reçoit les handles vers les buffers des clients ● Pas de fonctions desktop avancées – Drag & Drop, iconify, XDG – Délégué à des programmes tiers
  13. 13. NOM CLIENT 13 Wayland Architecture ● Architecures comparées X/Wayland
  14. 14. NOM CLIENT 14 Wayland 3/3 ● Déjà présent dans le monde de l'embarqué – Genivi – Sailfish OS ● Demande une version adaptée des toolkits pour le client – Supporté par EFL, Gtk+3.10, Qt5, SDL (expérimental) ● Demande un compositeur – Weston – Lipstick (Sailfish OS) – Gtk, Qt, EFL : en cours d'écriture Wayland n'est pas encore mature mais ce sera sans doute la solution par défaut pour l'embarqué dans quelques années
  15. 15. NOM CLIENT 15 Bibliothèques graphiques ● Se placent « au dessus » de X11, Wayland ou du framebuffer ● Deux catégories – Les bibliothèques d'abstraction → portabilité mais pas d'objets graphiques évolués (SDL, DirectFB) – Les toolkits graphiques → fournissent des objets graphiques et peuvent se placer au dessus des bibliothèques d'abstraction Qt → X11 Qt → Wayland Qt → FB Qt → DirectFB
  16. 16. NOM CLIENT 16 ● Bibliothèque d’ « abstraction » du framebuffer ● Fonctionne avec le framebuffer Linux mais également avec X11 (--enable-x11) ● Prise en compte des entrées (souris, clavier, …) ● Fournit des pilotes FB accélérés
  17. 17. NOM CLIENT 17 Exemple DirectFB
  18. 18. NOM CLIENT 18 Bibliothèque principalement concue pour le jeu vidéo et les besoins que cela entraîne. ● Fournit des primitives graphiques ET audio ● Portables sur Linux, Windows, Mac OS X, IOS, Android ● Pour Linux, utilisable sur framebuffer, DirectFB, X11 ● Utilisée pour le portage d’applications graphiques (jeux) et légères ● Gestion basique de l’écran: fenêtres, transparence, polices de caractères, … ● Supporte OpenGL et Direct3D ● Gestion des Input, du son, du réseau, des threads etc...
  19. 19. NOM CLIENT 19 Exemple SDL
  20. 20. NOM CLIENT 20 Les « toolkits » graphiques ● Fournissent un ensemble d’objets graphiques – Menus – Boutons – Boîtes de dialogues – WebView – Mediaplayer ● Exemples: – Athena widgets, OSF-Motif (X11) → obsolète – WxWidgets → obsolète – Qt – EFL (Enlightenment, E18) – GTK+
  21. 21. NOM CLIENT 21 ● Toolkit C++ publié par Trolltech en 1996 (X11) ● Outil multi-plateforme (Linux (X11, Wayland, DirectFB...), Windows, MacOS, Android, iOS ...) ● Connu grâce à KDE ● Dernière version: 5.3 ● Avantages : – Couvre plus que la partie graphique – Excellente documentation – Outil de conception d'interface wysiwyg (QtCreator) ● Inconvénients : – Lourd (comparé aux autres)
  22. 22. NOM CLIENT 22 Qt sur Mini2440
  23. 23. NOM CLIENT 23 EFL ● Toolkit C ● Avantages : – Peu gourmand en ressources, rapide – Taillé pour l'embarqué – Esthétique, modulaire, configurable ● Inconvénients – Peu connu – Moins de documentation que pour Qt – Pas de constructeur d'interface
  24. 24. NOM CLIENT 24 EFL au frigo
  25. 25. NOM CLIENT 25 ● Développé pour GIMP (Gimp ToolKit) ● Toolkit en C multiplateforme (Linux, Windows, MacOS X) ● Construit sur la Glib (programmation OO en C, énormément de fonctions de base) ● Assez peu utilisé dans l'embarqué ● Nécessite X11 ou Wayland (pas de FB) GTK+
  26. 26. NOM CLIENT 26 La prochaine version de la norme HTML permettra de développer des applications complètement offline et non pas seulement des pages web. ● Assure une certaine « indépendance » par rapport à la plateforme ● Maquettage aisé sur desktop ● IHM déportées ● Supporté nativement par Android et iOS ● Nécessite un navigateur web récent sur la plateforme (Gecko/firefox, Blink/Chrome, Webkit/Tizen+Android) ● Équipe d'IHM avec compétence web (Javascript) ● Ne dispense pas de l'ingénieur système ● Intéressant s'il y a une connexion web ● Toutes les particularités de l'embarqué ne sont pas gérées HTML
  27. 27. NOM CLIENT 27 Android ● Android n'est pas une IHM, c'est un OS. ● Difficile à adapter à un HW spécifique, prévu pour des téléphones. ● Très bien documenté ● Beaucoup de protocoles de communication (NFC, Bluetooth, Wifi, USB) ● Compétence de développement spécifique. ● La compétence plateforme n'a rien à voir avec la compétence développement applicatif Android est surtout intéressant pour des UI déportés (sur le téléphone de l'utilisateur)
  28. 28. Questions?
  29. 29. Solutions IHM pour Linux embarqué Contact :Jérémy ROSEN - 01 42 68 28 04 - jeremy.rosen@openwide.fr
  30. 30. NOM CLIENT 2 Programme ● Présentation d'Open Wide ● IHM et embarqué : spécificités ● Les approches possibles ● Xorg, Wayland et le Framebuffer ● Les bibliothèques graphiques – DirectFB – SDL ● Les toolkits – Qt – EFL – GTK ● HMTL5 ● Android
  31. 31. NOM CLIENT 3 Présentation Open Wide ● Entreprise créée en septembre 2001 ● Environ 120 salariés sur Paris, Lyon et Toulouse ● Industrialisation de composants open source ● Quatre activités : – OW Système d'Information – OW Outsourcing: hébergement – OW Ingénierie: informatique industrielle – OW Technologies: composants Java
  32. 32. NOM CLIENT 4 IHM et embarqué ● IHM = Interface Home Machine : affichage et saisies ● Ce fut longtemps un problème mineur car peu utilisées dans l’embarqué – Système autonome sans affichage (RTOS) – Configuration par réseau (SNMP, HTTP…) ● Évolution des systèmes, passage du RTOS au multimédia – Set-top box – Smartphones – Industriel → début de l’utilisation d’Android ● L'IHM n'est (était) pas le sujet de prédilection des spécialistes du logiciel embarqué
  33. 33. NOM CLIENT 5 Particularité des IHM embarquées ● Contraintes classiques de l'embarqué – Processeur – RAM – Carte vidéo, accélération matérielle ● Contraintes sur les périphériques de sortie – Afficheur LCD – Écrans de téléphone mobile – Écrans normaux ● Saisie (et donc ergonomie) spécifique – Boutons/télécommandes/joystick/main sales – Touch-screen – Reconnaissance/saisie vocale ● Environnement de travail – Compétence des équipes – Travail déporté/sur émulateur/sans hardware Google glass (voix/écran) Smartwatch Android Wear
  34. 34. NOM CLIENT 6 Plusieurs approches ● Développement d'une application embarquée – Le cas général, proche du desktop Linux – Équipe applicatif et graphique similaire – Travail sur émulateur ou sur plateforme ● Sous-traitance de l'applicatif vers une technologie spécifique – Android/html5 – Framework très connu – Compétences faciles à trouver – Développement séparé du produit final – Ne dispense pas d'une équipe système – Pas toujours adapté aux spécificités de l'embarqué – Pas toujours adaptable aux périphériques spécifiques
  35. 35. NOM CLIENT 7 Le framebuffer 1/2 ● Pilotage de la carte directement par le noyau (/dev/fb0 → plus de client/serveur) ● Mode VGA, SVGA, VESA ou (parfois) accéléré ● Programmation très bas-niveau (pixel) $ cp /dev/fb0 copie_ecran.raw ● Avantages : – Léger (faible consommation RAM) – Démarrage rapide ● Inconvénients : – Pilote spécial → drivers/video – Peu standard par rapport à X11 sur desktop
  36. 36. NOM CLIENT 8 Le framebuffer 2/2 ● Exemples d'utilitaires/bibliothèques disponibles/compatibles – Bas niveau → fbset, fbi, fbdump, ... – SVGALIB → DOOM :-) – DirectFB (abstraction du FB) – EFL – SDL – QtEmbedded – X11 sur FB – ...
  37. 37. NOM CLIENT 9 X11, 1/2 ● Linux est un UNIX – Mode texte par défaut – « X Window System » ou X11 à partir de 84 – Xorg à partir de 2004 ● Créé au MIT ● Système graphique réparti, modèle client/serveur → XFree86 (x86), X.org ● Puissant mais lourd + API complexe (rendering) ● Approche répartie rarement utilisée Utilisation de X11 →
  38. 38. NOM CLIENT 10 X11, 2/2 ● Initialement peu adapté à l’embarqué ● Retour grâce à plusieurs éléments : – L'augmentation de la puissance des CPU embarqués – L'utilisation de l'Atom/x86 – Le pilote accéléré devient commun au desktop et à l'embarqué Qt, GTK Motif
  39. 39. NOM CLIENT 11 Wayland 1/3 ● X11 a atteint ses limites – Mauvaise intégration au kernel, drivers intégrés à X11 – Protocole réseau inutile – Protocole au niveau rendering (fonts, inputs, dessin) quasi inutilisé de nos jours – Pas de compositing, partage de GPU quasi impossible ● Wayland reconstruit sur les besoins modernes – XOrg a fait passé les drivers dans le noyau (GEM/KMS/DRM) – Wayland supporte toujours le protocole X via XWayland ● Principalement ce qu'on fait actuellement avec X11, mais sans couches intermédiaires Modifier le dernier point.
  40. 40. NOM CLIENT 12 Wayland 2/3 Protocole de communication client/compositeur ● Le client dessine dans des buffers mémoire – Demande des buffers au kernel – Utilise EGL si nécessaire – Dessine lui même les widget et les décorations (via des librairies) ● Le compositeur place les buffers à l'écran – Réécrit et redirige les inputs – Reçoit les demandes de refresh des clients – Reçoit les handles vers les buffers des clients ● Pas de fonctions desktop avancées – Drag & Drop, iconify, XDG – Délégué à des programmes tiers http://wayland.freedesktop.org/archit ecture.html
  41. 41. NOM CLIENT 13 Wayland Architecture ● Architecures comparées X/Wayland
  42. 42. NOM CLIENT 14 Wayland 3/3 ● Déjà présent dans le monde de l'embarqué – Genivi – Sailfish OS ● Demande une version adaptée des toolkits pour le client – Supporté par EFL, Gtk+3.10, Qt5, SDL (expérimental) ● Demande un compositeur – Weston – Lipstick (Sailfish OS) – Gtk, Qt, EFL : en cours d'écriture Wayland n'est pas encore mature mais ce sera sans doute la solution par défaut pour l'embarqué dans quelques années
  43. 43. NOM CLIENT 15 Bibliothèques graphiques ● Se placent « au dessus » de X11, Wayland ou du framebuffer ● Deux catégories – Les bibliothèques d'abstraction → portabilité mais pas d'objets graphiques évolués (SDL, DirectFB) – Les toolkits graphiques → fournissent des objets graphiques et peuvent se placer au dessus des bibliothèques d'abstraction Qt → X11 Qt → Wayland Qt → FB Qt → DirectFB
  44. 44. NOM CLIENT 16 ● Bibliothèque d’ « abstraction » du framebuffer ● Fonctionne avec le framebuffer Linux mais également avec X11 (--enable-x11) ● Prise en compte des entrées (souris, clavier, …) ● Fournit des pilotes FB accélérés Standard avec certains constructeurs de hardware (sigma)
  45. 45. NOM CLIENT 17 Exemple DirectFB
  46. 46. NOM CLIENT 18 Bibliothèque principalement concue pour le jeu vidéo et les besoins que cela entraîne. ● Fournit des primitives graphiques ET audio ● Portables sur Linux, Windows, Mac OS X, IOS, Android ● Pour Linux, utilisable sur framebuffer, DirectFB, X11 ● Utilisée pour le portage d’applications graphiques (jeux) et légères ● Gestion basique de l’écran: fenêtres, transparence, polices de caractères, … ● Supporte OpenGL et Direct3D ● Gestion des Input, du son, du réseau, des threads etc...
  47. 47. NOM CLIENT 19 Exemple SDL
  48. 48. NOM CLIENT 20 Les « toolkits » graphiques ● Fournissent un ensemble d’objets graphiques – Menus – Boutons – Boîtes de dialogues – WebView – Mediaplayer ● Exemples: – Athena widgets, OSF-Motif (X11) → obsolète – WxWidgets → obsolète – Qt – EFL (Enlightenment, E18) – GTK+
  49. 49. NOM CLIENT 21 ● Toolkit C++ publié par Trolltech en 1996 (X11) ● Outil multi-plateforme (Linux (X11, Wayland, DirectFB...), Windows, MacOS, Android, iOS ...) ● Connu grâce à KDE ● Dernière version: 5.3 ● Avantages : – Couvre plus que la partie graphique – Excellente documentation – Outil de conception d'interface wysiwyg (QtCreator) ● Inconvénients : – Lourd (comparé aux autres)
  50. 50. NOM CLIENT 22 Qt sur Mini2440
  51. 51. NOM CLIENT 23 EFL ● Toolkit C ● Avantages : – Peu gourmand en ressources, rapide – Taillé pour l'embarqué – Esthétique, modulaire, configurable ● Inconvénients – Peu connu – Moins de documentation que pour Qt – Pas de constructeur d'interface
  52. 52. NOM CLIENT 24 EFL au frigo
  53. 53. NOM CLIENT 25 ● Développé pour GIMP (Gimp ToolKit) ● Toolkit en C multiplateforme (Linux, Windows, MacOS X) ● Construit sur la Glib (programmation OO en C, énormément de fonctions de base) ● Assez peu utilisé dans l'embarqué ● Nécessite X11 ou Wayland (pas de FB) GTK+
  54. 54. NOM CLIENT 26 La prochaine version de la norme HTML permettra de développer des applications complètement offline et non pas seulement des pages web. ● Assure une certaine « indépendance » par rapport à la plateforme ● Maquettage aisé sur desktop ● IHM déportées ● Supporté nativement par Android et iOS ● Nécessite un navigateur web récent sur la plateforme (Gecko/firefox, Blink/Chrome, Webkit/Tizen+Android) ● Équipe d'IHM avec compétence web (Javascript) ● Ne dispense pas de l'ingénieur système ● Intéressant s'il y a une connexion web ● Toutes les particularités de l'embarqué ne sont pas gérées HTML Eco systeme brouillon
  55. 55. NOM CLIENT 27 Android ● Android n'est pas une IHM, c'est un OS. ● Difficile à adapter à un HW spécifique, prévu pour des téléphones. ● Très bien documenté ● Beaucoup de protocoles de communication (NFC, Bluetooth, Wifi, USB) ● Compétence de développement spécifique. ● La compétence plateforme n'a rien à voir avec la compétence développement applicatif Android est surtout intéressant pour des UI déportés (sur le téléphone de l'utilisateur)
  56. 56. Questions?

×