Devel/NetworkEditor TODO's
From Clam
This is the development page of the NetworkEditor port to Qt4.
Contents |
[edit]
Tasks
- Porting NetworkCanvas to QGraphicsView framework
- [david] Abstract NetworkCanvas from CLAM dependencies
- Implement a Jack based NetworkCanvas
- Filtering the processing tree (like Amarok playlist)
- Adding processing documentation (doc widget or tab?)
- Evaluate whether processing configurators as DockWidget is feasible and useful.
- Implement the check that all inports are connected before play
- Solve code duplication on play prevention code (unconfigured, unconnected, empty, no blocking processing...) for Prototyper a Network editor
- Solve code duplication on backend selection that exists in Prototyper and NetworkEditor
- Solve code duplication on commandline processing that exists in Prototyper and NetworkEditor
- Offlineplayer: Check that processings are configured. In the case they are not, print configuration errors and exit.
- Binder by properties (now that Qt allows arbitrary properties)
- Add the properties to clam widgets
- Adapt the binder
- Designer plugin to add such properties from the menu to acceptable processings
- Control senders clean up
- Refactor connection loading code in NetworkCanvas
- Select (suggest) the audio backend on command line
- Select (suggest) the audio device on command line
-
Unify External (Source/Sink) and explicit (AudioIn/Out) audio inputs and outputs so a network will work whatever the mode (jack, alsa, protaudio, embeded into a network...)
- Saving/Loading dummy networks
- Undo feature
- Review 'Changed' flag check list (see checklist bellow )
- Both in dummy and clam mode
- Review loading error check list (bellow)
- Review tooltip logic
- Keep the offset of the viewport when moving boxes to < (0,0)
- Solve the MIDIManager hack (still not done in qt4)
- Move new colors to canvas as methods
- Checks on renaming
- Which processing names are valids?
- '.' should not be valid <- is used as connector full name separator Processing.Connector
- '__' (two or more underlines) should not be valid <- is used in prototyper name as place holder for space and separator between the processing and the connector
processings/ports/controls crashes.
- Box selection to take int account just the body (not the connectors)
-
Coloring ports by token type
-
Investigate how not having to register the configurations
-
Processing selection
-
Add a 'selected' state to ProcessingBoxes
-
Add a visual cue to the selected state
-
Make the canvas control the selection changes on click
-
Enable the control key to multiple selection.
-
Enable a drag mode for the selection box
-
Select all action
-
Deselect all action
-
Click on canvas deselects all when no ctrl pressed
- Implement selection actions
-
- Monitors:
- Abstract meta information such as units, scale, ranges, labels, circularity... as DataSource interface.
- Unify widgets thanks to this abstraction
- Push data abstraction to the Pools and to the Ports.
- Copy & paste processings (or xml's?)
[edit]
Feature proposals
- Undo
- Dropping a wire over a processing body connects to any suitable connector
- Hover should not work through an overlapping processing.
[edit]
Testing Check Lists
[edit]
Changed flag
- Set it on every change
- Proc added from context menu
- No when user cancelled the name dialog
- No when the type does not exists
- Proc added by drag
- No when the type does not exists
- Proc removed
- Proc reconfigured
- No when user cancelled the config dialog
- Proc renamed
- No when user cancelled the name dialog
- Connection
- No when the connection was discarded as illegal
- Disconnection
- No when no wire is involved with port
- Move?
- Resize?
- Both in dummy and clam mode
- Proc added from context menu
- Reset it on:
- new
- load
- save/save as
[edit]
Network loading errors
* XML Error
* Bad processing definition
* Type not available
* Name already exists in network
* Invalid name (dots or whatever)
* Bad processing configuration
* Wrong configuration parameter name
* Bad port/control connection definition
* Source processing not in network
* Source connector not in processing
* Target processing not in network
* Target connector not in processing
* Non connectable peers
* Incompatible types
* Already connected peers
* Other connection present (just for InPorts)
[edit]
Play-disturbing actions
* Should be reviewed in which cases they disturb and which ones they doesn't * Adding a wire * Removing a wire * Adding a processing * Removing a processing * Configuring a processing * Load/Clear the network * More?
[edit]
Design thoughts
[edit]
Model-Widget interface
* Widget actions with implications on the network and things to check afterwards
* Add a processing of a given class
* Was it possible?
* Name?
* Connect ports/controls
* Was it possible?
* Remove wires connected to a given port/control
* (?)
* Remove a processing and related wires
* (?)
* Configure a processing
* Configuration status?
* Ports/Connections changed?
* Rename a processing
* Was it possible (valid and unique)?
* Widget required information
* The name of a created processing
* The number of ports/controls
* The name of a port/control by index
* The processing status
* Whether two connectors are connectable
* Things to be checked
* Network status changes: It is playing?
* Processing status changes: Are they configured?
* Could we get the list of processings for the processing toolbox?
* Can we rely on the processing name to index model objects?
* Is any one, appart from canvas and new/load actions, modifiying the model?
* Full update (on new/load) alternatives
* Push: the model manipulates the canvas
* Pull: canvas ask the model all the information
Notes about the interface on the Qt3 version:
* ProcessingController
* slots
* send control -> does it directly
* name changed -> bypass, emits the same
* configure processing -> agh, sync-signals a lot of things Configure, then change state. If running, starts and stops the processing (just that processing!!) and if it changes the connectors it removes connections and updates the connectors on the presentation
* NetworkController
To ask:
* stoping just the processing being configured instead the full network is the proper thing to do? stop the whole network. or else the flowcontrol will assert (or fire a unready processing). Note that this could be done transparently to the user. I mean, the user can perceive that the network is playing all the time. --pau
