KWWidgets/Projects/3DWidgets/Widgets/ChangingArchitecture: Difference between revisions

From KitwarePublic
Jump to navigationJump to search
No edit summary
mNo edit summary
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
==Analysis and overview of existing architecture==
==Analysis and overview of existing architecture==
'''Architecture'''
'''Architecture'''
:In order to apply the redesigned architecture regarding the vtk 3D Widgets, I started by learning how it had been applied to vtkSliderWidget and how I could use this as a basis for comparison with the designated widgets, specifically vtkBoxWidget.
In order to apply the redesigned architecture regarding the vtk 3D Widgets, I had to first understand the old architecture, then how the new architecture was supposed to work and finally re-write the 3D widgets to match the new architecture.
<br><br>


:This I commenced by looking at the vtkSliderWidget and how it interacts with the main classes regarding the restructuring project - the vtkAbstractWidget and vtkWidgetRepresentation classes and their derivatives.
This I commenced by looking at the vtkSliderWidget and how it interacts with the main classes regarding the restructuring project - the vtkAbstractWidget and vtkWidgetRepresentation classes and their derivatives.
<center>[[Image:Class_Diagram_vtKSliderWidget.png]]</center>


'''Comparing Structure'''
'''Old architecture'''
:How to structure the callback?
After looking at the was the 3D widgets worked under the old architecture, I made my own class diagram to help me understand it (as opposed to just copying the generated diagram from the vtk documentation).
:After looking at vtkSliderWidget and vtkDistanceWidget, I have come across parts of two methods of dealing with callbacks. One (above) defines the required callback methods in the widget (vtkSliderWidget) whereas the other (below, based on vtkDistanceWidget) provides the possiblity to create CallbackMapper classes inheriting from vtkCallbackMapper to provide preset callback methods.
 
:I feel that the second method is more inline with the 3DWidget reauthoring - separating events from representation. Also, it provides the possiblity to have different callbacks depending on widget use.
<center>[[Image:3DWidgets_class_arch_before.jpg]]</center>
:For example, a program may have a "View" and "Interact" modes. In "View" mode, CallbackMapperA is used where left-clicking will update a window with data XYZ. In "Interact" mode, CallbackMapperB is used where left-clicking selects the object for manipulation.
 
:Which of these methods is better for the reauthoring?
'''New architecture'''
<center>[[Image:3DWidgets_class_arch_after.jpg]]</center>


==Analysis and overview of new architecture==
==Analysis and overview of new architecture==
'''Differences between the two architectures'''
<center>[[Image:3DWidgets_class_arch_differences.jpg]]</center>


==Comparing the two architectures==
==Comparing the two architectures==
'''Comparing'''
Looking at the two diagrams, it is easier to see how the widgets work by separating the event handling system from the representation. The next step is to see what methods from the old widget relate to which part of the new architecture. Then, the new classes can be written using the old methods as placed in their corresponding new classes.
'''Methodology'''
'''Methodology'''


Line 23: Line 32:
* study events
* study events
* compare vtkBoxWidget Old and New
* compare vtkBoxWidget Old and New
* methods<br>* added<br>* removed<br>* edited
* check methods<br>* added<br>* removed<br>* edited
* example code<br>*changes to original
* update example code to match new use of widget
 
==Changing Architecture===
 
'''Previous Architecture'''
 
'''Redefined Architecture'''
 
'''Change Overview'''
 
 
 
'''Modified Widgets'''
*vtkBoxWidget<br>vtkBoxWidget.h<br>vtkBoxWidget.cxx<br>vtkBoxRepresentation.h<br>vtkBoxRepresentation.cxx<br>
vtkBoxRepresentation2D.h<br>vtkBoxRepresentation2D.cxx<br>vtkBoxRepresentation3D.h<br>vtkBoxRepresentation3D.cxx<br>
[[Media:TestBoxNew.cxx|example code]]
 
==Widgets==
 
 
 
 
 
 
<center>[[Image:Class_Diagram_vtkMyWidget.jpg]]</center>

Latest revision as of 06:14, 15 June 2006

Analysis and overview of existing architecture

Architecture In order to apply the redesigned architecture regarding the vtk 3D Widgets, I had to first understand the old architecture, then how the new architecture was supposed to work and finally re-write the 3D widgets to match the new architecture.

This I commenced by looking at the vtkSliderWidget and how it interacts with the main classes regarding the restructuring project - the vtkAbstractWidget and vtkWidgetRepresentation classes and their derivatives.

Old architecture After looking at the was the 3D widgets worked under the old architecture, I made my own class diagram to help me understand it (as opposed to just copying the generated diagram from the vtk documentation).

3DWidgets class arch before.jpg

New architecture

3DWidgets class arch after.jpg

Analysis and overview of new architecture

Differences between the two architectures

3DWidgets class arch differences.jpg


Comparing the two architectures

Comparing Looking at the two diagrams, it is easier to see how the widgets work by separating the event handling system from the representation. The next step is to see what methods from the old widget relate to which part of the new architecture. Then, the new classes can be written using the old methods as placed in their corresponding new classes.

Methodology

  • study both architectures
  • study source code; vtkBoxWidget (Old) and vtkSliderWidget (new)
  • separate source code into new classes
  • study events
  • compare vtkBoxWidget Old and New
  • check methods
    * added
    * removed
    * edited
  • update example code to match new use of widget