1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
|
[[ These are just private implementation notes. They're probably
meaningless and/or out-of-date. Tony 16/9/99 ]]
M - V - C
Models:
- Generator (GeneratorClass)
Views:
- Component (ComponentClass)
- Control (ControlDescriptor)
Controllers:
- implicit...?
- it'd probably be cleaner with a formal separation.
- will probably need some kind of Controller-style mechanism
to implement feedback from Generator's data to visible controls...
[torbenh]
graphen implementierung:
welche objekte stellt die core lib zur verfuegung ?
generator objekt.
ein plugin gibt in der Regel eine von Generator abgelittene Klasse zurueck.
einen Objektyp (das ist ja ne klasse :)
es gibt auch plugins die einen componenten typen abgeben.
das muss aber eigentlich nicht sein, da die inputs und outputs
ueber generator methoden gemacht werden.
deswegen sind die emu components auch generatoren.
das sollte ich unbedingt aendern.
das wuerde ueber signal typen auszuschliessen sein,
dass es falsche verbindungen gibt.
TODO:
- move the connection code for emu components to the generator implementation.
what objects does core-lib provide ?
- Generator (is a base class)
- The GeneratorClass (the plugins implement this interface)
- it would be good to have a type system here.
- plugins could register a type ?
(hmmm types should be seperate plugins or implemented in the core.
first implement types in the core. types could come from the raptor rdf stuff
- the event stuff, the clock stuff.
- there must be a method to connect with adding.
the connection algorithms
|
