pr:mlib
Inhaltsverzeichnis
Medienbibliothek
Features
- Portablel (ohne Installation; Daten an frei wählbarer Speicherstelle; Relative Pfadangaben(!))
- Win32 / W2k+
- Verwalten von Video UND Foto in einem Programm (idealerweise aber nicht zwingend auch andere Dateien, z.B. Textdateien oder so)
- Tags (Bonus: Funktion um dann „Ähnliche Dateien“ zu finden)
- Kategorien
- Alben
- Verständnis von Pfaden (und dann auch Browsen danach)
- Umfangreiche Suche, im Idealfall so dass man jede beliebige Information filtern kann
- Notizfunktion zu Alben, Dateisystemobjekten
- Automatischer Import, Tagging (EXIF auslesen)
- Thumbnails für Video selber auswählbar, also „nimm Frame 42 als TN“
- Multi-User fähig: gleichzeitig von mehren Rechnern/Prozessen zugreifen
Systemanforderungen
Lebensdauer des Archivs: 10 aktiv, min. 20 Jahre passiv (=lesbar)
- Datensicherheit
- Standardisierte offene Dateiformate
- XML/JSON
- UTF-8
- JPEG (Grafikstandard in PDF-A, daher garantiert)
- PNG (ODF, ist das ein Archivstandard??)
- Extensive Dokumentation UND/ODER Code-Distribution (Interpretierte Sprachen)
- Ausführbarkeit
- Cross-Platform
- ggf emulierbare Umgebung
- möglichst wenige proprietäre Abhängigkeiten
- Win32/Wine
- Python?
- XULRunner mit Hacks damit er portable wird (JS und XUL sind standardisiert)
- Self-Contained
- nicht nur portabel, sondern sollte alles enthalten was man braucht
GUI
- Bedienbares UI. Meine Erfahrung ist ja, dass die besten Programme immer das schlimmste UI haben…
- Thumbnail-View von allem, also auch Suchergebnissen
- Operationen auch auf mehreren Dateien gleichzeitig
- Exif neu lesen
- Thumbnails neu generieren
- mehreren Dateien ein Tag geben
Views
- Listentypen
- Liste („besseres dir“)
- Miniaturen
- Miniaturen mit Details
- Galerie (Miniaturen als Coverflow oben/links)
- Einzelansicht (voriges/nächstes links/rechts klein)
- Fenster
- Suchergebnisse
- Verzeichnis (Tree + Liste)
- Verzeichnis durchsuchen/aktualisieren
- Merge neuer/vorhandener Daten, basierend auf „file“-Tupel
- Detailansicht
- Tabs mit Daten, ähnlich ACDSee 5
- Kann gedockt sein oder als Extrafenster
Tech Details/Implementationsideen
- FlatDB Key-Value-Store, Dateien indiziert über (Name, Pfad, ÄnderungsDatum, ErstellDatum, Größe, InhaltsHash)
- wäre auch wiedererkennbar, wenn extern verändert (closest match)
{"file":{"name": "abc.jpg","path":"foo\\bar\\baz","mdate":"1234567890","cdate":"1234567000","size":"555123","sha1":"abcdef12abcdef12abcdef12abcdef12"}}
Organisationsstruktur
- Archivgruppe
- Bibliothek (enthält auch Voreinstellungen) library.json
- Datenbank (FlatDB-Ordner)
- Dokumente: Metadaten
- Bibliothek …
Klassen
- Application
- Interface zur Hauptanwendung (Logger etc)
- MetadataExtractor
- Bekommt Datei, Füllt SuperObject
- Beispiele: ExifReader, Thumbnail, VideoThumbnail, Geotagger
- MetadataViewer
- Zeigt einen Tab in Detailansicht an
- Beispiele: ExifViewer, VideoThumbnailSetter, Geotagger
- Viewer
- Bekommt Datei, erzeugt daraus einen Renderer passend zum Datentyp
- RendererStill
- Stellt Bildausschnitte auf einem Canvas dar (ImageViewer)
- RendererOther
- bekommt ein WindowHandle, kann darauf passende Controls erstellen (VideoPlayer)
Global ist ein Plugin immer nur ein Objekt, dessen Methoden aufgerufen werden (also SideEffect-frei sein müssen). Es können aber beliebig viele Schnittstellen implementiert werden (Pflicht: IMediaLibraryModule)
Alle Klassen sind auch extern ladbar, aber schon an Delphi gebunden. Keine besondere CallingConvention also.
In Main: Initializatzion→ RegisterClass(TImplementor.Create)
Extern: DLL-Load→ DLL.Register(@RegisterFunction), DLL ruft RegisterFunction mit Instanzen von dem was sie hat auf. (BPL, nur besser)
RegisterClass prüft, ob IMediaLibraryModule implementiert wird; Ruft IMediaLibraryModule.Init auf und übergibt IMediaLibraryApplication.
pr/mlib.txt · Zuletzt geändert: 2011/10/29 20:16 von martok