 |
Vendredi 06 juin 2025 - 12:49 |
| Translate |
|
| Rubriques |
| Réseaux sociaux |
|
| Liste des jeux Amiga |
|
| Trucs et astuces |
|
| Glossaire |
|
| Galeries |
|
| Téléchargement |
|
| Liens |
|
| Partenaires |
|
| A Propos |
|
| Contact |
|
|
|
L'interface graphique fait le lien entre utilisateur, les ressources du matériel graphique et le système d'exploitation. Elle comprend plusieurs aspects qu'il faut bien distinguer : l'interface graphique proprement dite, Intuition, est responsable de la gestion des écrans, des fenêtres, des menus, des gadgets et de leur mise à disposition pour les applications. Pour la clarté du propos, rappelons que l'Amiga permet de créer plusieurs écrans indépendants les uns des autres, partiellement superposés et librement déplaçables, de résolution indépendante.
Pour faire son travail, elle s'appuie sur des bibliothèques spécialisées, notamment la graphics.library, pour les manipulations graphiques eux-mêmes, et l'input.device pour toutes les entrées (souris, clavier...). Elle exploite aussi abondamment le noyau Exec pour communiquer avec ses applications "clientes".
La graphics.library s'appuie elle-même sur les ressources matérielles. Le Workbench permet à l'utilisateur de piloter AmigaOS de façon intuitive au moyen d'icônes représentant les disques, les fichiers et les répertoires, de fenêtres regroupant le contenu de ces répertoires et de menus pour les opérations plus complexes... On peut schématiser l'ensemble du système par des "couches" logicielles offrant des services à bas, moyen puis haut niveaux.
Le système
Explorons systématiquement ce schéma de bas en haut.
- Le matériel a déjà été décrit en détail dans cet article.
- Le noyau du système, Exec, discret mais omniprésent, assure la coexistence des tâches et l'intercommunication. Il a été abordé dans cet article.
- Elle est chargée d'interfacer les circuits graphiques et le système.
- Elle prend en charge les opérations de bas niveau à savoir les primitives de base pour le dessin, la gestion du texte et des polices, la résolution graphique et la gestion des couleurs.
- Elle gère aussi les BOB (Blitter Objects), Sprites et VSprites (Virtual Sprites).
- On dispose également d'une prise en charge d'objets graphiques animés que le système gère au-delà du simple affichage (contrôle de la vitesse, de l'accélération, modification de forme, collisions...).
Par contre, il y a du matériel sous-jacent : le Blitter est largement mis à contribution, la mise en place et la modification des écrans et fenêtres passent par la programmation du Copper par la graphics.library. Cela confère de la vitesse : un objet simple en fil de fer ou en faces pleines demande le même temps processeur (tant qu'on ne sature pas les circuits spécialisés). On peut accumuler les défilements, les animations d'objets sont possibles, les écrans se meuvent en temps réel.
La layers.library
- Elle gère des entités appelées "layers" (zone d'affichage, liée à chaque fenêtre), composées de régions, listes de rectangles dans lesquelles les sorties graphiques sont "clippées" (on ne dessine pas en dehors).
- La bibliothèque prend en charge le rafraîchissement (restauration) de ces rectangles en cas d'écrasement, et reconnaît la notion de profondeur (un rectangle est devant ou derrière un autre).
Pour plus de souplesse, quatre modes de rafraîchissement sont disponibles au programmeur :
- Simple refresh : aucun rafraîchissement n'est effectué par le système. Soit le contenu est réellement perdu, soit le programme souhaite être simplement averti de l'écrasement pour procéder par ses propres moyens au retraçage de la zone perdue.
- Other refresh : on indique au système la routine de retraçage à appeler en cas de dérecouvrement.
- Smart refresh : une liste des rectangles écrasés est maintenue, et ces rectangles sont automatiquement rafraîchis lorsqu'ils réapparaissent sans que le programme n'ait rien remarqué.
- Super refresh : la fenêtre dispose de sa propre zone de mémoire (éventuellement plus grande que la partie affichée), à partir de laquelle le système retrouve les informations à afficher.
La bibliothèque n'est pas pour autant systématiquement au dessus de la graphics.library : le tracé des dessins se fait en coopération. Cela se traduit au niveau des structures de données par un graphe compliqué de pointeurs liant les deux entités (voir plus bas).
L'input.device
Bien qu'il soit représenté par une petite case sur le schéma, c'est l'une des plus belles parties d'AmigaOS et il y joue lui aussi un rôle capital : c'est lui qui collecte et redistribue les événements matériels (clics et mouvements de souris, touches du clavier, horloge, insertion d'une disquette) avec une particulière souplesse. Il supervise ainsi lui-même les différents périphériques logiques (périphériques logiciels) attachés chacun à un aspect donné du matériel.
Mais il gère également les événements logiciels (déplacement ou recouvrement de fenêtre, activation d'une icône ou d'un gadget, choix d'un item de menu...) : si l'on peut "recevoir" les événements, on peut également en "poster" et comme l'attestent les exemples donnés ici, Intuition ne s'en prive pas.
La programmation par événements est maintenant à la base de la plupart des interfaces graphiques plus connues (X Window, Windows, celle de Mac OS) : un programme s'articule désormais autour d'une boucle interactive, où il attend que le système l'avertisse d'un événement le concernant. Puis il appelle la fonctionnalité adéquate. A un certain niveau, cette boucle peut même être implicite, et c'est le système qui activera de lui-même la fonction attachée à un événement, en lui fournissant les paramètres appropriés.
En ce qui concerne l'Amiga, l'input.device se charge également d'appeler la graphics.library et la layers.library pour afficher les objets intuitions, affichage qui est donc indépendant de la tâche appelante. Sa présence simplifie d'autant la structure logicielle d'intuition.library.
L'intuition.library
Intuition.library est l'interface logicielle qui crée un environnement cohérent à partir des diverses ressources logicielles et matérielles : elle gère des objets synthétiques et intuitifs (écrans, fenêtres, menus, gadgets) qui s'appuient sur les objets de base du système (Viewport, layers, événements matériels).
Trois structures arborescentes organisant l'affichage sont donc mêlées :
- Celle du View (ce qui est affiché), regroupant plusieurs ViewPorts (zones indépendantes en résolution, position, nombre de couleurs), qui contiennent eux-mêmes une ColorMap (palette) et une bitmap (plans de mémoire graphique).
Comme nous l'avons vu dans le chapitre sur les circuits graphiques, à un View est associé une liste Copper, programme du Copper lui permettant de piloter le matériel pour afficher le View correspondant.
- Celle des layers, qui regroupent les zones d'affichages correspondant d'une part aux morceaux visibles des diverses fenêtres afin d'y limiter les dessins sans crayonner sur le voisin, et d'autre part aux morceaux cachés afin de pouvoir les restaurer en temps utile.
- Celle des écrans, qui contiennent plusieurs fenêtres, celles-ci étant elles-mêmes associées à des listes de gadgets, de menus, de requêtes, et à un contexte graphique (modes de tracés courants, position, polices...). Dans cette structure prennent également place diverses autres allocations, dont la liste des Graphics ELements (BOB, Sprites).
Les Viewports correspondent aux parties visibles des écrans ; Intuition en limite l'usage à des tranches horizontales, ce qui garantit que la résolution ne change pas sur une ligne (si l'on passe par Intuition). Les divers écrans peuvent donc glisser verticalement les uns par rapport aux autres quand on en saisit un à la souris, et glisser sur eux-mêmes horizontalement tant que cela ne fait pas apparaître l'arrière-plan sur les côtés.
Intuition fait reconstruire les listes Copper par la graphics.library à chaque modification de la disposition de l'affichage, en fusionnant des listes Copper partielles par écran/viewport (cela permet au programmeur désirant sortir localement du cadre strict de se raccrocher partiellement au système. Comme les diverses couches logicielles sont toutes accessibles, cela permet à loisir de personnaliser certains aspects sans perdre la cohérence du tout).
Les fenêtres sont essentiellement des layers un peu habillés et munis d'un port de message (voir cet article) au travers duquel l'application recevra les événements qui la concerne, auquel le programme souscrit : lorsqu'on ouvre une fenêtre sous Intuition, outre ses caractéristiques classiques (dimension, position, écran...) il faut spécifier ses propriétés et les événements auxquels on désire qu'elle soit sensible, au moyen d'un masque.
Les propriétés permettent à Intuition de définir l'aspect (gadgets standard) et de gérer à notre place les actions courantes (redimensionnement, rafraîchissement, détourage). Voici la liste des propriétés, que nous n'avons pas la place de détailler ici mais qui dans l'ensemble parle d'elles-mêmes :
WindowSizing, WindowDrag, WindowDepth, WindowClose, SizeBright, SizeBottom, RefreshBits, SmartRefresh, SimpleRefresh, OtherRefresh, SuperBitmap, BackDrop, ReportMouse, GimmeZeroZero, BorderLess, Activate, WindowActive, InRequest, MenuState, RmbTrap, NoCareRefresh, WindowRefresh, WBenchWindow, WindowTicked, (Super Unused).
Drags est le déplacement de la fenêtre, GZZ installe une zone de détourage laissant une marge pour Intuition aux bords. BackDrop désigne une fenêtre de "fond de panier" derrière toutes les autres.
Les événements que l'on déclare seront signalés par envoi de messages de la part d'Intuition via le port de communication de la fenêtre, le masque fourni à l'ouverture regroupant des drapeaux appelés "IDCMP" pour Intuition Direct Communication Message Port. En voici la liste :
SizeVerify, NewSize, RefreshWindow, MouseButtons, MouseMove, GadgetLip, GadgetDown, ReqSet, MenuPick, CloseWindow, RawKey, ReqVerify, ReqClear, MenuVerify, NewPrefs, DiskInserted, DiskRemoved, WBenchMessage, ActivateWindow, InactiveWindow, DeltaMove, VanillaKey, IntuiTicks, LonelyMessage, MenuHot, MenuCancel, MenuWaiting, OkOk, OkAbort, OkCancel, WBenchOpen, WBenchClose.
Les "Ok" se réfèrent aux requêtes, les intuiTicks peuvent tenir lieu d'horloge. Notez la possibilité d'être prévenu d'un changement dans les préférences du Workbench.
Tout ceci concerne la version 1.3 du système, de nombreuses extensions et améliorations ayant été apportées avec la version 2.0 (voir plus bas).
Les fenêtres peuvent être munies de "gadgets" systèmes, motifs graphiques manipulables avec la souris qui correspondent à des propriétés fondamentales :
- Redimensionnement, déplacement, fermeture et mise en avant/arrière-plan.
Jusqu'au système 1.3, les différents types de gadgets étaient :
- Gadget booléen (bouton pression ou interrupteur).
- Gadget proportionnel (ascenseur, curseur, pouvant avoir un ou deux degrés de liberté).
- Gadget de chaîne (numérique ou alphanumérique).
Les menus sont constitués de façon arborescente par des MenuItems, et sont disponibles quand la fenêtre est active. On peut y attacher des raccourcis clavier, y mettre un label ou une image, spécifier la disposition, associer un bouton on/off, dont on peut décrire les incompatibilités entre Items, etc.
Les gadgets et les menus sont contenus dans deux listes attachées à la fenêtre. Si leurs aspects, leurs comportements et leurs structures diffèrent, dans le principe, les deux entités sont très similaires. Intuition prend en charge la gestion et envoie au programme "abonné" le résultat des manipulations par le biais d'un message.
Le Workbench
C'est une application à part entière (et non une composante du système), que l'on peut à la rigueur supprimer ou remplacer. Au démarrage elle ouvre le premier écran et s'installe dans une fenêtre "backdrop" qui en couvre le fond (en 1.3).
Elle y place un certain nombre d'icônes représentant périphériques logiques, répertoires, applications, fichiers, qui peuvent êtres sélectionnés d'un clic ou activés d'un double-clic. Selon leur type, l'activation conduit à ouvrir un répertoire (ouverture d'une fenêtre et affichage des icônes du contenu), exécuter une application ou appeler un outil par défaut lié à un fichier de donnée.
Les icônes sont donc des gadgets booléens, munis d'une structure permettant leur paramétrage (type, taille de pile, outil à utiliser, arguments). La majeure partie reposant sur Intuition, le principal travail du Workbench consiste à déplacer les icônes lorsqu'ils doivent suivre la souris, et rafraîchir les fenêtres d'icônes.
Extensions
La grande commodité d'Intuition fait qu'un bon nombre d'outils d'extension ont été programmés et placés dans le domaine public : ajout d'items dans les menus du Workbench, menus en "PopUp" ou attachés à la barre de titre de chaque fenêtre, iconificafion, Workbench plus grand que l'écran (avec défilement quand la souris butte contre le bord), souris à déplacements non linéaires, copier-coller par caractères ou graphique, autres aspects de fenêtres, surcouches pour programmer l'interface graphique...
La liste des logiciels en domaine public est impressionnante et comporte nombre de réalisations de qualité, et nombre d'exemples de programmation. Beaucoup de ces outils ont été intégrés dans la version 2.0, dont la nouveauté explique nos connaissances encore restreintes en la matière, et par conséquent la référence majoritaire au 1.3 dans ce propos.
Les améliorations d'AmigaOS 2.0
Les améliorations d'AmigaOS 2.0 en matière d'interface graphique concernent notamment :
1. Le matériel, avec de nouveaux modes graphiques (résolution jusqu'à 1280x512) et la mémoire Chip portée à 2 Mo.
2. Le système d'exploitation, qui gère la notification (pour prévenir de la modification d'un fichier les applications qui le souhaitent), les "locks" (verrous) sur des parties de fichiers, les liens, les assignations logiques regroupant plusieurs répertoires et intègre ARexx et IFF, etc.
3. La graphics.library, avec l'ajout de nouvelles fonctions, la gestion des nouveaux modes et le support direct de différents moniteurs (l'examen des structures laisse à penser que la gestion de cartes graphiques est possible au moins à ce niveau), la gestion de polices vectorielles...
4. Intuition, avec une extension considérable des possibilités concernant les gadgets (il est possible de définir totalement un gadget et son comportement), de nombreux "hooks" dans les structures générales (indirections qui permettent d'aiguiller vers d'autres comportements dans certaines circonstances), mécanisme de passage des paramètres par "tags" (on ne définit que les paramètres jugés nécessaires, ce qui assouplit grandement l'utilisation des objets d'Intuition en évitant d'avoir à remplir d'interminables structures, et il existe des valeurs par défaut), liberté accrue de mouvement des écrans, etc.
5. Le Workbench, avec de nouveaux outils et une paramétrisation systématique (décors de fond de fenêtres, polices, résolution et dimensions de l'écran (qui peut être plus grand que le moniteur), séparation des diverses préférences, fichier regroupant tous les messages), sélection par lasso, copier-coller depuis le Shell, texte des fenêtres Shell sauvegardé, choix de présentation des contenus de répertoire, l'interaction avec les applications est accrue (introduction des AppWindows, fenêtres possédant une zone active sur laquelle on peut déposer une icône, les AppMenus permettent d'ajouter des items, les écrans publics acceptent la visite de fenêtres étrangères)...
Il resterait encore à incorporer une intégration réseau (voir X Window et Mac OS 7) permettant d'accéder aux ressources d'autres machines (certains DP comme ParNet le font à une échelle modeste) et à gérer (par graphics.library et Intuition) les cartes graphiques et processeurs graphiques externes...
|
