Obligement - L'Amiga au maximum

Mardi 17 octobre 2017 - 01:57  

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

 


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 "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]