Obligement - L'Amiga au maximum

Mardi 19 mars 2024 - 10:21  

Translate

En De Nl Nl
Es Pt It Nl


Rubriques

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

Articles in english


Réseaux sociaux

Suivez-nous sur X




Liste des 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,
ALL


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


Galeries

Menu des galeries

BD d'Amiga Spécial
Caricatures Dudai
Caricatures Jet d'ail
Diagrammes de Jay Miner
Images insolites
Fin de jeux (de A à E)
Fin de Jeux (de F à O)
Fin de jeux (de P à Z)
Galerie de Mike Dafunk
Logos d'Obligement
Pubs pour matériels
Systèmes d'exploitation
Trombinoscope Alchimie 7
Vidéos


Téléchargement

Documents
Jeux
Logiciels
Magazines
Divers


Liens

Associations
Jeux
Logiciels
Matériel
Magazines et médias
Pages personnelles
Réparateurs
Revendeurs
Scène démo
Sites de téléchargement
Divers


Partenaires

Annuaire Amiga

Amedia Computer

Relec


A Propos

A propos d'Obligement

A Propos


Contact

David Brunet

Courriel

 


Programmation : Présentation de MUI
(Article écrit par Mathias Parnaudeau - juillet 2004)


Chapitre 0

Depuis une dizaine d'années, MUI s'est imposé comme un système de gestion d'interfaces utilisateur incontournable. A l'heure actuelle, son essor continue après une trop longue période de stagnation et les nouveaux systèmes bénéficient d'une version 3.9 depuis 2003. MUI est géré par AmigaOS 4 et carrément intégré dans MorphOS ; quant à AROS, il bénéficie d'une implémentation appelée Zune.

Pour vous accompagner dans l'apprentissage de MUI, nous vous proposons ici une suite de chapitres classés par difficulté croissante. Ce sujet s'est avéré être le plus attendu des programmeurs débutants qui vont enfin pouvoir s'y mettre.

La lecture de la documentation MUI dédiée aux développeurs reste bien sûr indispensable, tout comme les autodocs pour le détail de chaque classe de composant (le terme classe est choisi car MUI présente une conception orientée objet, des notions sur le sujet sont plus que conseillées !). Des exemples sont également présents dans le kit de développement mais le plus simple d'entre eux est déjà consistant.

Afin de rendre les exercices de ce cours plus concrets, ils sont destinés à illustrer l'évolution d'un véritable projet, à savoir un lecteur de CD audio. Il restera simple dans ses fonctionnalités pour ne pas se détourner de l'objectif principal, à savoir l'apprentissage de MUI.

Définition, généralités

MUI (Magic User Interface) est développé par Stefan Stuntz et apparaît au début des années 1990. Sa conception et ses capacités d'évolution ont permis à MUI de toujours être incontournable en 2004. Ce puissant système de création d'interfaces graphiques s'est en effet imposé au fil des années, notamment devant ReAction et UIK.

Au niveau de ses possibilités, MUI bénéficie comme Java d'un calcul de disposition ("layout") automatique, c'est-à-dire que la gestion de la position et de la taille des composants est déléguée au moteur de MUI, le programmeur n'a pas à s'en soucier. La conception de MUI a également joué en sa faveur, tout comme sa simplicité de programmation, basée sur des macros C. Et la personnalisation des applications MUI peut atteindre un niveau très poussé dont les limites ont encore été reculées dans sa version 3.9.

Techniquement, MUI repose sur des principes de programmation objet, il étend d'ailleurs BOOPSI, le principe orienté objet d'AmigaOS. On viendra donc à parler de classes MUI que l'on peut distinguer en trois catégories :
  • Les classes "builtin" qui sont au coeur de MUI et font partie intégrante de sa distribution.
  • Les classes externes, les fameux fichiers à l'extension MCC (MUI Custom Class) écrits par des développeurs tiers et mis à disposition de la communauté.
  • Les classes internes à un programme, ou classes privées, qui ne sont pas accessibles par d'autres applications au niveau du système d'exploitation mais dérivent tout de même une classe existante.
Notion d'héritage

