ROOT 2002 Workshop Summary discussion


Georges Irwin:

  How committed are you to the CINT's based implementation of RT (signal/slot)?


  It works fine for us at the moment and users can use something else (like sigc++).

  Do not know if we can have both at the same time



  About ROOT on Windows, Is your main problem speed?


      For me speed is good enough as it is.  The real problem is in the thread handling.

      In particular, there is problem with the usage of CINT.  We need expert in Windows threads.

      The GUI is fully ported. 


  Do we have to wait until 2003?


  Bertrand is working on this on his own time and money.  We do want to speed this process.


  Are you considering Windows to be un-important?  One of the latest experiments (GLAST?) have their code organized in such a way that it work equivalently well on Windows and Unix.



  Do you any idea of a "Standard ROOT Gui" much like PAW and system like that.


  There are quite a few experiences with this (we have URLs).  People do like to have the history file so that you can trace back what you did.



  Are going to invest 2 FTE per year to improve the GUI.  Wouldn't be better to invest only one FTE in supporting QT?


  What about the help system?


  There is a help system.


  Well what's time consuming is to actually write the text.



  Is the new help system going to be user usable?





  I had a big bunch of requests, which are answered by "we will work on 2D/3D"

  It would be nice to have a way to switch ACLiC from Optimization to NonOptimization easily.

  Problem of license.  Do you intend to change the license of ROOT now that

  it is supported by CERN.  (Meaning True Open Source License).


  We have had many discussions with the license experts.  We are going to move toward an Open Source license.

  CINT does not want to apply GPL.  Masa had some discussions with Richard Storma.  CINT will be GPL compatible.


  ROOT is in the standard test package for the GNU compiler.

  I will be ALWAYS opposed to any restriction to the distribution of ROOT.

  ROOT's success is due to outside contribution.  We need to acknowledge those contributors much better.


  Even power-users only know and/or use a small fraction of the existing interface

  So it would be nice to have the HELP system that shows "first/forFront" class being more visible and the same for the method.  So that it is easy to see the real meat of the class. 


  We would like to improve the 'relation' between classes and their package.

  Maybe by extending ClassDef to contain which package this class belongs.

  This information would be useful for the plug in manager.


  About HELP, you should think about the question the users ask themselves, i.e. more like "How do I fit this thing?".


  Our web site is per-used by robots.  We could take more advantage of that.


  We are talking about 3 types of help.  References, API, FAQ.


  We had the same remark from Ilka about the GUI.


  Our users are drawn to Doxygen, especially for class without ClassDef.


  You can now use ClassImp to register the implementation file even if the ClassDef is not present.


  THtml does a good job but is not as extensive as d0xygen.  It would be great to be able to move to doxygen.  The problem is that the d0xygen and THtml have different convention.  So maybe we should upgrade d0xygen to understand ROOT's format.


  RDBC, are you happy with it?


  Do just need support or more development?  We could add it but we can not really support.


  We need just as it is.




  What do you think of the format of the Workshop?  Should it be smaller and more often?


  This might get expansive (i.e. not affordable)


  Maybe we could have parallel session



The following is the list of request (there is NOT ordering of important and/or order of being handled)


  rootcint not well documented

  what is NOT supported by rootcint is not documented

  rootcint error messages are not very helpful

  work-around are usually simple but NOT obvious.

  Need for more online help

  Need for a more directed view of the existing classes


  Stricter C++ support (at least as an option)

  Pointer handling; Overloading ; STL enhancement

  Improve CINT

  cintify Geant4

  ability to generate the dictionary of "just" a specific instantiation of a template data member

  virtual inheritance (does the dictionary calculate base offset properly?)


  ability to change the color, at least as a customization.

  a few issue on graphic libraries from G4GuiRoot

  request for a standard ROOT gui.


  Support for type change if USER provide a cast operator.

  std::vector<bool> saves a series of char or maybe ints.

  Abstract class in the I/O


  need ability to do something with branches when TChain load a new tree.

  Enable to change the value of a pointer attached to a TBranch

  Clarify, document the subset of C++ which is supported by ROOT I/O and which subset of this subset is supported within trees.

  TClonesArray split even in base class

Library Support

  Request for direct support of RDBC

  Request for direct support/distribution of TSQL, libodbc

  more integration/standardization between TParticle and StdHep


  request for patch for production version.

  virtual inheritance (does the dictionary calculate base offset properly?)

  more granularity in shared library selection, possibly based on header files.

  Command completion

        Pointer chains; Replay history blocks; Wildcard completion;

        GUI events to history; Auto-cast TObject; Emacs root-mode, Calc;

  Return value: objects

  Undo option

  Segfault debugging

  Extra documentation

  Thread: too many global variable in particular gFile, gFitter, gPad