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.