Discussion :

[millie]

Bonjour,

Je voulais juste discuter de certains détails concernant l'ajout de plugins.

Le message s'adressant surtout à pseudocode .

On avait parlé une fois d'utiliser des annotations à la place du fichier de propriété afin d'avoir quelque chose du style :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
@PluginShortDescription("Mon Plugin qui s'affiche dans le menu")
@PluginName("Le vrai nom du plugin")
@PluginCategory("Ma catégorie")
public class BloomEffectPlugin extends GenericPluginFilter {
}

Alors, sauf que si on veut pouvoir internationaliser le programme, il faudrait que les annotations puissent aussi utiliser quelque chose.

Par exemple : @InternationalizationClass(MaClass.class) avec une méthode du type : String getText(String key)

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
@PluginShortDescription("plugin.bloom.shortdescription")
@PluginName("plugin.bloom.name")
@PluginCategory("plugin.bloom.category")
@InternationalizationClass(MaClass.class)
public class BloomEffectPlugin extends GenericPluginFilter {
}

Bon, pour l'instant ça va.

Sauf que quand je charge les plugins du jar, il faut quand même que je fasse un : Class<PluginFilter> filter = (Class<PluginFilter>) pluginClassLoader.loadClass(clazz);
En utilisant un ClassLoader spécial pour les Jar.
Donc du coup, je vois pas trop d'autres possibilité que d'avoir toujours un fichier de config qui contient la liste des classes de plugins à moins de charger comme un bourrin récursivement les fichiers et de vérifier qu'il n'y en a pas dans le lot qui hérite de PluginFilter (mais, est-ce que c'est pas un peu lent ?) => il est toujours possible d'offrir les deux possibilités

Donc au final, je ne suis pas trop avancé.

A moins que quelqu'un ait une idée

[pseudocode]

Le message s'adressant surtout à pseudocode .

Ah que... qui ça ?

Donc du coup, je vois pas trop d'autres possibilité que d'avoir toujours un fichier de config qui contient la liste des classes de plugins à moins de charger comme un bourrin récursivement les fichiers et de vérifier qu'il n'y en a pas dans le lot qui hérite de PluginFilter (mais, est-ce que c'est pas un peu lent ?) => il est toujours possible d'offrir les deux possibilités

Le chargement "bourrin" des *.jar (limité au répertoire plugin) me parrait jouable. C'est ce que fait ImageJ et ça n'a pas l'air d'être trop long (on en reparlera quand l'application aura 1 million de plugin .)

Sinon on peut faire comme eclipse : un mecanisme qui regarde si des jar ont été ajoutés/modifiés depuis le dernier lancement. Si "oui" alors scan bourrin. Sinon on recharge la meme liste que la derniere fois. Plus un bouton pour forcer le scan (comme actuellement).

On avait parlé une fois d'utiliser des annotations à la place du fichier de propriété afin d'avoir quelque chose du style

Pourquoi utiliser des annotations (et donc la retention RUNTIME) ? Pourquoi ne pas mettre directement les méthodes getXXXXX() dans l'interface de Plugin ?

Pour la traduction, il y a un moyen simple. Des fichiers "properties" pour chaque langue qui contiennent des couples (clé,traductions). La clé représente le nom complet de l'attribut a overrider. Si la clé n'est pas trouvée, on utilise l'attribut original (via son getter) du plugin. Sinon on prend la valeur du fichier "properties".

On peut aussi gerer les noms des paramètres en utilisant une syntaxe spéciale

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
public class BloomEffectPlugin extends GenericPluginFilter {
  String getCategory() { return "artistic"; }
  String getDescription() { return "the description in english"; }
  /* ... */
}

Code BloomEffectPlugin_fr.properties :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
millie.plugins.core.artistic.BloomEffectPlugin.category=artistique
millie.plugins.core.artistic.BloomEffectPlugin.description=la description en français

millie.plugins.core.artistic.BloomEffectPlugin.@threshold=seuil
millie.plugins.core.artistic.BloomEffectPlugin.@radius=rayon

[millie]

En fait, les annotations servaient surtout à pouvoir accéder à des propriétés sans avoir à instancier la classe.

[pseudocode]

En fait, les annotations servaient surtout à pouvoir accéder à des propriétés sans avoir à instancier la classe.

Ah, ok. En tant qu'architecte je ne suis pas vraiment pour l'utilisation des "annotations de source" à la place des "attributs de classe". Mais bon, c'est personnel.

Quitte à utiliser les annotation, pourquoi ne pas créer une seule grande annotation PluginInfo.

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface PluginInfo {
    String name();
    String description();
    String category();
}

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
@PluginInfo(name="Bloom filter",category="artistic",description="the description")
public class BloomEffectPlugin extends GenericPluginFilter {
/* ... */

[millie]

En fait, quand j'ai dit instancier la classe, je voulais dire : instancier un objet de cette classe.

Enfin, je vais réflectionner

[pseudocode]

En fait, quand j'ai dit instancier la classe, je voulais dire : instancier un objet de cette classe.

oui, j'avais compris. Je fais souvent la même erreur

[millie]

J'ai ajouté 2 nouveaux plugins possibles qui vont permettre d'ouvrir et d'enregistrer des images dans un format particulier.

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public interface ImageDecoderPlugin {
 
	public BufferedImage[] decode(File file);
}

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public interface ImageEncoderPlugin {
 
	public void encode(BufferedImage[] im, File file);
}

Pour l'instant, il faut un fichier codecs.config qui contiendra le nom de la classe avec les formats supportés par le plugin.

Cela sert surtout pour ouvrir des fichiers non pris en compte par la bibliothèque standard (comme du TIFF).


Par exemple :

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
 
public BufferedImage[] decode(File file) throws IOException {
		BufferedImage inputImage = null;
 
		if(input.getName().toLowerCase().endsWith(".tiff") || input.getName().toLowerCase().endsWith(".tif")) {
			//on charge comme un tiff
			SeekableStream s = new FileSeekableStream(input);
	        ImageDecoder dec = ImageCodec.createImageDecoder("tiff", s, null);
	        RenderedImage in = dec.decodeAsRenderedImage(0);
 
	        System.err.println("Input image color : " + in.getColorModel());
	      //suivant le nombre de composant, on choisie une image en niveau de gris ou en niveau de couleur
	        if(in.getColorModel().getNumColorComponents() == 1)	        	
	        	inputImage =  new BufferedImage(in.getWidth(), in.getHeight(), BufferedImage.TYPE_BYTE_GRAY); 
	        else
	        	inputImage =  new BufferedImage(in.getWidth(), in.getHeight(), BufferedImage.TYPE_INT_RGB);
	        Graphics2D g = inputImage.createGraphics();
			g.drawRenderedImage(in, AffineTransform.getTranslateInstance(0, 0));
			g.dispose();
		}
		else {
			throw new IllegalArgumentException("Fichier pas de type tiff");
		}
		return new BufferedImage[]{ inputImage };
	}

Avec un codecs.config sous la forme :
maclasse=tiff,tif

Normalement, si on ajoute les jar (du genre JAI) dans le dossier plugins, ça sera bon.

[millie]

Le chargement "bourrin" des *.jar (limité au répertoire plugin) me parrait jouable. C'est ce que fait ImageJ et ça n'a pas l'air d'être trop long (on en reparlera quand l'application aura 1 million de plugin .)

Je repensais à un truc.
J'aurai aimé garder la possibilité de développer des plugins dans le workspace. Mais comment faire avec ça en fait ?

Je me demande si il n'est pas nécessaire de garder les 2 types de chargements.

[pseudocode]

Je repensais à un truc.
J'aurai aimé garder la possibilité de développer des plugins dans le workspace. Mais comment faire avec ça en fait ?

Perso, j'utilise un script an qui me génère le *.jar dans le répertoire des plugins, donc je ne vois pas trop le problème.

[millie]

J'ai fait une MAJ sur le principe des PluginInfo et CodecInfo

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
@PluginInfo(name="Bleach ByPass", category="Cinema")
public class BleachByPassFilter extends GenericPluginFilter {
...

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
@CodecInfo(formats="tif,tiff")
public class TIFFDecoder implements ImageDecoderPlugin {
{
...

Pour ne pas prendre en compte le filtre, il suffit de commenter l'annotation.

Actuellement, le fichier plugins.config ne sert donc plus dans les jar.
Il peut être ajouté dans le workspace au niveau de MillieGUI et ne contient plus qu'une liste de classe. Ca sert uniquement pour le développement si on veut travailler sans jar.

[millie]

Intégré à la nouvelle version

[pseudocode]

Suggestion d'ajout d'un constructeur dans "GenericPluginFilter" afin de positionner automatiquement le nom du filtre s'il y a une annotation.

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public GenericPluginFilter() {
	PluginInfo info = this.getClass().getAnnotation(PluginInfo.class);
	if (info!=null)	setPluginName(info.name());
}

Ca évite de dupliquer le nom dans le code du filtre:

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
@PluginInfo(name = "Stack Blur", category = "Flou")
public class StackBlurFilter extends GenericPluginFilter {
 
	public StackBlurFilter() {
		setPluginName("Stack Blur"); // <-- fait automatiquement dans le constructeur du parent
		setRefreshable(true);
		...

[millie]

Suggestion d'ajout d'un constructeur dans "GenericPluginFilter" afin de positionner automatiquement le nom du filtre s'il y a une annotation.

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public GenericPluginFilter() {
	PluginInfo info = this.getClass().getAnnotation(PluginInfo.class);
	if (info!=null)	setPluginName(info.name());
}

Ca évite de dupliquer le nom dans le code du filtre:

Code java :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
@PluginInfo(name = "Stack Blur", category = "Flou")
public class StackBlurFilter extends GenericPluginFilter {
 
	public StackBlurFilter() {
		setPluginName("Stack Blur"); // <-- fait automatiquement dans le constructeur du parent
		setRefreshable(true);
		...

Fait et releasé

[millie]

Il devrait y avoir quelques nouveautés :

- un nouveau type de plugin qui est un super type des 4 PluginFilter qui existent actuellement (Generic, Area, Rectangular, NoParameter). Pour des besoins plus spécifiques, il est possible d'hériter directement de celui là.

Par exemple, GenericPluginFilter va désormais ressembler à ça : http://subversion.developpez.com/pro...agePlugin.java mais cela ne changera pas les plugins existants.

- un nouveau type de plugin qui devrait se greffer visuellement sur la barre des tâches de l'application (et non de l'image) qui est relativement équivalent à la classe Generic. C'est par exemple déjà le cas avec l'action "Fichier/Nouveau". Cela permettrait de faire des plugins qui ne sont pas directement liée à une image (comme une fusion HDR, un téléchargement d'image par le web) ou des plugins qui n'ont aucun rapport (MAJ de l'interface de swing par exemple)

Ces 2 classes auront accès à des classes d'action "générique" du type : ouverture/sauvegarde/fermeture/MAJ dans l'IHM d'une image. Et auront la possibilité de s'abonner à certains types de traitement.

- la possibilité de créer une vue plus custom (c'est le cas actuellement avec la fonction Courbe ou la fonction "Manage Plugins") => mais ça reste à éviter

- un nouveau type de paramètre File ou Files

- éventuellement un type de plugin "Lifecycle" qui est appelé au chargement à l'arrêt du plugin => pour l'instant, je n'en ai pas l'utilité

- la possibilité de rendre les plugins "scriptables", cela pourrait permettre plus tard d'enregistrer des séquences de traitement et de les exporter.