summaryrefslogtreecommitdiffstats
path: root/src/IDEAS
blob: f8a2f9c9b9da12567525a83fdba75811d9742de1 (plain)
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.