Problèmes à l'exécution quand on veut jouer du son sur une machine dont la carte son n'est pas configurée (Linux)
En fait les vrais problèmes (ceux qui demandent de faire usage de son cerveau) ont commencé quand il a fallu enregistrer
puis charger des simulations.
Le premier problème venait d'un problème de conception dans une des classes et du fait que les threads et les images
ne sont pas des objets sérialisables, or nos plugins qui étaient sérialisables, utilisaient des objets nécessitant des threads
ou des images. Ce problème a pu être réglé en modifiant les classes incriminées (en particulier la classe utils.SoundPlayer
qui est passée de l'état de classe implémentant Runnable
à celui de sous-classe de Thread
qui implémente
Serialisable
).
Le deuxième problème est que nous avions prévu que l'emplacement des plugins soit libre, ne nécessitant pas que leur emplacement
se trouve dans le fameux CLASSPATH
. Tout marchait très bien, on chargeait les classes, on les instanciait, on
enregistrait la simulation qui était prête, mais, pas moyen de charge le fichier (pour être plus précis, une exception
ClassNotFoundException
était levée quelque part). Ce problème a donc été résolu en rajoutant le répertoire des plugins
dans le CLASSPATH
de l'application. Ce problème au chargement perdure un peu sous Windows (probablement le Write once,
run everywhere, en fait c'est aléatoire, des fois ça marche, d'autres...).
Un autre problème rencontré sur les machines Linux de la fac : quand on utilise un Boid comme Homer (Simpson) et que la carte son n'est pas
configurée, une exception est levée (on se souvient plus du nom) qui bloque le programme.
JBuilder, même s'il offre beaucoup de fonctionnalités nous simplifiant la vie, à une forte tendance à bouffer (désolé, nous
ne voyons pas d'autre mots) les ressources et la mémoire, tant et si bien
qu'il fini par se planter souvent.
Ces plantages vont du curseur de texte qui disparait à la terminaison sale (en laissant plein de JVM tourner) en
passant par l'impossibilité de modifier un fichier ouvert, en fait on en revient toujours à VIM ou Emacs
La conception d'interface graphique, même si le fait de tout faire (ou presque) en WYSIWYG, pose aussi des problèmes de portabilité du à l'inclusion de packages propriétaire de Borland dont on a pas besoin, et des problèmes de performances car le code génèré n'est pas particulièrement propre (en fait, il se contente de créer tous les objets nécessaires avec leurs propriétés, mais sans se soucier d'efficacité.
C'est tout dans le titre, nous nous y sommes pris comme des pieds : nous avons commencé pendant les révisions, nous avons perdus nos vacances avec, nous nous sommes mis d'accord sur l'architecture du projet qand déjà, nous en avions deux qui étaient relativements avancées, mauvaise communication malgré les techniques par mail...
Le JFileChooser
et le Look And Feel MacOS ne font pas très bon ménage (on ne peut pas revenir en
arrière dans les répertoires).
Quand on veut changer le Look And Feel de l'application (au choix: MacOS, Metal, Motif ou Win32), la modification n'affecte
pas les JFileChooser
s.
La fenêtre du créateur d'entité n'est créée qu'une seule fois au démarrage de l'application, ensuite elle se contente de passer
du premier au second plan, afin d'éviter de devoir recréer des instances de cette fenêtre et donc d'accroitre un peu la
réactivité de l'application qui n'est pas une championne de vitesse.