X-Git-Url: https://git.creatis.insa-lyon.fr/pubgit/?a=blobdiff_plain;f=TODO;h=4673dc1063c90d5278d3adcf3dd985b463d3a451;hb=44a9814938a6824d3a66b932429084517da6dadf;hp=3e57f3c55b22d10dd93c1bb7a148bcc84a06a5f1;hpb=9a8932b74aab77d55d7b478b1996611c7d588daa;p=gdcm.git

diff --git a/TODO b/TODO
index 3e57f3c5..4673dc10 100644
--- a/TODO
+++ b/TODO
@@ -1,9 +1,22 @@
-* Split gdcmHeader through inheritance to create gdcmHeaderHelper
-  that would regroup all the heuristics above a gdcmHeader e.g. the
-  functions GetXsize(), GetXSpacing(), GetXImagePosition()...
-  Those functions are the one using the results of the parsing as
-  done by gdcmHeader to provide the user with heuristics above various
-  values found in the header (the simplest form being to default a value).
+-----------------------------------------------------------------------------
+Use namespace gdcm:
+  Problem: using enum with name like 'Unknow' on .Net, or LP on cygwin 
+           causes problems.
+  Question: when introducing the namespace, should we remove the gdcm
+            prefix from classes or keep it ?
+-----------------------------------------------------------------------------
+Convert the C-like IO to C++ IO:
+  Goal: remove all the C-oriented IO references like FILE*, fread...
+        with the C++ fstream notation. Provide overload of operators
+        << and >> for any gdcm class using file IO.
+  Question: the underlying jpeg libraries (written in C) use the FILE*
+        notation. Is there a way to still use fstream in gdcm, and 
+        build or pass the proper FILE* to jpeg libs ?
+  References:
+        binary IO are available at
+        http://www.angelfire.com/country/aldev0/cpphowto/cpp_BinaryFileIO.html
+-----------------------------------------------------------------------------
+* Clean up src/gdcmValEntry.[h|cxx] from VoidArea
 * vtk/vtkGdcmHeader.cxx: if speed becomes a concern some changes can
   be made at the cost of memory consumption (refer to header of 
   vtk/vtkGdcmHeader.cxx)
@@ -17,14 +30,6 @@
   gdcmElValSet::GetElValueByNumber except for the returned code.
   gdcmHeader::SetPubElValLengthByNumber (which is based on 
   gdcmElValSet::SetElValueLengthByNumber) is used nowhere...
-* The declarations commented out and starting with "TODO Swig" (try
-  grep "TODO Swig" *.h) needed to be temporarily removed for swig to
-  proceed correctly (in fact problems appears at loading of _gdcm.[so/dll]).
-  So, simply uncomment the declaration once you provided the definition of
-  the method...
-* As stated by the first lines of Test/ExceptionAndPython/README, it looks
-  like we can move back to the exceptions and remove the errno stuff from
-  src/gdcm* !
 * Fix the bug in Test/bug1.cxx (see first comment line): Win32 only.
 * All (or at least many of) the methods of gdcmHeader whose only arguments
   are an ElValue* (e.g.  FindLength, FindVR, LoadElementValue...) can
@@ -70,5 +75,3 @@
       a.write(output);
    }
 
-* use namespace for gdcm, to avoid problem when using enum with name like
-  'Unknow' on .Net, and LP on cygwin that cause problems