- Modif de z-mesh pour tenir compte des modifs Metafor relatives au Propelem.
- Constructeur par copie de la Map Oofelie (oeTools/oeMap.h - pas oeMaps.h qui ne sert à rien!). N'ayant pas d'itérateur constant sous la main, j'ai dû faire un const_cast pas très joli mais ça marche. Ceci permet de copier correctement des Propelem. Quand OE se décidera-t-il à virer ces objets d'une autre génération au profit de la STL? Certainement jamais au rythme où ça avance; faut donc faire avec...
- Amélioration et unification de la gestion des Propelem. Pour rappel, un Propelem (propriété élémentaire) s'ajoutait (via un add_properties) au niveau de l'objet qui allait générer les éléments concernés. Par exemple, un Propelem de contact se met au niveau du ContactInteraction qui génère les éléments de contact. Par contre, en ce qui concerne les éléments volumiques, le Propelem devait se mettre au niveau de l'entité géométrique utilisateur sur laquelle elle se trouve. La symmétrie est retrouvée depuis ce commit puisqu'il faut mettre le Propelem au niveau du FieldApplicator (le générateur d'éléments). Remarquons que le Propelem est le seul objet pour lequel le mécanisme PhySet a sa raison de subsiter! (oui, c'est à cause de lui qu'on perd son temps à faire des get_properties!)
- Autre nouveauté: le add_properties de Interaction ne réagit plus de la même manière: il copie le Propelem donné en argument (un peut comme on fait wireset.copy(wire1) dans le cas du contour et de son ensemble, par exemple). Ceci permet de détruire le Propelem donné en argument après l'appel. A quoi ça sert? Par exemple à écrire une fonction python qui crée et assigne automatiquement des Propelems. Ceux qui auraient déjà essayé de faire ça savent que c'était pas possible sans passer le Propelem en argument. Faire cependant attention à ne pas modifier le Propelem après le add_properties. La copie sera bien sûr inchangée!
- Modification de tous les cas-tests pour changer le fameux add_properties.
- Pour le cas particulier du LoadAdaptationManager (l'adaptation de pression par Laurent), il y avait un problème: le Propelem doit être partagé entre l'objet qui le contient et le PropelemSet (seul cas où on utilise ce set). Pour régler ça, j'ai dû bidouiller un truc: lorsqu'on utilise le PropelemSet et l'adaptation de pression (regardez sonaca_tee.py par exemple), il faut utiliser la nouvelle fonction Interaction::sharePropElem au lieu du traditionnel add_properties. On retrouve ainsi l'ancienne manière de faire.
- En ce qui concerne le nom de la fonction (add_properties), je crois que je la renommerai plutôt soit copy, soit setPropElem. Il faudrait aussi interdire l'ajout du PropElem à toutes les autres entités, ça serait plus propre et plus sûr...
- Petite remarque finale (pour Luc en particulier): il n'est plus possible de créer un seul FieldApplicator et distribuer le Propelem sur plusieurs domaines (comme c'était fait dans presque tous les cas-tests de monos). Il faut obligatoirement faire plusieurs FieldApplicators. Au niveau du fichiers, inutile de faire des couper-coller: python supporte les boucles for (je vous rappelle qu'il serait possible de coder Metafor entièerement en python, alors les boucles c'est vraiment pas grand chose), alors utilisez-les! Un chti exemple (tiré de - accrochez-vous - eas3dModesTracNoSym2):
for i in [1, 101, 201, 301, 401, 501, 601, 701, 801]:
app = FieldApplicator(i)
app.push(i,VOLUME_PO)
app.setElementType(EasVolume3DMetaElement)
intset.copy(app)
ou:
for i in range(1,901,100):
app = FieldApplicator(i)
app.push(i,VOLUME_PO)
app.setElementType(EasVolume3DMetaElement)
intset.copy(app)
Pour ceux qui veulent pas lire mon blabla : 
modifiez vos cas-tests - sinon, ils marcheront plus!
