[Dcmlib] Feedback

[Eric Boix]

	Salut Emmanuel,

Quoting Emmanuel Olart <eolart at theralys.com>:
> Le wrapping python pose quelques problemes que je suppose connus : il
> est notamment impossible d'utiliser toute méthode prenant un std::string
> en paramètre ou en retournant un.
Les wrappers python sont actuellement dans les choux complet. En gros
ils sont cass'es depuis le passage a cmake et c'est mon prochain gros
morceau (apres le nettoyage de l'interpretation de Pixel Data).

> Il faudrait définir quelle méthode doit être wrappée dans le cas d'un
> overload, notamment pour les constructeurs. Sur ma version seul
> gdcmHeader(void) est wrappé, si je veux l'autre qui me semble plus utile
> (d'un point de vue personnel) je l'indique clairement a SWIG.  Serait il
> utilie qu'on prenne une par une les methodes surchargées en qu'on décide
> lesquelles wrapper pour python ?
Hummm, en theorie seule l'API doit-etre wrappe' (a la louche gdcmHeader
et gdcmFile). Si tel etait le cas, il ne devrait pas y avoir de surcharge
a gerer....

> Autre problème plus génant a mon sens :
> La méthode :
> 
> bool gdcmFile::SetImageData(void *inData, size_t expectedSize) est
> recemment passée à 
> bool gdcmFile::SetImageData(uint8_t *inData, size_t expectedSize)
Oui, car c'est LA chose qui est actuellement en cours de nettoyage.
Une fois les choses calme'es (et sincerement je suis a deux doigts de
jetter l'eponge vu la complexite' du code actuel) on devrait pouvoir
revenir a des types classiques pour l'API (i.e. des types que Python
connait). Autrement dit, on va revenir a
   SetImageData(void *inData, size_t expectedSize)
quand le nettoyage sera fini...

> J'ai cru comprendre que cette modif a été faite afin de pouvoir faire un
> free sur le inData le moment venu.
Yep, et surtout pour l'API soit plus humaine pour les GetImageAsRGB()
ou WriteImageAsRGB() [modulo la syntaxe qui sera VTK like, i.e. un
SetMode puis un GetImage() ou un WriteImage()].

> Dernière petite remarque sur ma short list, le python setup.py install
> ne copie pas le _gdcm.so la ou il doit aller. 
Hummmm, le setup.py est mort (depuis le passage a Cmake). Je pense qu'il
le restera. A vrai dire c'est le seul degat collateral (i.e. le cadavre
civil) du passage a cmake. A comparer a tous les avantages de cmake.

Je pense que la partie packaging de gdcmPython devra donc se faire
avec un packager externe (rpm ou Innosetup pour Win32) et non plus
avec le packager natif de python i.e. distutils. Vu le nombre de parametres
que gere maintenant cmake, je pense que distutils n'est de toutes fac,ons
plus adapte' pour gdcm...

	Frog.