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
|
wie in KOffice K3bDoc von KParts::ReadWritePart ableiten
in KOffice ist der view von KParts::PartBase abgeleitet. Warum das?
alle actions, die das doc ändern, auch ins doc packen.
alle actions, die nur für die ansicht da sind (zb. properties dialog) in den view
da wir verschiedene projekt-typen für den gleichen mimetype haben macht ein ReadWritePartWrapper,
der aufgrund des doctypes entscheidet, welches K3bDoc benötigt wird, mehr Sinn. Das hieße,
dass es einen K3bPart gibt, der alle Projekte beinhaltet. Die einzelnen Projekte könnten allerdings auch wieder
dynamisch hinzugeladen werden, so dass immer nur das gerade benötigte K3bDoc im Speicher ist.
Der Wrapper muss dann nur den externalbin- und den devicemanager initialisieren und den kostore öffnen. Dann alle
K3bDocFactories (wenn ein K3bDoc als eine Art plugin dynamisch hinzugeladen werden soll) fragen, ob sie
den projekttyp unterstützen und wenn ja, eine instanz erzeugen und das dokument laden.
Wie sieht es dann mit dem erstellen eines neuen dokumentes aus? Ev. Könnte der Wrapper hier alle Factories nach
dem projecttyp fragen und für jeden eine Action erstellen.
K3b selber benutzt dann nicht den Wrapper, sondern macht alles selber. Das hieße redundanten Code in K3b und dem
Wrapper.
Audiodoc:
tracks und files.
ein track kann mehrere files enthalten
ein file kann vorne und hinten abgeschnitten werden
tracks können zusammengeführt werden (resultiert in einem track mit den files aus den beiden quelltracks)
es gibt track- und filefilter; trackfilter sind das gewohnte und sollten meist benutzt werden, filefilter
filtern nur innerhalb eines tracks (Bsp: normalising nur über alle files in einem track, wohingegen
normalising als trackfilter über alle tracks normalisiert)
Das normale verhalten ist wie jetzt: Anlegen eines Tracks mit einem File. Das sollte für die meisten
Anwender reichen. Wenn ctrl oder sowas gehalten wird kann man files zu einem track hinzufügen
(die gui könnte hier beim drücken von ctrl alle files als kindelemente der tracks anzeigen, auch bei
solchen tracks, die nur ein file enthalten. So würde deutlich, dass ein file zu einem track hinzugefügt
werden kann.)
K3bFileSystem:
K3bFsItem
-> K3bFsFile
-> K3bFsDirectory
FileSystem bietet virtuelle Funktionen newFile( filename ) und newDirectory( name ), mit welchen neue
Elemente von den addUrl Funktionen angelegt werden. Jedes Item hat eine size methode, welche die Größe
der Datei angibt. Zusätzlich gibt es eine methode, welche die Gesamtgröße aller Kinder und Enkel angibt
(nur sinnvoll für K3bFsDirectory)
K3bFileSystem hat zusätzlich ein caching-system, welches inode-basierte Größenberechung erlaubt.
K3bFsItem hat methoden wie isDir() und einen void Zeiger für zusätzliche Daten, wenn man nicht ableiten
möchte.
Von K3bFileSystem könnte man K3bIso9660FileSystem und K3bUdfFileSystem ableiten, welche zusätzliche Daten
enthalten.
|
