Suivez-nous sur X
|
|
|
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
|
|
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
|
|
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
|
|
A propos d'Obligement
|
|
David Brunet
|
|
|
|
En pratique : CanDo - création d'une application multimédia (première partie)
(Article écrit par Guy Beteille et extrait d'Amiga News - novembre 1993)
|
|
Bruce Lepper : voici le début d'un série pratique sur l'utilisation du logiciel CanDo. Déjà, l'année
dernière, Guy Béteille nous a présenté d'une façon assez compréhensive cette interface géniale
qui permet aux non programmeurs de créer de véritables logiciels utilisant le système Amiga. Si
nous vous proposons encore une série sur CanDo c'est parce que nous sommes convaincus de son efficacité.
Après tout, vous avez un ordinateur devant vous, n'est-ce pas ? Pourquoi demeurer toujours utilisateur
des programmes conçus par d'autres quand, avec un peu de patience, vous pouvez faire faire à votre Amiga
ce que vous voulez ?
Application multimédia
Actuellement, le multimédia s'implante sur toutes les machines qui n'étaient pas à l'origine prévues
pour exploiter des sources aussi différentes que le son, l'image, la vidéo, le texte.
L'Amiga, ordinateur multimédia par excellence, est capable, avec un minimum d'investissement
(numériseur de son, éditeur de texte, logiciel 2D ou 3D, numériseur d'image...), de générer
des images, du son, des textes, au gré de l'utilisateur. Encore faut-il disposer d'un outil
de programmation qui puisse permettre un développement rapide d'application.
CanDo est l'un de ces outils car il permet des raccourcis fabuleux en temps de développement
quel que soit le type d'application, interface utilisateur, pilotage matériel,
base de données, jeux, bornes interactives.
Dans cette nouvelle série sur CanDo nous allons aller pas à pas vers la création d'une
application complète. Le but est de permettre à un débutant de se familiariser avec la
logique de développement qu'impose CanDo et au travers de la réalisation de cette application de
trouver des solutions à des questions qui concernent d'autres applications.
Avant de programmer
Avant toute chose, il importe de passer un minimum (il vaudrait mieux un maximum) de
temps à analyser l'application que l'on souhaite réaliser. A savoir : que doit-elle
faire exactement, que pourra faire l'utilisateur, quelles ressources seront utilisées, etc. ?
Penser à ce que fera l'application c'est déjà organiser une grande partie de la programmation,
et définir ce que fera l'utilisateur c'est organiser l'interface... Et c'est déjà au niveau
de l'interface que CanDo va nous permettre de gagner du temps et surtout de faire des essais,
ajouter, déplacer et enlever boutons, menus, champs de saisie et zones texte, car à l'usage
l'utilisation donne des indications et oblige à modifier l'ergonomie...
L'interface doit toujours être pensé en fonction d'un utilisateur débutant qui ne connaît
rien de l'Amiga ou plus généralement de l'informatique. C'est l'assurance que l'application
pourra être utilisée par le plus grand nombre. Autant que possible, il faut que l'interface
soit claire, que l'on comprenne ce qu'il faut faire et qu'une assistance (par exemple sous
forme de messages) guide l'utilisateur néophyte...
Prévoir les ressources qu'utilisera l'application c'est prévoir le transport de l'application
sur un autre Amiga, ce qui suppose que l'application retrouvera seule (ou presque) les
fichiers dont elle a besoin... dans le cas du multimédia le nombre de fichiers utilisés est
généralement important ! Toujours avant de commencer l'application on peut aussi se demander
si on autorisera l'utilisateur à avoir accès à une certaine configuration de l'application.
Bien que moins indispensable cela peut s'avérer parfois très utile.
Analysons notre application
Passons à du concret. Quelle application multimédia allons-nous faire ? Tout simplement un
gestionnaire de votre collection de disques, cassettes et CD. Ce gestionnaire va
permettre d'accéder à une liste de titres (de disque, cassettes ou CD), chaque titre
pouvant être illustré par une image (une numérisation de la pochette), un extrait sonore
(numérisation d'un extrait d'une chanson) et un commentaire (sans limite de taille).
Pour être plus complet les titres pourront être consultés par genres (classique, rock, reggae, etc.).
Cette application devra être capable de gérer des listes de titres, d'afficher des images et
des textes, de jouer des sons. Au niveau des titres, elle devra permettre d'en ajouter et
d'en supprimer.
Le départ de la programmation sera la liste des genres. Lorsqu'un genre sera sélectionné on
accèdera à une liste de titres, et lorsqu'un titre sera sélectionné on pourra voir l'image
l'illustrant ou écouter un extrait sonore (ou faire les deux simultanément).
Comme il s'agit d'une base de données, on pourrait décider d'utiliser les commandes
CanDo spécifiques à ce genre d'applications, mais pour un débutant cela complique un peu la
partie programmation. A la place, on peut envisager de gérer les listes sous forme de fichiers
texte classique (en ASCII) ce qui aura l'avantage d'autoriser l'édition des listes par tout
éditeur de texte et donc de régler pour l'instant la question de l'édition de notre base.
Mais nous y reviendrons...
Le reste (voir une image, écouter un son) demandera peu de programmation.
Pour l'interface, nous aurons besoin de deux cartes, une carte "principale" ayant
les objets suivants :
- Un menu, pour quitter (ou un bouton si on préfère).
- Deux objets "listes" un pour les genres, l'autre pour les titres.
- Un objet "memo" pour les commentaires.
- Trois boutons, un pour voir, un autre pour écouter et un pour les deux simultanément.
- Une carte pour visualiser les images ayant pour objets : un bouton, pour arrêter
l'affiche d'une image.
Pour les ressources, nous pouvons déjà prévoir que nous utiliserons des brosses pour
illustrer les boutons, des fichiers textes pour les listes. Ces brosses et fichiers
devront être facilement localisables.
Le mieux est de créer un tiroir où résideront l'application et les fichiers qui lui
sont nécessaires. Ici créons le tiroir "Discothèque". L'application se chargera de
créer une assignation qui lui sera propre et qui évitera les problèmes en cas de changement
de nom du tiroir ou de transport.
Commençons...
L'élément de base d'une application c'est la carte. Qui dit carte dit écran-fenêtre.
Chaque carte possède une seule fenêtre (ou écran). La première chose à créer quelle que soit
l'application est bien évidemment l'aspect de l'écran et de la fenêtre. Il suffit donc
d'appeler l'éditeur de fenêtre et de définir les dimensions de la fenêtre, c'est assez simple.
Dans notre application nous choisirons (provisoirement) une dimension de 640x256 avec 8 couleurs.
Nous ne mettrons aucun titre à cette fenêtre.
Les options (figure suivante) demandent un peu plus de réflexion car elles déterminent la
localisation de la fenêtre par rapport à un écran (écran propre, écran du Workbench,
écran d'une autre application).
Dans une application qui va utiliser des brosses dans son interface, le mieux est d'ouvrir
un écran à part et de ne pas utiliser celui du Workbench (sauf si vous êtes limité en mémoire).
Sinon vous risquez d'avoir certains problèmes faute de pouvoir imposer la palette et le
nombre de couleurs. Choisissez le mode "backdrop" qui confond écran et fenêtre et ne mettez
pas de bordure.
Maintenant que la fenêtre est créée, passons à l'éditeur de carte et commençons à programmer...
Pour l'instant, notre application ne fait qu'ouvrir un écran vide et rien
d'autre, habillons un peu cet écran avec une barre titre ce qui nous amène à éditer le script
"AfterAttachment". C'est le script qui est exécuté dès que la fenêtre a été ouverte, c'est
là que doivent se trouver toutes les instructions qui seront exécutées avant que l'utilisateur
n'intervienne. Une fois ce script exécuté, l'application attendra un événement :
choix d'un menu, clic sur un bouton... Notre AfterAttachment sera :
ScreenTitleBar ON ; barre titre de l'écran visible (On)
SetScreenTitle "Discothèque" ; titre de l'écran, et de notre application !
|
Mais l'application peut déjà effectuer certaines tâches avant l'ouverture de la fenêtre,
ceci par l'intermédiaire du script "BeforeAttachment" qui sera exécuté avant l'ouverture
de la fenêtre et donc avant le script "AfterAttachment". Dans ce script il faut ne jamais
mettre de commandes qui demandent l'existence d'une fenêtre, par exemple en changer le titre,
dessiner... Nous allons utiliser ce script pour faire créer à notre application une assignation,
ici "Discothèque:", qui correspondra au tiroir d'où elle est lancée.
Si l'application se trouve en "DH0:decks/discothèque/" c'est à ce chemin que correspondra
l'assignation "Discothèque" ! L'énorme avantage de créer cette assignation à cet endroit-là
c'est de permettre à l'application d'avoir un repère sûr, de pouvoir trouver les fichiers
dont elle a besoin, et plus spécialement les futures brosses de nos boutons.
Il nous suffit d'utiliser cette assignation lors de l'utilisation de ces fichiers.
Notre BeforeDetachment sera :
Dos "Assign >NIL: Discothèque:" ||Char(34)||TheCurrentDirectory||Char(34)
; créer l'assignation "Discothèque:"
|
Le nom du tiroir d'où est lancée l'application est donné par la variable système
"TheCurrenDirectory". Aussi, "Char(34)" place des guillemets et la commande "Dos"
exécute la ligne comme s'il s'agissait d'une commande AmigaDOS lancée d'une fenêtre Shell.
Il reste une chose importante à faire... pouvoir quitter l'application.
Pour ce faire, éditer un menu "Projet", ajouter l'item "Quitter" ayant comme script
la commande "Quit".
Désormais, vous êtes prêts à passer à la construction de l'interface, listes et boutons...
Ce que nous ferons le mois prochain.
|
