Technical Meeting 08/18/2006 1:15PM EDT
Agenda
| Item | People | Description |
|---|---|---|
| 1 | Geveci | Team Status |
| 2 | Shead | Wiki Documentation |
| 3 | Moreland | Signal Slot Smackdown |
| 4 | Wylie | Charting Data Models, see Chart Model-View |
Action Items
- Shead - writeup details of the proposed plot data pipeline, for further discussion / ratification.
Discussion
A question was raised about creating various forms of documentation in the Wiki; it was emphasized that developer documentation should go in the source code so it can become part of the Doxygen-generated online docs. End-user documentation will be gradually moved from the "ParaQ" wiki into the "ParaView" wiki on an ad-hoc basis until the "ParaQ" wiki becomes obsolete.
Brian W. raised some tough questions about the interface to the vtkEventQtSlotConnect class - currently, it can only be used with slots that have a convoluted five-argument function signature that includes void pointers and other evil stuff. Various alternatives were discussed, from using vtkMemberFunctionCommand to adding support to vtkEventQtSlotConnect for additional slot signatures to new adapter classes that would provide type-safety and varying numbers of arguments, such as the libraries at http://libsigc.sourceforge.net/ and http://www.boost.org/doc/html/signals.html. Many were not aware that Qt slots do not have to have the same signature as the corresponding signal - slots may have fewer arguments than the signal they're connected to, as long as the remaining arguments still match (i.e. a slot may omit the arguments at the end of the signature but cannot omit arguments at the beginning or middle, or rearrange arguments). This led to a proposal to rearrange the argument order in the slot signature for vtkEventQtSlotConnect so that the most useful arguments are at the beginning. There was tentative support for this proposal, so long as backwards-compatibility isn't affected. This would likely mean adding a new API to vtkEventQtSlotConnect that would be used to connect slots using the new signature.
There was extensive discussion on how plotting data (for line plots, histograms, probe geometry, etc) should be represented as it travels through the pipeline for delivery to the client. Various proposals ranged from using vtkTable for all plots, to using existing VTK data structures (e.g: vtkRectilinearGrid, vtkImage) to creating plot-specific datatypes (e.g: vtkLinePlot, vtkHistogram). The weak consensus was to have the plot-extraction filters generate existing VTK data structures. Further discussion centered on how this data would be delivered to the client, whether it would be converted to a single representation such as vtkTable at some point along the way, and whether it would be converted to a QtAbstractItemModel. The conversation was cut short by time and will continue at the Tuesday meeting on 8/22/2006. See Plot Data Pipeline for details.
