From 50b48aec6ddd451a6d1709c0942477b503457663 Mon Sep 17 00:00:00 2001 From: tpearson Date: Wed, 3 Feb 2010 02:15:56 +0000 Subject: Added abandoned KDE3 version of K3B git-svn-id: svn://anonsvn.kde.org/home/kde/branches/trinity/applications/k3b@1084400 283d02a7-25f6-0310-bc7c-ecb5cbfe19da --- src/IDEAS | 45 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 45 insertions(+) create mode 100644 src/IDEAS (limited to 'src/IDEAS') diff --git a/src/IDEAS b/src/IDEAS new file mode 100644 index 0000000..f8a2f9c --- /dev/null +++ b/src/IDEAS @@ -0,0 +1,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. \ No newline at end of file -- cgit v1.2.3