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
|
|
|
|
Programmation : C - AppIcons, AppWindows et AppMenuItems
(Article écrit par Olivier Jeannet et extrait d'Amiga News - juillet 1994)
|
|
Le système 2.0, grâce à la workbench.library, ne limite plus l'usage des icônes aux
seules fenêtres du Workbench. Par exemple, un programme peut ouvrir une fenêtre,
et être informé si on lâche des icônes dessus.
La workbench.library, créée avec le système 2.0, a apporté trois objets supplémentaires :
l'AppIcon, l'AppWindow et l'AppMenuItem. Le "app" signifie application. Avec le système 1.3,
on ne pouvait lâcher des icônes que sur les fenêtres du Workbench, c'est-à-dire les fenêtres
correspondant aux répertoires ouverts. Si on lâchait des icônes sur des fenêtres autres que
le Workbench, on avait droit à un flash d'écran et un message d'erreur. On ne pouvait utiliser
les icônes que pour déplacer des fichiers ou lancer des applications.
Grâce à la workbench.library,
le 2.0 (et les systèmes ultérieurs bien sûr) permet d'avoir une certaine interaction entre
le Workbench et les applications. On peut, par exemple, lâcher une icône sur une fenêtre
non-Workbench, si cette fenêtre est une AppWindow. Le programme qui gère la fenêtre en
sera informé et pourra obtenir toutes les informations liées à l'icône : son nom, son
répertoire, son outil par défaut, etc.
Pour donner rapidement une idée de ce qu'apporte cette nouvelle bibliothèque,
nous allons prendre un bon exemple de programme qui utilise la workbench.library :
le programme ToolManager, qui est DP (disponible dans la collection Fish)
et livré avec ses sources. Celui-ci utilise en effet les trois objets mentionnés plus
haut. Une proportion notable des utilisateurs du 2.0 qui ont essayé ToolManager l'ont
probablement adopté, car il est pratique. De plus, c'est une commodité : on le met dans
le tiroir WBStartup pour qu'il soit lancé au démarrage, et on peut l'appeler avec le
programme Exchange.
Nous allons nous étendre ici sur la version 1.5, qui semble plus simple à configurer que
les versions ultérieures.
Quand on lance ToolManager, deux modifications apparaissent d'emblée sur le Workbench :
une nouvelle icône dans la fenêtre principale (celle qui contient les icônes des disques),
et une entrée supplémentaire (item) dans le menu "Outils" ("Tools" pour ceux qui sont restés
en anglais), intitulée "Quit ToolManager". Le but de ToolManager est d'ajouter des
entrées dans le menu Tool (?) du Workbench, pour pemettre un lancement rapide d'applications.
On peut ainsi y mettre ses programmes favoris (PPMore, Az, Deluxe Paint, etc.)
et les lancer en sélectionnant tout simplement le menu correspondant. Cela évite par
exemple de devoir ouvrir des (sous) répertoires pour aller double-cliquer sur le programme.
Il y a mieux : avant de sélectionner le menu, en peut sélectionner des icônes, et le
programme sera lancé avec ces icônes comme arguments. On peut ainsi cliquer sur un fichier
texte et lancer son lecteur préféré avec le menu, au lieu d'utiliser celui indiqué dans
l'outil par défaut de l'icône. Cette première caractéristique de ToolManager correspond à
la notion d'AppMenuItem.
Deuxième caractéristique : l'icône apparue dans la fenêtre principale est particulière,
et ce pour trois raisons. Tout d'abord, si on demande l'information sur cette icône
(menu du Workbench Icône/Info), le Workbench affiche : "information manquante".
Ensuite, en double-cliquant sur l'icône, on obtient la fenêtre de ToolManager :
c'est une façon supplémentaire d'obtenir la fenêtre, en plus du raccourci clavier
du programme et l'option "Montrer" du programme Exchange.
Enfin, en lâchant l'icône d'un programme sur cette icône, le nom de l'icône lâchée
vient s'ajouter dans le menu "Outils" du Workbench : si on ouvre la fenêtre
de ToolManager, le nom a également été rajouté dans la liste. Cette deuxième caractéristique
de ToolManager correspond à la notion d'AppIcon : l'icône apparue est une AppIcon,
elle ne correspond à aucun fichier existant.
La troisième notion, l'AppWindow, est utilisée par la fenêtre de ToolManager.
Le fait de lâcher des icônes sur la fenêtre de ToolManager a le même effet que
de les lâcher sur l'icône (l'AppIcon, pour être exact) de ToolManager. La méthode
est pratique : il suffit d'aller cliquer sur l'icône du programme à ajouter à
la liste et de la lâcher sur la fenêtre de ToolManager, au lieu de devoir rentrer
le chemin et le nom associés au programme.
Le fichier autodoc de la workbench.library donne un autre exemple de programme utilisant
une AppIcon et une AppWindow. On peut créer une icône de "spooler" (gestionnaire de file
d'attente) d'impression et l'ajouter au Workbench comme AppIcon. Pour imprimer un fichier,
il suffit alors de le lâcher sur l'AppIcon. En double-cliquant sur l'AppIcon,
on obtient une fenêtre qui donne l'état de la file d'attente, qui permet de changer les priorités
et d'annuler des fichiers en attente, etc. La fenêtre peut aussi être une AppWindow,
pour ajouter aux possibilités. Comme exemple pratique, le programme DP PrintManager ouvre
une AppIcon et gère une file d'impression.
Cet exemple un peu détaillé va nous permettre de passer rapidement à la programmation.
Les trois fonctions de la workbench.library qui nous intéressent s'appellent :
AddAppIconA, AddAppMenuItemA, AddAppWindowA. En voici les prototypes en C :
Explication des arguments communs
- "id" est un nombre qui est ignoré par le Workbench, et sert à différencier les différents
"AppObjets".
- "userdata" est également ignoré par le Workbench : on y met ce qu'on veut, l'adresse
d'une structure par exemple.
- "text" donne le nom de l'AppIcon ou de l'AppMenuItem.
- "msgport" est le port de communication par lequel le Workbench nous informera du
lâcher d'icône (AppIcon/Window) ou de la sélection du menu (AppMenuItem).
- "taglist" est une liste de balises, qui jusqu'à présent doit être vide.
Les arguments particuliers
- "lock" est jusqu'à présent inutilisé (NULL).
- "diskobj" pointe vers une structure DiskObject (en gros une icône), dont on peut
soit préciser les champs "à la main" dans le programme, ce qui est un peu compliqué,
soit créer une icône avec IconEdit et l'appeler avec GetDiskObject.
- "window" pointe vers la fenêtre à ajouter.
Chaque fois qu'il y aura une action sur l'AppObjet, le Workbench va nous en
informer, par le biais du port de communication qu'on spécifie dans la fonction.
La notification consiste en un AppMessage, qui est une structure Message augmentée de
plusieurs champs.
Il peut y avoir trois types de messages, chaque type correspondant à la nature
de l'AppObjet manipulé : MTYPE_APPWINDOW, MTYPE_APPICON, MTYPE_APPMENUITEM.
Les champs UserData et ID sont égaux aux arguments donnés lors de l'appel
de la fonction d'initialisation (AddApp..).
La liste des arguments est en fait un tableau, on peut y accéder des deux façons suivantes :
En cas de succès, ces trois fonctions retournent un pointeur sur la structure "AppObjet"
correspondante, dont on se sert uniquement pour enlever l'AppObjet a la fin du programme.
En cas d'échec, la fonction retourne NULL. Cela peut arriver quand le Workbench ne tourne
pas ou par manque de mémoire. Les trois fonctions qui servent à enlever les AppObjets s'appellent
(assez logiquement) RemoveAppIcon, RemoveAppMenuItem, RemoveAppWindow.
Ce premier exemple ouvre une AppIcon sur le Workbench, et affiche le nom des icônes
qu'on lâche dessus (une ou plusieurs à la fois). Le nom est tiré du champ wa_Name du
message reçu du Workbench. Il informe également des double-clics sur l'AppIcon.
En fait, ce programme n'affiche que les noms des icônes qui correspondent à des
fichiers ou à des AppIcons ; il affiche une chaîne vide si on lâche l'icône d'un
disque ou d'un répertoire. Pour obtenir le nom des disques ou des répertoires,
il faut exploiter le champ wa_Lock du message reçu. On peut utiliser la fonction
NameFromLock() de la dos.library (Workbench 2.0 et plus), qui permet d'obtenir le nom
et le chemin d'un fichier d'après son "lock".
A présent, voyons comment utiliser un AppMenu et une AppWindow. Au lieu d'écrire
un programme pour chaque objet, nous allons combiner l'utilisation des deux
objets en un seul programme. Il sera sans doute un peu plus compliqué à comprendre,
mais sera plus proche de la programmation d'un utilitaire comme ToolManager.
Le programme ouvre une fenêtre, la déclare comme AppWindow, et ajoute un intitulé
"List" au menu "Outils" du Workbench (c'est l'AppMenu). On peut prendre une
icône (ou plusieurs avec la multisélection) et ensuite, soit la lâcher sur l'AppWindow,
soit sélectionner l'entrée "List" du menu "Outils". Dans les deux cas, les noms des
icônes lâchées/sélectionnées seront affichés ; dans le cas de l'AppMenu, on cherchera le
chemin des icônes et on appellera la commande "C:List" avec ces chemins. On aura
ainsi le contenu du tiroir où se trouve chaque icône.
Vous avez probablement entendu parler de MyMenu et de ParM, qui permettaient de lancer
un programme par un menu du Workbench, avec le système 1.3. Le 2.0 a intégré directement
dans sa workbench.library des fonctions appropriées, il n'y a pas besoin de "bricoler"
des utilitaires et de rectifier les bibliothèques du système. Le logiciel du DP de Nico
François, ToolsDeamon, rectifie par exemple des vecteurs de l'intuition.library pour afficher
des sous-menus dans le menu "Outils", ce qui n'est pas prévu par le 2.0 (ni le 3.0).
Le Workbench 3.0 a apporté une nouvelle fonction à la workbench.library : WBInfo (lock, name,
screen). Elle permet d'obtenir la fenêtre d'information du Workbench sur un fichier
quelconque, sans passer par le Workbench et son menu "Icônes/Information...". Browser II
s'en sert en 3.0 et affiche la fenêtre d'information sur son propre écran.
Je conseille à tous ceux qui sont intéressés par la programmation système de se procurer
les RKM sous forme de fichiers (appelés RKRM il me semble), dans le domaine public.
Il existe aussi le "C Manual", qu'on peut trouver par exemple sur Aminet,
répertoire dev/c sous le nom ACM.lha (443 ko).
En conclusion
Un des intérêts de l'AppIcon est également de pouvoir retailler l'écran du
Workbench (avec ScreenModePrefs) et de garder l'application dans un coin
sous forme d'AppIcon. L'iconification sous forme de fenêtre, comme le font
AZ ou VirusX, ne permet pas de changer la résolution du Workbench, car il
demande de fermer les fenêtres non-Workbench. On doit dans ce cas fermer les
programmes correspondants, comme le CLI/Shell par exemple. Avec un programme DP comme KingCON
(une console avec historique des commandes et beaucoup de possibilités variées), on
peut garder son Shell sous forme iconifiée, changer le nombre de couleurs et la
taille du Workbench, et rouvrir son Shell ensuite.
Voici un exemple de programmes qui utilisent les AppIcons : ToolManager, Browser II,
XOper, Excellence!, KingCON, IconEdit, livré avec le 2.0, est une AppWindow.
Excellence! ajoute également un AppMenu. On peut éditer un fichier en le
lâchant sur l'AppIcon ou en sélectionnant l'entrée "Excellence!" du menu "Outils".
Avec Browser II, le fait de lâcher une icône sur son AppIcon ouvre le répertoire
correspondant à celui de l'icône. En lâchant un fichier sur la fenêtre KingCON, le
nom et le chemin du fichier s'inscrit sur la ligne de commande.
Bref, ces trois fonctions de la workbench.library permettent une ouverture du Workbench vers
les applications, en ajoutant certaines possibilités aux programmes. Cependant,
on pourrait imaginer par exemple une fonction pour ouvrir directement un répertoire
quelconque sur le Workbench. Le Workbench 3.0 s'avance déjà dans cette direction
avec la fonction WBInfo(). Il est à noter que les derniers développements de X Window
(sur Unix) et de Windows intègrent des possibilités qui existent déjà depuis le Workbench
2.0 sur Amiga.
|
