ROOT
2002 Workshop Summary discussion
Georges Irwin:
How committed are you to the CINT's based implementation of RT (signal/slot)?
Fons
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?
Rene
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?
Rene
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.
Rene
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.
Mohamed:
Are going to invest 2 FTE per year to improve the GUI. Wouldn't be better to invest only one FTE in supporting QT?
Rene:
What about the help system?
Mohamed:
There is a help system.
Rene
Well what's time consuming is to actually write the text.
Chris
Is the new help system going to be user usable?
Rene
Yes
Damir
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).
Fons
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.
Rene
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.
Damir
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.
Rene
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.
Damir
About HELP, you should think about the question the users ask themselves, i.e. more like "How do I fit this thing?".
Rene
Our web site is per-used by robots. We could take more advantage of that.
Nick
We are talking about 3 types of help. References, API, FAQ.
Rene
We had the same remark from Ilka about the GUI.
George
Our users are drawn to Doxygen, especially for class without ClassDef.
Philippe
You can now use ClassImp to register the implementation file even if the ClassDef is not present.
Axel
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.
Nick
RDBC, are you happy with it?
Fons
Do just need support or more development? We could add it but we can not really support.
Georges
We need just as it is.
Rene
What do you think of the format of the Workshop? Should it be smaller and more often?
Georges
This might get expansive (i.e. not affordable)
Bill
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)
Documentation:
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
ROOTCINT
and CINT
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?)
Graphics
ability to change the color, at least as a customization.
a few issue on graphic libraries from G4GuiRoot
request for a standard ROOT gui.
I/O
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
TTree
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
Infrastructure
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