[Clam-devel] and NetworkEditor evolves...

[David García Garzón]

This mail is to explain latest movements on NetworkEditor svn for anyone 
wanting to collaborate in ideas or code.

I have three pending refactors to the CLAM NetworkCanvas:

1 - Abstracting the widget from CLAMness so that the widget can be used in 
other environments. A Qt equivalent of Patchage's FlowCanvas for GTK. 
(http://wiki.drobilla.net/FlowCanvas)

2 - Turning NetworkCanvas a QGraphicsView: QGraphicsView appeared the release 
after we migrated to qt4, so we implemented by hand a lot of QGraphicsView 
functionality. QGraphicsView is optimized with clipping, selective redraw, 
B-Tree lookup... so it should speed up big networks rendering.

3 - Using a plugin system for the embedded widgets. That is breaking the long 
spagetti if-then-else function that inserts a widget or another depending on 
the processing class.

I am currently addressing the first refactor. It would enable adding the 
network canvas to an eventual qt audio widget library that will be usefull 
for other projects such as [http://qjackctl.sourceforge.net/ QJackCtl] (that 
has been ported to qt4) and the UPF's GTI framework which have 
shown interest on such a widget.

But also it could revert on CLAM's features, for example, we could add a 
cool 'jack view' to the network editor that could be used to connect the 
network with other jack clients as if they were clam processings within the 
same application.

What i am doing now is constructing a base class and moving most CLAM 
independent attributes and methods up. If I found some CLAM dependency I 
create a virtual method and call it. By the shape of the virtual methods i 
think that a modelview-like class will emerge but i don't take it by granted.

Next steps:

1 - Solving the processingBox:
Some net canvas tasks that are delegated to the ProcessingBox are also CLAM 
dependant and should be moved to a CLAM dependant class. The problem here is 
that processingboxes now have direct access to the clam processing pointer 
and indirecting using a network view could mean a lot of processing name look 
up. To avoid lookup, do we need a 'processing view' class? could a dull void 
pointer could be used to avoid lookup?

2 - Providing hooks to populate contextual menus and sigslot programming
Currently CLAM dependant context menu options are populated in the abstract 
class. They work because sigslots are runtime binding and in runtime the 
derivate provides such signals and slots.

3 - Subclassing the netcanvas widget or the netcanvas widget using a 
network-view interface?:
The key question to decide is what do we need to redefine, just the new model 
access virtual functions, yelling for a view class hierarchy, or do we still 
need to redefine widget's methods so that views imply double hierarchy of 
widget and views.

4 - Solving the initial setup (active model vs. providing a description list)
The most intense interaction with the model is the initial reflexion of the 
model into the canvas. Initially 

5 - Spliting dummy and clam models and test that dummy works by itself without 
clam.
Currently the model we have is dual, when the network pointer is null, we do 
dummy actions over a dummy model. We used it originally to test the widget. 
Dummy model could be the default implementation to be redefined being 
abstract methods on the abstract canvas or in the abstract model/view 
hierarchy.

6 - Implementing a Jack model.
The proof of concept will be implementing a Jack model. It will introduce new 
requirements not currently considered: Some actions doesn't have sense such 
as adding/removing clients, and also networks are modified externally so that 
we need to observe external signals beside user actions.

7 - Adding the canvas to the clam widgets plugin and eventually split it in a 
different binary package so they can be used without CLAM.



-- 
David García Garzón
(Work) dgarcia at iua dot upf anotherdot es
http://www.iua.upf.edu/~dgarcia