1. des documents faiblement taggés (weakly tagged).
2. des informations textuelles qui ne sont pas forcément en anglais, ni basé sur un alphabet latin.

• correction de bugs,
• ajout et suppression de colonnes à la table d'affichage avec les touches '+' et '-',
• activation du modèle de table dynamique (nombre de colonnes dans la table d'affichage fonction de la largeur de la fenêtre),
• activation de la navigation dans la liste d'images avec pagination.

• pour le moment, je conserve en mémoire les thumbnails calculées pour le rendu, en fonction de leurs tailles, on peut vite être confronté à un java.lang.OutOfMemoryError: Java heap space.
  Pour le moment, utiliser les paramètres de la JVM -Xms<initial heap size> -Xmx<maximum heap size> est une solution à court terme. Une amélioration pourrait être d'améliorer le thread d'affichage en utilisant une liste bornée en taille pour les items chargés en mémoire.
• le widget swing est plus lent que le widget SWT Nebula Gallery (sauf pour le temps de chargement du widget en lui même, swing est beaucoup plus rapide), sur deux points:
  • pour le calcul des thumbnails: dans un premier temps, j'ai utilisé BufferedImage.scaleInstance(...), puis dans un second temps JAI (j'ai testé avec et sans la library C, d'ailleurs étonnamment la library native de JAI est plus lente que la library pure java). Dans les deux cas SWT fait appel à des routines plus rapides.
  • pour l'affichage, la JTable est un widget assez rigide, il y a peut être des paramètres pour assouplir le scrolling mais je ne les connais pas. J'ai quand même positionné l'unité d'incrémentation du scroll (via sp.getVerticalScrollBar().setUnitIncrement(42), sp étant le JScrollPane de ma JTable, pour que le scrolling ne se fasse pas row par row mais sur une quantité de pixels.
• le layout: avec SWT Nebula Gallery, le layout est dynamique, si la largeur de la fenêtre change le nombre de colonne de la grille d'images s'adapte pour afficher autant de colonnes que possible. Dans mon widget, la JTable empêche ce genre de chose.
  Je pourrais faire écouter le redimensionnement de la JTable et changer son modèle en fonction, mais j'ai peur que cela alourdisse cruellement l'affichage.
  Une solution à adopter serait peut être de changer le modèle sur demande de l'utilisateur, par exemple avec les touches '+' et '-', pour ajouter ou retirer des colonnes au modèle.
  edit 09-05-16: j'ai ajouté les deux comportements (1) '+' et '-' pour modifier le nombre de colonne, et (2) un modèle de table dynamique en fonction de la taille du JScrollPane contenant la JTable, ça se fait bien en codant futé pour modifier au minimum le modèle.
  Ainsi j'ai dû coder aussi l'update de la cellule sélectionnée dans le nouveau modèle (i.e. nouveau modèle car redimensionnement de la table, il faut que la cellule qui était sélectionnée dans l'ancien modèle soit toujours une cellule sélectionnée dans le nouveau modèle), et un scroll de la JTable pour que la cellule sélectionnée soit affichée (un scroll du rendu du nouveau modèle pour que la cellule sélectionnée soit affichée).

• Galatee-0.1.jar
• edit 09-05-17: nouvelle version avec l'edit 09-05-16 (voir plus haut): Galatee-0.2.jar. Ajout également d'une interface GalateeListener à implémenter pour répondre aux événements sur la grille d'image:

  public interface GListener extends EventListener {
  	public void itemClicked(GEvent e);
   
  	public void itemDoubleClicked(GEvent e);
   
  	public void selectionChanged(GEvent e);
   
  	public void focusChanged(GEvent e);
  }

• SWTGalatee-0.1.jar

• utiliser un Panel avec un GridLayout, spécifier la taille de la grille du layout en fonction du nombre d'images. Trouver un moyen pour savoir quand une cellule du panel doit être affichée et quand elle n'est plus sur l'écran. Quand elle doit être affichées faire un setComponentAt(...) de la cellule avec un custom panel pour mon image+metadata. Dès que la cellule quitte l'affichage de la fenêtre (par un scrolling), faire un setComponentAt(..., ..., null).
• ne pas utiliser une table mais une succession de JList, ce qui permettrait de ne pas avoir des lignes de tailles fixes (et pas de ligne du tout d'ailleurs), cependant ce n'est peut être pas visuellement très louable.

1. configuration du lancement du main > onglet common
2. cocher File
3. indiquer le chemin vers le fichier de log

• avec ANTLR et une astuce un brin bancal.
• façon barbarian avec ANTLR ou JavaCC: essayer toutes les possiblités sur les types de tokens (j'en ai peu, la grammaire est courte, donc c'est envisageable), et si aucune erreur alors le type de token est possible... Le problème est que ce n'est pas que le type de token que je veux, mais aussi les productions possibles!

• dans la dernière version d'ANTLR, dans le package Java, il y a la version ANTLR 2.7.7 dans un package antlr, et la version 3.1.1 dans un package org.antlr, attention donc à bien utiliser la classe org.antlr.Tool et non antlr.Tool...

• DataDirect XQuery
• XQDT
• xqIde: coloration syntaxique, vérification de syntaxe, génération de xqDoc, et intégration avec la database Marklogic pour l'exécution de requête XQuery.

Exception in thread "Thread-2" org.eclipse.swt.SWTException: Device is
disposed
at org.eclipse.swt.SWT.error(SWT.java:3777)
at org.eclipse.swt.SWT.error(SWT.java:3695)
at org.eclipse.swt.SWT.error(SWT.java:3666)
at org.eclipse.swt.widgets.Display.error(Display.java:1142)
at org.eclipse.swt.widgets.Display.wake(Display.java:4068)
at
org.eclipse.ui.application.WorkbenchAdvisor$1.run(WorkbenchAdvisor.java:797
)

• Un moyen de faire est d'utiliser le TrayIcon introduit dans Java1.6 pour ajouter une icône de notification dans le System Tray (nommé notification area sous GNU/Linux, et Taskbar Status Area sous Windows), puis utiliser la méthode: TrayIcon.displayMessage(caption, text, TrayIcon.MessageType.INFO);. Cette approche a le mérite d'être multi-plateforme. voir http://java.sun.com/developer/technicalArticles/J2SE/Desktop/javase6/systemtray/
• Utiliser libnotify:
  1. soit par un script python par exemple:

     #!/usr/bin/python
      
     from pynotify import *
     import sys
      
     def notify(title="", message=""):
     	n = Notification(title, message)
     	n.show()
     	#n.set_hint("x", 0)
     	#n.set_hint("y", 0)
      
     init("cli notify")
     if len(sys.argv)>2:
     	notify(sys.argv[1], sys.argv[2])
     else:
     	notify()

     voir http://roscidus.com/desktop/node/336.
  2. soit en utilisant une commande système avec notify-send (apportée par le paquet libnotify-bin sous Ubuntu).

Dans le cas présent, c'est une application Web de recherche d'imagette de livre depuis les AWS, Amazon Web Services, puis Ajout ou Retrait d'une imagette à un profil de lecture. Les imagettes sont stockées en local sur le serveur, et pour chaque profil je construis un fichier XML contenant les informations sur les imagettes (metadata physiques, i.e. location, size etc.) ainsi que les données relatives au document obtenues par les AWS et intégrées dans des éléments XML DublinCore (creator, title etc.).
Je génère des pages XHTML qui contiennent mes éléments DublinCore marshallés, il faut ainsi que JAXB génère des fragments XML et non un document XML complet.
Ainsi pour faire en sorte que JAXB ne génère pas l'instruction processing du document XML lors de l'opération de marshalling, il faut utiliser la propriété suivante:

m.setProperty(Marshaller.JAXB_FRAGMENT, Boolean.TRUE);

Autre point: bien que j'ai spécifié que mon élément contenant mes données DublinCore comme élément du document XML, (i.e. il fait partie des éléments déclarés dans ma XSD), JAXB ne veut pas marshaller uniquement cet élément.
Une exception est levée disant qu'il manque l'annotation @XmlRootElement dans la classe de binding de cet élément. Ce post sur java.net en parle mais ne répond pas vraiment au problème.
Ajouter cette annotation à la classe de binding résout le problème mais l'élément étant déclaré dans ma XSD, cette modification ne devrait pas être nécessaire...
Cependant, pour Unmarshaller un fragment XML, on peut passer par un XMLStreamReader, et passer cet objet à l'unmarshaller (une rapide overview), on doit pouvoir en faire de même pour le marshalling.

• le fichier de configuration du service tomcat est /etc/default/tomcat.
• les fichiers server.xml et web.xml se trouvent dans /etc/tomcat, mais le reste des fichiers de configuration sont dans /var/lib/tomcat.
• les webapps sont dans /var/lib/tomcat/webapps, mais l'application Tomcat se trouve dans /usr/share/tomcat.
• on a un script de gestion du service /etc/init.d/tomcat.

# Tomcat auto-start
#
# description: Auto-starts tomcat
# processname: tomcat
# pidfile: /var/run/tomcat.pid
 
export JAVA_HOME=/opt/jdk1.6.0_10
 
case "$1" in
start)
start-stop-daemon --start --chuid www-data:www-data --exec /home/tomcat/apache-tomcat-6.0.16/bin/startup.sh -- -d -r /home/tomcat/apache-tomcat-6.0.16/
;;
stop)
#start-stop-daemon --stop --exec /home/tomcat/apache-tomcat-6.0.16/bin/shutdown.sh
/home/tomcat/apache-tomcat-6.0.16/bin/shutdown.sh
;;
restart)
$0 stop
$0 start
;;
esac
exit 0

chmod 755 /etc/init.d/tomcat

ln -s /etc/init.d/tomcat /etc/rc1.d/K99tomcat
ln -s /etc/init.d/tomcat /etc/rc2.d/S99tomcat

LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so
JkLogFile /var/log/apache2/mod_jk.log
JkLogLevel debug
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] "
JkMount / worker1
JkMount /* worker1

workers.tomcat_home=/home/tomcat/apache-tomcat-6.0.16
workers.java_home=/opt/jdk1.6.0_10
ps=/
worker.list=worker1
worker.worker1.port=8009
worker.worker1.host=localhost
worker.worker1.type=ajp13
worker.worker1.lbfactor=1

workers.tomcat_home=/home/tomcat/apache-tomcat-6.0.16
workers.java_home=/opt/jdk1.6.0_10
ps=/
worker.list=worker1
worker.webapps.port=8009
worker.webapps.host=localhost
worker.webapps.type=ajp13
worker.webapps.lbfactor=1

<VirtualHost *:80>
ServerAdmin nicolas.james@gmail.com
ServerName webapps.trevize.net
# Send servlet for context /servlets-examples to worker named worker1
JkMount /* worker1
# Send JSPs for context /jsp-examples to worker named worker1
JkMount /*.jsp worker1
</VirtualHost>