Nous venons de présenter les types de classes sur lesquelles MUI est fondé. L'arborescence des composants de type builtin, sur lesquels s'attarder en premier, est présentée dans la documentation mais aussi dans le fichier "libraries/mui.h" dont la lecture est toujours utile (pour les constantes, macros...). On y apprend par exemple que les classes "Text" ou "Image" sont dérivées de la classe de base "Area" qui représente une zone rectangulaire, ce qui est logique. Mais plus surprenant, on découvre qu'il n'y a pas de classe "Button" ! Pour MUI, ce qui fait un bouton est avant tout sa représentation, c'est-à-dire qu'un bouton est une chaîne ou une image avec une visualisation en relief (appelée cadre sous MUI)... mais nous verrons cela rapidement.

Fidèles à leur orientation objet, les classes ont naturellement toutes les caractéristiques que l'on peut retrouver dans des classes des langages C++ ou Java. Pour connaître la nature d'un élément MUI, des préfixes adaptés sont utilisés :
  • MUIC_ pour une classe.
  • MUIM_ pour une méthode, c'est-à-dire une fonction.
  • MUIA_ pour un attribut (membre privé, c'est-à-dire variable interne à la classe).
  • MUIV_ pour une valeur spécifique à un attribut.
Ainsi, chaque classe MUI dispose de ses propriétés et méthodes, y compris son constructeur (méthode particulière qui sert à créer un nouvel objet) et son destructeur (qui supprime et libère ses ressources). Si le vocabulaire ne vous est pas familier, je vous renvoie aux articles qui expliquent les principes de la programmation objet.

La création d'une classe dérivée d'une autre permet donc d'écrire de nouvelles méthodes pour enrichir un composant existant mais aussi de compléter l'action des méthodes héritées (par surcharge et appel de la méthode de la classe mère).

Description de l'interface

Une interface MUI est entièrement composée d'objets, à commencer par l'Application qui est obligatoire et sur lequel se greffe un objet "Window" correspondant à la fenêtre principale. Chaque fenêtre est avant tout constituée d'un groupe obligatoire, dans lequel on va organiser les composants graphiques. Lors de la conception d'une interface, il faut donc la dessiner sur papier (ou dans sa tête) et dégager les zones principales qui vont devenir des groupes MUI. Puis on descend dans le détail et pour chaque groupe, on exprime ce qu'il contient (composants ou groupes internes). Et représentant cette organisation sous forme d'un arbre, on obtient le code de base de l'interface :
 Application

        Window

                Group

                        Object

                        Object

                        Group

                                Object

                                Object

                                Object
Cette écriture symbolique pourrait convenir pour une interface qui présenterait deux chaînes de caractères (par exemple) l'une sur l'autre, avec en dessous une zone contenant trois boutons sur une même ligne. Il suffit de préciser que le deuxième groupe est de type horizontal : ses objets seront alors disposés horizontalement de gauche à droite.

Au niveau des composants, chacun d'entre eux appartient forcément à un groupe et est donc présenté comme enfant (Child) que l'on ajoute comme un jeu de construction. Lors de cette description d'interface, on peut attribuer des valeurs par défauts aux propriétés de cet objet (souvenez-vous des attributs notés MUIA_NomClasse_NomAttribut), comme le texte dans un composant "String". Un composant est donc annoncé par "Child, " et sa description se termine par "End,". Le mot-clé "End" est suivi d'un point-virgule et non d'une virgule uniquement pour terminer la description d'un ensemble d'objets.

La description d'une interface est très logique et utilise des macros pour mettre l'accent sur l'architecture et pas sur le langage de programmation. Normalement, il n'y a aucune difficulté pour passer du dessin papier au code source équivalent. Il faut toutefois être vigilant sur l'encapsulation des objets par Child/End et sur la présence des virgules associées.

Prérequis pour la suite

Avant de commencer à programmer réellement, il est nécessaire de réunir certains éléments. Vous devez donc avoir :
  • Un environnement de développement fonctionnel : un éditeur, un compilateur C ainsi que les bibliothèques et includes MUI (mui38dev.lha pour AmigaOS et le SDK correctement installé pour MorphOS).
  • Éventuellement d'autres ressources mais elles ne se prêtent pas forcément au débutant : l'archive Calculator sur MDC (fournit des exemples), MUIUndoc, S3DC sur Aminet (exemple de création de classe)...
Ici, désormais, on connaît MUI dans les grandes lignes et tous les éléments permettant de programmer avec sont installés. Pour en être sûr, compilez un ou des exemples du SDK même si vous n'en comprenez pas le contenu.


[Retour en haut] / [Retour aux articles] [Article suivant]