Iterative document: Ideas for v1/v2

[ollpu]

The current codebase could be called a horrible mess. Sorting it out seems like a bad idea, because it is built on principles that could be vastly improved. Plan: Reprogram the whole codebase with new ideas and optimizations.

v1 was supposed to be relased with the current codebase, so perhaps v2 would be more suitable.

• Language: Probably still Processing (3)?
• Drawing
  • Only portions of the screen that were changed will be redrawn
• UI
  • More efficient and versatile pane management (integrating with drawing)
  • Universal control elements (buttons, sliders, etc)
  • "Rethinking" of layout
  • Desinging new interfaces shouldn't be about writing complicated code for every element
  • XML UI design? -> all events are pushed to functions with reflection and all the managing is handled by a singular entity
  • Operation modes
  • A simple switch to jump between modes:
    • Different modes show & hide different UI elements and change working functionality
  • Patch: Assign, move and customize fixtures (and fixture groups?)
  • Program: Program & manage memories
  • Show: Runtime mode, in which you won't accidentally make the strobe flash
  • Switching between operation modes shouldn't disrupt DMX output. Programming during the show (busking) should be possible too.
  • 3D view should be integrated in the main window somehow, such that you can view from either the top, sides, or as a pannable 3D view in the same area as where the 2D view would reside.
• DMX logic
  • Fixtures
  • All fixtures have UIDs to avoid management issues
    • Handled with a map (uid -> fixture)
    • Memories reference to UIDs instead of a numerical ID
    • Possibility of merging two files together
  • Fixture types handled as abilities which are then mapped to DMX channels for specific fixtures
    • For example: dimmer, red, green, blue, strobe, fog
    • All abilites can be used together to create different kinds of fixtures
    • Abilities accept "parameters", that control the channel. For example, the dimmer ability accepts has one parameter: Dim.
    • Ability parameters can also be unset (mainly in the programming universe)
  • Think about memories, presets, chases
• Save-files, XML
  • Ability to save fixture types to a certain level (as long as the abilities are preprogrammed)
  • Save only necessary details for memories
• Things borrowed from Chamsys MagicQ:
  • Seperate programming universe to only include necessary values into memories
  • The programming universe overwrites any values coming from memories and can be easily cleared
  • How will this be incorporated in the visualization?
• Rules
  • Drawing shouldn't compromise DMX output or simulation
  • Don't crash (Avoid trys everywhere)
  • Clear code. Don't make a mess and keep it clear.

[eliasjhojala]

Remember these

• toggle button
• push button
• text area
• switch
• slider
  • max and min values
• adjustable size for all elements
• adjustable themes
• color themes and layouts savable to xml