Obligement - L'Amiga au maximum

Mercredi 22 novembre 2017 - 23:07  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

 · Accueil
 · A Propos
 · Articles
 · Galeries
 · Glossaire
 · Hit Parade
 · Liens
 · Liste jeux Amiga
 · Quizz
 · Téléchargements
 · Trucs et astuces


Articles

 · Actualité (récente)
 · Actualité (archive)
 · Comparatifs
 · Dossiers
 · Entrevues
 · Matériel (tests)
 · Matériel (bidouilles)
 · Points de vue
 · En pratique
 · Programmation
 · Reportages
 · Tests de jeux
 · Tests de logiciels
 · Tests de compilations
 · Articles divers

 · Articles in english
 · Articles in other languages


Twitter

Suivez-nous sur Twitter




Liens

 · Sites de téléchargements
 · Associations
 · Pages Personnelles
 · Moteurs de recherche
 · Pages de liens
 · Constructeurs matériels
 · Matériel
 · Autres sites de matériel
 · Réparateurs
 · Revendeurs
 · Presse et médias
 · Programmation
 · Développeurs logiciels
 · Logiciels
 · Développeurs de jeux
 · Jeux
 · Autres sites de jeux
 · Scène démo
 · Divers
 · Informatique générale


Jeux Amiga

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Trucs et astuces

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Glossaire

0, A, B, C, D, E, F,
G, H, I, J, K, L, M,
N, O, P, Q, R, S, T,
U, V, W, X, Y, Z


Partenaires

Annuaire Amiga

Amedia Computer

Relec

Hit Parade


Contact

David Brunet

Courriel

 


Dossier : Intuition et l'interface graphique Amiga
(Article écrit par Fabrice Neyret et Emmanuel Buu et extrait d'Amiga News - mars 1992)


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.

schéma AmigaOS

  • 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.
La graphics.library
  • 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 Bobs (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...).
Il n'est pas question de développer ici toutes les opérations graphiques disponibles. Un peu comme sous X Window, on dispose de contextes graphiques (couleurs, motifs, plans de bits visés, point courant, police, styles d'écriture...) et d'une certaine redondance dans les fonctions pour mieux s'adapter aux besoins (remplissage par inondation ou polygones pleins, vecteurs à l'unité ou en série...).

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).
Ces layers sont automatiquement associés aux fenêtres par Intuition, de façon à désigner les portions de fenêtres visibles et celles qui sont masquées et qu'il faudra remettre en place si elles doivent revenir à l'avant-plan (en général, les fenêtres d'un même écran partagent la même mémoire graphique. Le contenu est donc bien perdu en cas de superposition, et c'est le travail du système de faire en sorte que l'affichage se comporte conformément à Intuition, et que les parties masquées réapparaissent...).

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 layers.library utilise les fonctions de manipulation du Blitter fournies par la graphics.library, ce qui lui permet de remettre en place les fenêtres quasi instantanément. Elle possède un mécanisme de synchronisation pour assurer des accès aux layers sans collisions dans le contexte multitâche.

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 devices (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).
Notons que plusieurs Views peuvent êtres présents en mémoire même si un seul est affiché. Cela permet notamment de réaliser l'entrelacement vidéo en affectant deux Views différents aux trames paires et impaires, que l'on désigne alternativement comme étant "le" View.

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 (Bobs, Sprites).
La dernière structure, celle d'Intuition, comporte de nombreux branchements sur les deux précédentes (appartenant à la graphies et la layers.library), afin de rendre les fenêtres utilisables par la graphics.library.

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 standards) 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.
Le programmeur peut ajouter ses propres gadgets qui seront alors pris en charge par Intuition et donneront lieu comme les autres à des événements. Ils servent généralement soit à habiller les bords de la fenêtre d'outils supplémentaires (défilement, iconification), soit à constituer des pages de saisie avec boîtes de dialogue.

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).
Chaque gadget peut être muni de propriétés et de motifs graphiques qui permettent de lui donner un aspect et un comportement personnalisés.

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 devices, 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...


[Retour en haut] / [Retour aux articles]