Plug-ins (dildo ?)

De retour après un petit long moment d’absence, mais cependant pas les mainsvide puisque depuis hier je me suis jetté sur l’éditeur de niveau de Liebesstein, maisavant il y avait une chose à faire : les plugins !

Le principe :

Nous avons GRAK, il se lance et fonctionne, un programmeur décide d’ajouter des fonctionnalités de type controle (non-graphique OG) pour par exemple faire un editeur, un analyseur de code, une trace live, un interpreteur de script etc…

Il va créer un composant (un control), l’ajouter dans le répertoir Plugins (ou ailleurs si l’envie lui prend, c’est prévu) ensuite il va modifier le fichier de configuration plugins.conf.

Au démarrage, GRAK va charger la fenêtre plugins qui chargera les plugins listé dans son fichier plugins.conf, ajoutera un onglet nommé et ajoutera le composant dans cet onglet, le rendant disponnible.

Explication en images :

06-03-31-plugins

Le plugins obtient un accès vers GRAK pour, par exemple, consulter les données centralisées (but principal). Inversement GRAK a un moyen de communiquer vers le plug-in grâce à une interface IPlugin.

Cependant GRAK, ne pouvant pas prévoir quel type de communication il va devoir faire face, utilisera une méthode commune et maléable : Alerte.

Cette méthode remplace les événements et le transfert de données.

Un cas concret :

On veu récupérer la position d’un objet qui est dans le monde 3D, afin de le déplacer peut-être.

Au clic le CR est prévenu et exécute ses méthodes (si besoin), on place les données dans la table de centralisation des données, on ajoute une ligne pour prevenir le plugin (par son nom + une action [clic])

Ce dernier sera donc prévenu d’une action, ici « clic » et dans ce cas ira chercher les données placées afin de les afficher ou modifier

Du CR vers le Plug-in il y a la méthode Alert (événement unique paramètré)
Du plug-in vers le CR il n’existe pas de lien directe

Explication de ce choix :

Le Plug-in est un élément d’analyse ou de controle
Le CR est un élément d’affichage et donc à chaque tour de rendu, tout les X rendu ou tout les x ‘temps’ il raffraichira ses données tout seul

Retour vers le futur

Zou on revient en avant, OGTexteEditable est de nouveau un OG, qui réécrira Draw et qui manipulera un IFont.

OGTexte n’était pas une bonne base, car lui est multiligne. D’ailleurs il a été amélioré, on peut accéder au DrawTextFormat de FontSysteme ce qui fait que si le texte dépasse il est masqué, avant il dépassait et était visible.

Donc voilà les points 2 et 3 de la news précédente qui sont revu et le 1 qui reste actuellement à faire.

Suite au prochain numéros.