1. 18 Jul, 2010 3 commits
  2. 16 Jul, 2010 2 commits
  3. 15 Jul, 2010 13 commits
  4. 14 Jul, 2010 1 commit
  5. 13 Jul, 2010 2 commits
  6. 12 Jul, 2010 9 commits
  7. 09 Jul, 2010 1 commit
    • jcfr's avatar
      ENH: Review the DisplayableManagerFactory design · 12664fda
      jcfr authored
      1) The factory is now a singleton (following the nifty pattern also applied in vtkEventBroker, see http://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Nifty_Counter)
      2) DisplayableManager are registered using their classname
        - For that reason, in CMakeLists, the displayableManager should be
      processed using the VTK_MAKE_INSTANTIATOR3 macro. Dong so will create the
      proper list of instanciator.
      3) The concept of DisplayableManagerGroup has been created.
      A group is a list of DisplayableManager instances associated with a Renderer
      and a MRMLViewNode.
      For example, the qMRMLThreeDRenderView can call InstantiateDisplayableManagers()
      method on the factory and obtain a DisplayableManagerGroup.
      Observing the group, the qMRMLThreeDRenderView will be able to catch
      the UpdateEvent (invoked upon a DisplayableManager call RequestRender) and
      call its method scheduleRender(). Internally, ScheduleRender used a QTimer
      to handle the compression of Rendering events.
      The group also observe the Factory and will instantiate or delete a DisplayableManager
      if DisplayableManager is registered/unregistered from the factory after
      the group has been instantiated. The group observe the event
      DisplayableManagerFactoryRegisteredEvent and DisplayableManagerFactoryUnRegisteredEvent
      from the factory.
      Note: Nothing prevent the instantiation of multiple Group associated with
      the same renderer
      git-svn-id: http://svn.slicer.org/Slicer4/trunk@14087 3bd1e089-480b-0410-8dfb-8563597acbee
  8. 05 Jul, 2010 6 commits
  9. 04 Jul, 2010 3 commits