Skip to content

Structural Goals

Jump to bottom
ThomasMcVay edited this page Jan 11, 2015 · 15 revisions

Node Based GUIs and Data Structures

The entire foundation of the MediaApp data structure is based around Nodes that contain Knobs. If your user has some data, it should be inside of a Node. Nodes can not be transfered between NodeOwningObjects. Paste functionality is provided by creating an entirely new node, see Copy/Paste below

This enables us to use generic project saving/loading, and generic undo redo functions that cost so much to develop on a per application basis.

Generic saving and loading.

A single generic format for saving Project files will suffice. The files will be constructed as human editable ascii files with heavy reliance on pprint.pformat in three layers:

  • AppCore.AppAttributes
  • AppCore.Nodes
  • AppCore.UndoQueue

At load time Instances of Nodes will be reconstructed with heavy reliance on eval Security concerns associated with these types of executions will be addressed directly in the load project functions.

Contextual Undo

Separate UndoQueues handled in the context of each Knob, Node or NodeOwningObject that ultimately report to AppCore.UndoQueue.

AppCore.UndoQueue also handles both RunOnce Scripts that will need a single Undo Object, and Looping Scripts that are given the power to disable the queuing of undo objects for a set period of time.

Timeline Independence

AppCore does not have a current time or frame. NodeOwningObjects shall be expected to provide these independently in a way that they do not conflict with each other.

Example Case: An instance of a TimelineWidget will maintain a Timeline with several NodeGraph Nodes on it. Each NodeGraph when opened will have it's own separate timeline, so that when viewed that nodegraph may have data ranging from 0 to 100 where on the timeline that same data appears at the node's position at frame 800 to 900

In this way, different kinds of WidgetLinkedNodes will be infinitely nestable.

Active Terminal and Script Widget

Active scripting interface in the terminal built from python cmd module similar in style to pdb Active scripting interface in the gui as a provided widget

Generic widgets that will handle necessary data from any conceivable media type:

  • ViewerWidget (Arguably the most complex cross media task, best achieved with a variety of subclasses)
  • GraphWidget (Does not handle data, It's up to the nodes to define accepted data types)
  • NodeGraph (Just a subclass of GraphWidget)
  • TimelineWidget (Just a subclass of GraphWidget)
  • CurveEditorWidget (Really only ever takes data from Knobs)
  • PropertiesBin (Just an abstraction for displaying QDockWidgets that contain Knobs
  • BrowserBin (File browser supporting a variety of modes, collapsing file sequences, etc)
  • ScriptEditor

Node types spanning a variety of media types

Media types will include but are not limited to:

  • Image Data/Streams
  • 2D and 3D Vector Data
  • Array Data/Streams
  • Audio Data/Streams
  • Packet Streams

Math

Mathematic formulas used in the construction of nodes for various media types, so that standard effects can be achieved.

Example A Gamma formula for image data might be used in a color correction node, or a phase formula for audio data might be used to provide a phase modulation effect.

Simple Knobs

Simple Knobs need to provide both a simplified data structure and a gui. Simple Knobs need to be ownable by other knobs and widgets.

Complex Knobs

Implement their own key frames and GUI's

Easily Accessible Icons

svg files are loaded automatically by IconFromSVG, and exposed as functions in the Icons package. The use of functions rather than instances here is important, because the icons get converted to a QIcon the contains a memory heavy QPixmap. By using a function, the QIcon isn't created in memory until you call for it, in this way I can add thousands of icons taking minimal disk space without impacting available memory.

TCP Presence

Use Pyro to do a few unsoported things:

  • Maintains both a remote copy, and a local copy of each object.
  • Make it so that Calling setValue, setScript, createNode or SoftDelete causes the then also change the cloned remote object
  • Set up a server bouncing system similar to Smedge so that users can operate with TCP functions as if they were using a TCP network.
  • Create Temporary objects on ther server that points to the widget that a given user has set their focus in.

Add some Gui Concepts:

  • Large Profile Pictures should appear in the corner of any widget that you share a focus with.
  • Small Profile Pictures should appear in the corner of any widget that is a parent of the NodeLinkedWidget they currently have focused
  • Small Profile Pictures will appear above the node and parent nodes of any NodeLinkedWidget that a user is focused on.
  • Double clicking on a ProfilePicture will open a chat session.
  • Chat widget that displays conversation from current Widget.

NodeLinkedWidgets that are sub projects.

Should look and feel like opening a normal NodeLinkedWidget. If another user has the project open, the second user will pull the Live version from the current server. Closing the widget will prompt the user to save if they are last out.

Versioning up, saving, etc will have scripting calls that can make changes to parent projects based on user end scripts.

Clone this wiki locally