C'est le plus ancien. Il contient des projets CodeWarrior préhistoriques (7.0 ou 8.0) qui ne peuvent pas être convertis par les versions récentes de CodeWarrior (Pro x). Pour préciser à quel point cela peut être pénible de convertir les projets du SDK 3.0 sur des versions récentes de CodeWarrior, je signalerais que j'ai été harcelé par des développeurs Mac Américains après avoir signalé sur le Newsgroup Netscape consacré aux plug-ins que j'avais converti à la main un projet du SDK 3.0 et que je le tenais à la disposition des demandeurs.
C'est le kit le plus récent. Il contient des projets qui peuvent être convertis par les versions récentes de CodeWarrior. La version 4.01a des APIs du Plug-In incorporent cependant des fonctionnalités qui ne sont supportées que par des versions 4.0 et plus des navigateurs (par navigateur j'entends Communicator-Navigator et Internet Explorer). Si vous souhaitez que votre Plug-In fonctionne sur des versions 3.x des navigateurs, vous pouvez toujours utiliser ce Kit mais vous ne devez pas utiliser les nouvelles fonctionnailtés (qui ne sont pas exceptionnelles AMHA).
Téléchargez le SDK 4.01a.
En ce qui concerne la documentation, il existe là aussi deux versions :
En résumé :
Téléchargez la version PDF.
Si vous avez téléchargé la version 4.01 du SDK, ouvrez le projet Simple Macintosh, compilez le, et installez un alias du Plug-In dans le répertoire Plug-In de Netscape Communicator.
Vous remarquerez que je parle ici du Browser de Netscape uniquement. Et ce pour une bonne raison: ce Plug-In d'exemple ne fonctionnera que sur Netscape Communicator/ Navigator et plantera sous Internet Explorer.
Après avoir fait mumuse avec ce Plug-In, il est temps pour vous d'affronter la vraie vie.
Pour commencer le développement d'un Plug-In, je conseille de partir du projet exemple MacTemplate; ceci pour deux raisons :
Placez un alias du Plug-In dans le répertoire du Navigateur, pas l'original. Ceci vous permettra de n'avoir qu'un seul vrai Plug-In pour tous les navigateurs: adieu la gestion des versions. Ensuite cela vous permet de compiler une nouvelle version d'un Plug-In et de n'avoir qu'à relancer le navigateur.
En ce qui concerne le dessin, on peut s'inspirer très fortement du code du fichier MacShell.cpp. En effet, le Plug-In doit mettre en place son contexte de dessin chaque fois qu'on lui demande de se dessiner.
Si comme moi, vous êtes un chieur de première, vous n'allez pas manquer de vous interroger sur la signification exacte des structures NP_Port et NPWindow.
Quelques heures de débuggages à la lueur de la bougie m'ont donné certains éléments de réponses que l'on ne trouve pas dans la documentation. Ils ne sont pas évidents à retenir vu que au moment où j'écris ces lignes, je dois avoir le code sous les yeux pour vérifier.
En tout premier lieu, tous les dessins que vous effectuez sont clippés. Ceci est géré à l'aide de la données clipRect de la structure NPWindow et des données portx et porty du NP_Port.
Les données portx et porty servent aussi généralement à définir la nouvelle origine QuickDraw pour le Plug-In.
Les données width et height de la structure NPWindow vous permettent de connaîtrent les dimensions du Plug-In.
A quoi peuvent bien servir les coordonnées x et y de NPWindow ? Ce sont en fait les coordonées réelles du coint supérieur gauche du Plug-In.
Si vous souhaitez gérer une vue OpenGL dans un Plug-In, je tiens à vous signaler tout de suite que du point de vue des coordonnées, c'est un véritable cauchemar.
Un autre point important concerne le redimensionnement et le scrolling du Plug-In.
Vous êtes averti du redimensionnement du Plug-In par un nouvel appel à la fonction NPP_SetWindow.
En ce qui concerne le scrolling, vous n'êtes jamais averti. Ce sont justes les valeurs des données NPWindow et NP_port que l'on vous donne au moment du dessin du Plug-In qui sont modifiées. Donc se méfier.
Ce détail crucial est en fait expliqué dans la documentation (mais il est toujours difficile de retrouver le bon passage qui en parle).
Sous MacOS, la gestion des évènements souris, clavier, de dessin, se fait par la fonction NPP_HandleEvent. Cette fonction supporte la plupart des évènements MacOS et 3 de plus :
En ce qui concerne le curseur, c'est une très mauvais idée d'utiliser la globale qd. Il faut en fait utiliser gQDPtr qui est récupéré par le Plug-In. Une fois que votre code supporte ces évènements, vous verrez que le support du clavier est assuré.
Il suffit donc simplement d'appeler UseResFile comme d'habitude.
Sous CodeWarrior il est relativement simple de débugger un Plug-In, qui est en fait une Shared Library. Dans le panneau préférence du projet, rubrique Target, sélectionnez la sous-rubrique Runtime Settings.
Vous pouvez à l'aide du bouton Choose... indiquer le binaire qui lance votre Shared Library. Choisissez donc Internet Explorer ou Netscape. Il suffit ensuite de glisser sur la fenêtre du Navigateur la page HTML faisant appel à votre Plug-In.
Remarque : Dans mes divers essais, il s'est avéré que cette technique ne marchait pas avec iCab.
HALTE !
Vérifier que votre Plug-In fonctionne sous Internet Explorer avant de commettre ce suicide professionnel.
He oui ma brave dame, c'est un monde pourri dans lequel nous vivons avec tous ces satellites qu'ils nous envoient dans le ciel et qui perturbent le climat: Internet Explorer ne supporte pas toutes les fonctionallités du SDK.
Les incompatibilités que j'ai répertorié à ce jour avec la version 4.5 d'Internet Explorer :
Pourquoi ? Tout simplement parce qu'Explorer ne supporte déjà pas la communication entre JavaScript et Java.
Conclusion : Si vous souhaitez faire un plug-in qui tourne sous Internet Explorer, ne faites pas de LiveConnect. Sur la fonction NPP_GetJavaClass faites un return NULL;
On peut streamer dans un Plug-In des données sous 3 formes dont une consiste à demander à être averti de la fin du stream et de la création d'un fichier contenant ces données ; c'est l'option StreamAsFileOnly.
Cette fonctionnalité ne fonctionne pas sous Internet Explorer qui à la place vous gratifie d'un stream StreamAsFile.
Cela signifie que quand vous demandez le téléchargement d'un fichier, chaque fois qu'une partie de ce fichier a été téléchargée, un appel à NPP_Write va se faire.
Une fois que tout le fichier a été téléchargé, Internet Explorer appelle NPP_StreamAsFile avec le fichier local que lui-même a crée.
Conclusion : Evitez le StreamAsFileOnly si vous le pouvez. Si vous devez y passer, prenez en compte le fait que sous Internet Explorer le fichier sera streamé en StreamAsFile.
Internet Explorer ne vous fait parvenir que les événements keyDown.
Conclusion : Concevez votre gestion des touches en vous appuyant uniquement sur l'événement keyDown.
Internet Explorer 4.5.1 ne supporte pas l'appel à NPN_GetURLNotify.
Internet Explorer 5.0 supporte l'appel à NPN_GetURLNotify.
Apparement Internet Explorer 4.5 ne supporte pas plusieurs Streams à la fois. Si vous faites plusieurs requètes par NPN_GetURL (IE 4.5 ne supporte pas NPN_GetURLNotify vu qu'il ne supporte pas le mode NP_ASFILEONLY), toutes les Streams vont être détruite sauf une.
Conclusion : Sous Internet Explorer 4.5, une seule Stream à la fois pour ne pas le fatiguer. On peut par exemple faire une requète GetURL à la fin de NPP_DestroyStream. Comme Internet Explorer 5.0 supporte le multi-stream, bonjour l'angoisse.
Méfiez vous d'Internet Explorer et des autres Browsers. Le fait que votre Plug-In tourne sous Netscape Communicator ne signifie pas qu'il fonctionnera sur les autres navigateurs.
A partir d'un Plug-In, vous avez accès à tous les appels de la ToolBox. Tels que FSpDelete, FSpRename, etc, ... Vous pouvez donc effacer un disque dur entier si vous le souhaitez.
Pourquoi n'est ce pas sécurisé comme le sont les applets Java ?
Tout simplement parce que c'est l'utilisateur qui choisit de downloader un Plug-In, c'est lui encore qui installe le Plug-In. Sans le consentement de l'utilisateur un Plug-In ne peut pas s'installer dans le répertoire Plug-In du Navigateur. Même la technique de téléchargement de Plug-In spécifique à Netscape Communicator demande une confirmation auprès de l'utilisateur.
En résumé :
L'utilisateur sait ce qu'il fait et assume le cas échéant.
Le code source MacTemplate correspond à une version modifiée de l'exemple MacTemplate.
Ceci est un project CodeWarrior Pro 5.