Skip to content
GitLab
  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in / Register
  • VTK VTK
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 762
    • Issues 762
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 205
    • Merge requests 205
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages & Registries
    • Packages & Registries
    • Package Registry
    • Infrastructure Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • VTK
  • VTKVTK
  • Issues
  • #17218
Closed
Open
Created Jan 11, 2018 by Ben Boeckel@ben.boeckelOwner

Support specifying object factory overrides in executables

The vtkObjectFactory class should gain support for preferring certain overrides as given by the executable that is running. For example, one can create two versions of an application, one which is for desktop use and another that is for VR device use. Currently, vtkRenderingOpenVR disables all other overrides of the classes that it overrides, effectively disabling support of the other overrides while it is loaded.

The proposed solution is to support "override attributes" on override classes. Executables could then register their preferences with vtkObjectFactory and when a factory base class is requested, it would consult the preferences and the available attributes and construct the "best" option.

Implementation details:

  • vtkObjectFactory::RegisterOverride would take an additional argument of a linked list of attributes for the override.
  • Overriding classes would indicate that they have overrides via the <classname>_OVERRIDE_ATTRIBUTES preprocessor definition. It would resolve to the pointer to the head of a linked list describing the attributes for the class (this would allow for intermediate base classes to provide attributes that may be referenced by subclasses).
  • vtkObjectFactory.cmake would use #ifdef to specify this attribute to the RegisterOverride call.
  • vtkObjectFactory.cmake would provide a function to create a source file which indicates preferences to vtkObjectFactory as a static initialization function for use in executables.

One question is where the logic of choosing an override lives.

  • Embedded proposal We describe an algorithm in vtkObjectFactory which performs the selection based on its input data. One could be "strength of preference is from first attribute specified to last and within each attribute, first to last". So the selection between class J with AttrA=X,AttrB=N and class K with AttrA=Y,AttrB=M with the preferences AttrA=X,Y;AttrB=M,N would be class J since AttrA is a "stronger" preference.
  • Callback proposal It can either live in a function that is passed to vtkObjectFactory which it then calls for override requests (where attributes are available) with the list of constructor functions paired with the attributes describing each. Here, the vtkObjectFactory.cmake module should have the option to provide a default implementation of this callback, likely similar to whatever the Embedded proposal is.

Cc: @brad.king @utkarsh.ayachit @ken-martin

Assignee
Assign to
Time tracking