|
|
|
|
|
wie in KOffice K3bDoc von KParts::ReadWritePart ableiten
|
|
|
|
|
|
in KOffice ist der view von KParts::PartBase abgeleitet. Warum das?
|
|
|
|
|
|
alle actions, die das doc <20>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<65>tigt wird, mehr Sinn. Das hie<69>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<65>tigte K3bDoc im Speicher ist.
|
|
|
|
|
|
Der Wrapper muss dann nur den externalbin- und den devicemanager initialisieren und den kostore <20>ffnen. Dann alle
|
|
|
|
|
|
K3bDocFactories (wenn ein K3bDoc als eine Art plugin dynamisch hinzugeladen werden soll) fragen, ob sie
|
|
|
|
|
|
den projekttyp unterst<73>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<69>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<65>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 <20>ber alle files in einem track, wohingegen
|
|
|
|
|
|
normalising als trackfilter <20>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<75>gen
|
|
|
|
|
|
(die gui k<>nnte hier beim dr<64>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<65>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<47><72>e
|
|
|
|
|
|
der Datei angibt. Zus<75>tzlich gibt es eine methode, welche die Gesamtgr<67><72>e aller Kinder und Enkel angibt
|
|
|
|
|
|
(nur sinnvoll f<>r K3bFsDirectory)
|
|
|
|
|
|
K3bFileSystem hat zus<75>tzlich ein caching-system, welches inode-basierte Gr<47><72>enberechung erlaubt.
|
|
|
|
|
|
K3bFsItem hat methoden wie isDir() und einen void Zeiger f<>r zus<75>tzliche Daten, wenn man nicht ableiten
|
|
|
|
|
|
m<>chte.
|
|
|
|
|
|
Von K3bFileSystem k<>nnte man K3bIso9660FileSystem und K3bUdfFileSystem ableiten, welche zus<75>tzliche Daten
|
|
|
|
|
|
enthalten.
|
