Was sind Metadaten?

Verfasst am: Dienstag, 17. Mai. 2011 um 22:48

An der einen oder anderen Stelle hier im Blog habe ich bereits den Begriff  Metadaten verwendet. So richtig erklärt habe ich ihn allerdings noch nicht. Da die Metadaten mit der heute veröffentlichten neuen Programmversion langsam den Weg ins Programm finden, ist es ein guter Zeitpunkt, die Erklärung  jetzt nachzureichen.

Vorweg allerdings noch der Hinweis, das mit der neuen Version eine klitzekleine Datenbankänderung vorgenommen wurde. Es ist also wieder notwendig, die Datenbankstruktur zu aktualisieren. Die neue, dafür notwendige Workbench-Projektdatei befindet sich wieder im Unterverzeichnis „db“ des Programmverzeichnisses.

Was sind also nun die ominösen Metadaten?

Normalerweise ist es bei Bildverwaltungen so, das der Anwender nachdem er Bilder in der Datenbank importiert hat, diesen Bildern Fotoalben und/oder Schlagworte zuordnen kann. Die Zuordnung erfolgt manuell durch den Anwender und erfordert viel Zeit und Ausdauer. Das BVASystem möchte genau den umgekehrten Weg gehen. Nachdem ein Fotoalbum oder Schlagwort erstellt wurde, soll der Anwender eine Reihe von Kritieren festlegen können, die beschreiben, wann ein Bild zu dem Album bzw. Schlagwort gehört. Diese Kritieren, die unterschiedlicher Struktur sein können, bezeichne ich als Metadaten.

Die festgelegten Metadaten sollen vom Programm beim Bildimport dazu dienen, das die Bilder gleich automatisch den entsprechenden Fotoalben bzw. Schlagworten zugeordnet werden. Dadurch möchte ich erreichen, das der Anwender viel Arbeit spart. Es ist nicht mehr notwendig, für jedes Bild festzulegen wohin es gehört. Schlussendlich soll der Anwender beim Betrachten seiner Bilder nur noch, eventuell vorhandene, falsche Zuordnungen korrigieren.

Im einfachsten Fall nutzt man für ein Fotoalbum nur die Metainformation des Aufnahmedatums aus. Tante Trudes Geburtstag war halt am 16. Mai 2011. Alle Bilder, die nicht am 16. Mai aufgenommen worden sind, können also nicht von Tante Trudes Geburtstag stammen. Im Umkehrschluss sind also alle Bilder, die am 16. Mai aufgenommen wurden, von Tante Trudes Geburtstag.

Kompliziertere Zuordnungen sind natürlich denkbar. Alle Fotos die im Umkreis von 52° 31′ N, 13° 24′ O aufgenommen wurden, sind in Berlin gemacht. Alle Bilder, auf denen sich ein Gesicht befindet, sind Portraits. Alle Bilder, auf denen sich eine Horizont-Linie finden lässt, sind Landschaftsbilder. Alle Bilder, die nachts aufgenommen wurden und deren vorherrschende Farbe schwarz ist, sind Nachtaufnahmen. Generell sind der Phantasie hier keine Grenzen gesetzt.

Was ist davon bisher umgesetzt?

Mit dem Dialog zum Erstellen eines Fotoalbums war ich bisher ja nicht richtig zufrieden. Daher hat dieser Dialog nun eine komplett neue Oberfläche erhalten. In der neuen Oberfläche kann nun ausgewählt werden, welche Metadaten zu dem Fotoalbum gehören. Umgesetzt habe ich 2 Metadatentypen (Aufnahmedatum und Bildbesitzer), die in beliebiger Anzahl ausgewählt werden können. In der linken unteren Ecke des Dialoges gibt es eine Testfunktion, die die Metadaten in einem XML-Format abspeichert. In der Datenbank werden die Metadaten noch nicht abgelegt.

Eine Metadatendatei könnte wie folgt aussehen:

<?xml version="1.0" encoding="ISO-8859-1"?>
<metadata>
 <name>Album_Mosel_2011</name>
 <elemente>
  <element typ="0">
   <mindate>10.05.2011</mindate>
   <maxdate>20.05.2011</maxdate>
  </element>
  <element typ="1">
   <owner>Marc</owner>
  </element>
 </elemente>
</metadata>

In der nächsten Programmversion werde ich mich darum kümmern, das das Hauptmenü und die PopUp – Menüs wieder klarer strukturiert sind. Durch die Einführung der 3 Ansichtmodi ist die klare Struktur leider verloren gegangen, so das eine Anpassung notwendig wird.

Außerdem werde ich mich natürlich darum kümmern, die Metadatenfunktionalität weiter auszubauen. Bei dem Metadatentyp Bildbesitzer muss die Auswahlliste der möglichen Bildbesitzer gefüllt werden. Die Metadaten müssen natürlich in der Datenbank gespeichert werden. Eine Auswahlliste der verfügbaren Metadatendefinitionen muss ebenfalls gefüllt werden. Beim Editieren müssen die Metadatendefinitionen wieder geladen werden …. usw. Es gibt noch viel zu tun bis die Metadaten richtig genutzt werden können. Ich hoffe, das sich der Aufwand trotzdem lohnen wird.

Scrollbars einer TScrollbox

Verfasst am: Dienstag, 10. Mai. 2011 um 21:55

In der letzten Zeit scheinen sich die Delphi Problemchen wieder zu häufen. Dieses mal hat mich die TScrollbox fast 2 Tage gekostet. Aber der Reihe nach:

Ich bin gerade dabei, eine Komponente zu entwickeln, mit der Metadaten, die zu einem Fotoalbum gehören, definiert werden können. Da eine beliebige Anzahl von Metadaten definiert werden kann, ist es notwendig, die jeweiligen Steuerelemente in eine Scrollbox anzuordnen.

Da es die erste TScrollbox ist, die ich im BVASystem benutze, fiel mir gleich ein grundlegendes Problem auf: Die Scrollbars der Scrollbox sahen optisch anders aus, als die in den selbstgeschriebenen Komponenten.

In Delphi 2005  sehen  die Steuerelemente standardmäßig so aus wie unter Windows 2000. Durch das Einbinden der Komponente TXPManifest kann das Aussehen auf den XP Style umgestellt werden.

Durch die selbstgeschriebenen Komponenten habe ich bisher darauf verzichtet, das Manifest in die Bilddatenbank zu integrieren. Es gab zu viele unschöne Effekte, die ich hätte korrigieren müssen. Außerdem finde ich es unschön, wenn das komplett in Brauntönen gehaltene Design durch blaue Scrollbars gestört wird.

Das Problem bei der TScrollbox war nun, das die Scrollbars der Scrollbox automatisch im XP-Style sind, auch wenn kein Manifest eingebunden wurde. Warum das so ist, habe ich leider nicht herrausfinden können. Aber ich habe eine Möglichkeit gefunden, wie man den XP-Style der Scrollbox wieder deaktivieren kann:

SetWindowTheme(Scrollbox.Handle, '', '');

Mit diesem schnöden Einzeiler sind die Scrollbars zumindest erstmal wieder einheitlich. Früher oder später, werde ich mich allerdings damit auseinander setzen müssen, wie ich mit der Oberflächengestaltung weiter umgehen werde. Wirklich toll sehen die Scrollbars bei deaktiviertem XP-Style nicht aus. Schlussendlich bleiben 2 Möglichkeiten: 1. Eigene hübschere Scrollbars entwickeln oder 2. den XP-Style Anwendungsweit aktivieren.

Bugfixes Teil 2

Verfasst am: Donnerstag, 05. Mai. 2011 um 07:37

Nach der letzten Bugfix-Version steht heute nun die nächste Version an, wo ich aber eigentlich ehrlich zugeben muss, das sie im strengen Sinne keine reine Bugfix-Version ist.

Bei der Einführung des Workers habe ich mir gedacht, das es sinnvoll ist, wenn der Anwender über den Status des Workers informiert wird. Welche Aufgaben stehen im Worker? Welche Aufgaben hat der Worker ausgeführt? Bei welchen Aufgaben im Worker ist ein Fehler aufgetreten?

Um die Fragen zu beantworten, hatte ich schon damals einen Dialog in das Programm integriert, der mit einem Klick auf die „Ampel“ des Workers geöffnet werden kann. Bis zum heutigen Tag war dieser Dialog allerdings leer. Von daher kann es entfernt vielleicht doch als Bugfix bezeichnt werden, wenn dieser Dialog nun nicht mehr leer ist.

Wenn der Statusdialog des Workers geöffnet wird, so wird als erstes der Worker pausiert. Solange der Dialog angezeigt wird, werden also keinerlei Aufgaben erledigt. Wenn der Dialog geschlossen wird, nimmt der Worker seine Arbeit wieder auf. Der Dialog selber unterteilt sich in 2 Bereiche. In dem ersten Bereich sieht man, welche Aufgaben noch im Worker aktiv sind, während im zweiten Bereich angezeigt wird, welche Aufgaben bereits abgeschlossen wurden.

Statusdialog des Workers

Statusdialog des Workers

Weiterhin neu ist auch der Info-Dialog, in dem abgelesen werden kann, welche Version gerade verwendet wird. Außerdem steht dort ein Verweis auf diese Seite. Neben den Neuerungen habe ich, wie es der Name dieses Artikel bereits vermuten lässt, einige Bugs beseitigt. Wie immer kann die genaue Liste der abgearbeiteten Punkte im Bugtracker analysiert werden.

Als kleine Vorschau auf die nächste Version gibt es zu sagen, das ein klitzekleines Datenbankupdate erfolgen wird. Damit werde ich dann in der Lage sein, die Fotoalben weiter zu erweitern. Außerdem möchte ich, sofern ich es zeitlich noch schaffe, die Funktionen in den Popup-Menüs leicht anders anordnen, da sie nach der Einführung der 3 Ansichtsmodi nicht mehr so klar getrennt sind wie zuvor.

Fehler in TShellTreeView, TShellComboBox und TShellListView

Verfasst am: Samstag, 30. Apr. 2011 um 21:33

Meinen letzten Artikel, den ich einem Delphi-Problem gewidmet habe, liegt schon einige Monate zurück. Da ich beim Testen auf ein größeres Problem gestoßen bin und auch recht lange gebraucht habe um das Problem zu lösen, bietet es sich an, die Lösung des Problemes hier vorzustellen.

In Delphi 2005 gibt es 2 Sets an Komponenten, die es ermöglichen, einen Dateiauswahl-Dialog recht schnell zusammenzubauen. TDriveCombobox, TDirectoryListBox und TFileListbox sind noch aus den guten alten Windows 3.1 Zeiten vorhanden. Von der Optik her würde ich heute diese Komponenten nicht mehr einsetzen. Als zweites Set haben TShellTreeView, TShellComboBox und TShellListView in der Komponentenliste Platz gefunden. Allerdings werden sie etwas stiefmütterlich behandelt und befinden sich in meiner Delphi 2005 Version nur unter der Komponentenkategorie „Beispiele“.

Im BVASystem habe ich den TShelltreeview und die TShellComboBox genutzt, um den Dialog zur Auswahl des Dateinamens zur Speicherung eines Fotoindexes zu realisieren. Beim Testen ist mir dann aufgefallen, das die Komponenten unter Windows XP für Verzeichnisse, die auf einer CD liegen, teilweise falsche Pfadangaben zurückgeben.  Es werden nur dann richtige Pfadangaben geliefert, wenn das Verzeichnis kein Unterverzeichnis ist. „D:\Bilder\“ klappt also, während für „D:\Bilder\2011-04-29\“  nur „D:\Bilder\“ zurückgegeben wird.

Ok, für die Auswahl eines Speicherortes kann man wohl getrost auf das CD-Rom Laufwerk verzichten. Aber da ich vor habe, die Komponenten auch anderweitig zu verwenden, hat mich das Problem nicht mehr losgelassen.

Die Ursache des Problems konnte ich in der Klasse TShellFolder und dort genau in der Funktion „PathName“ finden. Zur Korrektur des Fehlers muss die Funktion, die sich in der „ShellCtrls.pas“ befindet, folgendermaßen geändert werden:

function TShellFolder.PathName: string;
begin
 result := GetDisplayName(ParentShellFolder, FPIDL, SHGDN_FORPARSING);
 //Result := GetDisplayName(DesktopShellFolder, FFullPIDL,  SHGDN_FORPARSING );
end

Wenn man dann die „ShellCtrls.pas“ schon offen hat, bietet es sich auch an, gleich ein paar Speicherlecks, die die Komponenten haben, zu schließen. Wie die Speicherlecks beseitigt werden, könnt ihr in der QualityCentral von Embarcadero nachlesen. Dort hat Brad Prendergast seine Lösung detailiert in den Kommentaren beschrieben.

Jede Menge kleine Bugfixes

Verfasst am: Donnerstag, 14. Apr. 2011 um 22:17

Nachdem es in den letzten 2 Programmversionen viele neue Funktionen gegeben hat, ist es nun angebracht, entstandene Fehler und aufgeschobene Details nachzuholen.

Die auffälligste Änderung im Programm ist bereits hier auf der Homepage erkennbar. Ich habe den Startbildschirm und das Logo auf dieser Homepage vereinheitlicht. Das Logo, welches ich bisher nur im Icon des Programmes benutzt habe, hat nun Platz auf dem Startbildschirm gefunden. Die neue Schriftart habe ich so ausgewählt, das sie gut zu dem Logo passt. Ich bin jedenfalls mit dem neuen Design zufriedener, da es ruhig wirkt.

Neuer Startbildschrim der Bilddatenbank

Neuer Startbildschrim der Bilddatenbank

Jetzt hier auf jeden einzelnen Punkt einzugehen, den ich abgearbeitet habe, ist wohl überflüssig. Daher nenne ich nun nur kurz die größeren Änderungen:

  • das übergeordnete Fotoalbum wird nun in dem Dialog zur Erstellung/Veränderung eines Fotoalbums angezeigt (siehe: Der Rohbau der Fotoalben steht)
  • das bekannte Popup-Menü aus der Filmstreifen Ansicht ist nun auch in der Miniaturbilder Ansicht vorhanden
    die gewünschte Ansicht, mit der das Programm gestartet werden soll, kann in der Ini-Datei eingestellt werden (siehe: Ticket 162)
  • im Optionsdialog zur Speicherung eines Fotoindexes habe ich die Edit-Komponenten durch eine selbstgeschriebene Komponente ersetzt, mit der die Bildgrößen besser eingestellt werden können

Für die nächste Version steht eigentlich wieder das gleiche an. Es sind noch eine Menge kleinerer Tickets offen, die wenn ich sie nicht auf einmal angehe, wohl viel zu lange liegen bleiben würden. Und in rund 14 Tagen steht dann hier also ein weiterer Blog: „Jede Menge kleine Bugfixes 2“

Update der Funktionen des Bildbetrachter-Moduls

Verfasst am: Sonntag, 03. Apr. 2011 um 22:38

Im Jahresfazit des letzten Jahres hatte ich angekündigt, das ich dieses Jahr hauptsächlich damit verbringen werde, die Datenbankfunktionalitäten des BVASystems auszubauen. Daher ist die neue Programmversion, die ab heute zum Download bereit steht, etwas ganz besonderes. Neu hinzugekommen sind nämlich 2 neue Ansichtsmodi, die sowohl im Bildbetrachtermodul, als auch im Datenbankmodul nutzbar sind.

Sucht man in einer Bildliste, die rund 100 Bilder enthält, ein spezielles Bild, so war es bisher nur möglich, das Foto durch ein langsames Durchblättern der Bildliste aufzufinden. In der neuen Miniaturbilder-Ansicht wird der gesammte rechte Bereich der Anwendung dazu genutzt, kleine Miniaturbilder anzuzeigen. Dadurch passen natürlich mehr Fotos auf den Anzeigebereich und die Suche nach einem Bild in der Liste gestaltet sich einfacher. Kurz: Man gewinnt leichter einen Überblick über die Fotos.

Miniaturbilder-Ansicht der Bilddatenbank BVASystem

Miniaturbilder-Ansicht der Bilddatenbank BVASystem

Konsequenterweise habe ich einen dritten Ansichtsmodus implementiert, in dem nur  das große Vorschaubild angezeigt wird. Wie in der altbekannten Oberfläche gibt es unter dem Vorschaubild eine Funktionsleiste, mit der auch ohne Bildliste navigiert werden kann.

Die Ansichtsmodi kann man wechseln, indem man die entsprechenden Buttons im oberen Teil der Ansichten anklickt. Außerdem kann mit den Funktionstasten F5, F6 und F7 zwischen den Ansichtsmodi gewechselt werden. Beim Wechsel von einem Modus zum nächsten, wird das aktuell aktive Foto übernommen. Es ist also möglich, sich ein Bild in der Matrix herrauszusuchen, um es anschließend in der Einzelbildansicht möglichst groß anzuzeigen.

Wie auch beim letzten Update sind die neuen Funktionen nur in einer Rohbaufassung fertig. In der nächsten Version wird also nichts wirklich neues weltbewegendes dazukommen. Ich werde mich stattdessen damit beschäftigen, vorhandene Fehler zu beseitigen. Es passt von daher auch ganz gut, das mein Cheftester gerade eine Menge neue Tickets eingestellt hat, die ich dann so gut es geht ebenfalls bearbeiten werden.

Ordnungsprinzipien

Verfasst am: Montag, 28. Mrz. 2011 um 21:07

Gerade jetzt, wo die Implementation der Fotoalben schon relativ weit vorrangeschritten ist, ist ein guter Zeitpunkt sich Gedanken darüber zu machen, nach welchen Prinzipien Ordnung in die Bilderflut gebracht werden kann. Durch die Fotoalben hat das BVASystem ein flexibles System erhalten, mit der Anwender fast jedes Ordnungsystem manuell umsetzen können. Trotzdem ist es angebracht, zu schauen, welche weit verbreiteten Prinzipien  in das Programm zusätzlich implementiert werden können, damit sich diese mit wenig Aufwand nutzen lassen.

Welche Ordnungsprinzipien gibt es?

Weit verbreitet ist zum Beispiel ein relativ einfaches System, bei dem die Bilder zeitlich geordnet werden. Die Bilder, die an einem Tag aufgenommen wurden, werden einfach in einem Ordner gespeichert. Zur besseren Übersicht können die Ordner monats- bzw jahresweise zusammengefasst werden. Dieses einfache System hat den Vorteil, das sich niemals neue und alte Bilder miteinander vermischen. Es kommen immer nur weitere Ordner dazu, der Inhalt der bestehenden Ordner bleibt immer gleich. Das Auffinden eines speziellen Bildes gestaltet sich allerdings schwierig, wenn man nicht ungefähr weiß, wann das Bild aufgenommen wurde.

Ebenfalls weit verbreitet ist ein Ordnungssystem, welches auf dem Bildinhalt basiert.  Jedes einzelne Bild wird dabei durch eine Anzahl einzelner Schlagwörter verknüpft. Wenn man den Aufwand nicht scheut, wird man damit belohnt, das Bilder, die thematisch zusammengehören ohne größere Probleme lokalisiert werden können. Neben dem hohen Aufwand hat dieses System aber auch Nachteile. Nicht ganz einfach ist das Festlegen der Schlagworte, denn diese müssen aussagekräftig und auch bei späteren Verschlagwortungen von ähnlichen Bildern wieder gleich sein. Es nützt zum Beispiel relativ wenig, wenn die Hälfte der Bilder mit dem Schlagwort „Spatz“ und die andere Hälfte mit „Feldsperling“ versehen wurde. Logische Problemlösung dafür ist eigentlich, alle Bilder mit den Schlagworten „Spatz“ und „Feldsperling“ zu versehen. Damit steigt allerdings der Aufwand für die Verschlagwortung weiter an und trotzdem ist die Gefahr, kein Schlagwort vergessen zu haben, nicht ausgeschlossen.

Ein weiteres Prinzip ist nutzbar, wenn zu den Bildern GPS-Informationen vorhanden sind. Dann können Bilder, die am gleichen Ort aufgenommen wurden, in eine Kategorie geordnet werden. Vorteilhaft ist, das dabei Kartenansichten erzeugt werden können, in denen man relativ leicht navigieren kann. Für die Suche nach Bildinhalten bringt das System nur dann Vorteile, wenn sich der Bildinhalt eindeutig lokalsieren lässt. Das „Brandenburger Tor“ kann eben nur in Berlin aufgenommen werden, ein „Spatz“ findet man dagegen wohl in jeder deutschen Stadt.

Als viertes System könnten automatisch bestimmte Parameter genutzt werden. Es könnten Beispielsweise alle Bilder nach ihrer vorherschenden Farbe geordnet werden. Alle Bilder einer Banane würden so in die Kategorie „gelb“ eingeordnet werden. Vorteil eines solchen Systems ist, das es ohne großen Aufwand umgestetzt werden kann. Leider ist es aufgrund automatischer Parameter nicht möglich den Inhalt des Bildes zu erkennen.  Nicht alle „gelben“ Bilder zeigen Bananen und alle Bananen sind auch nicht „gelb“. Unreife Bananen sind „grün“ und würden leider in einer anderen Kategorie landen.

Weiterhin könnten Bilder noch nach Parametern geordnet werden, die während der Bildaufnahme mit gespeichert werden. Solche Parameter wären zum Beispiel: verwendete Kamera, Brennweite oder Belichtungszeit. Da ich denke, das solche Systeme kaum genutzt werden, werde ich darauf jetzt nicht weiter eingehen.

Was bedeutet das nun für eine Bilddatenbank und für das BVASystem im Speziellen?

Der große Vorteil einer Bilddatenbank liegt darin, das nicht nur ein Ordnungsprinzip genutzt werden kann. Durch eine Mischung von mehreren Systemen kann das Auffinden eines Bildes erleichtert werden, da die Nachteile der einzelnen Systeme nicht so sehr zum tragen kommen. Vielleicht erinnert man sich an das ungefähre Aufnahmedatum des Bildes, welches man gerade sucht. Oder man hat genau den Ort vor Augen, wo das Bild aufgenommen wurde. Im Idealfall führt jede der Suchanfragen zu dem gesuchten Bild.

Ziel des BVASystems sollte es sein, möglichst alle Ordnungsprinzipien zu ermöglichen. Dabei soll der Anwender aber nicht in ein starres Konzept gepresst werden, welches wahrscheinlich nicht seiner Wunschvorgehensweise entspricht. Es gilt also einen Mittelweg zu finden zwischen einer kompletten Freiheit und einer selbsterklärenden Struktur.

Die Fotoalben sind ein erster Schritt um dieses Ziel zu erreichen. Durch die Fotoalben habe ich dem Anwender ein System geschaffen, mit dem er selbst eine Mischung aus den oben genannten Prinzipien umsetzen kann. Mein Beispielbild aus der Ankündigung der Fotoalben vermischt die Prinzipien der inhaltlichen („Urlaub“) und zeitlichen („Alpen 2002“) Ordnung.

Fotoalben im Rubrikenbaum

Fotoalben im Rubrikenbaum

Weiterhin ist bereits eine fest vorgegebene zeitliche Ordnung nach dem „Aufnahmedatum“ in dem Programm integriert, welches beim Aufbau keinerlei Benutzerinteraktiv benötigt. Das System wird einfach beim Import der Bilder mit erstellt.  In der Zukunft werde ich das BVASystem sicherlich um das eine oder andere fest vorgegebene Ordnungssystem erweitern. Welche das im genauen sein wird, kann ich noch nicht sagen. Ein System zur Verschlagwortung der Bilder wird aber auf jeden Fall mit dabei sein.

Der Rohbau der Fotoalben steht

Verfasst am: Dienstag, 15. Mrz. 2011 um 21:55

Vergleicht man die Softwareentwicklung mit einem Hausbau, so kann ich sagen, dass mit der neuen Programmversion das Zimmer für Fotoalben im Rohbau fertig ist. Generell sind alle Funktionen, die ich geplant hatte, umgesetzt. Es fehlt aber hier und da noch die Tapete, damit das Zimmer wohnlich wird. Um zeigen zu können, was fertig ist und was nicht, möchte ich kurz das Fotoalbum-Konzept vorstellen.

Beim Import eines Bildes in die Datenbank, wird es automatisch an der jeweiligen Stelle im Aufnahmedatumbaum abgelegt. Dadurch kann man recht schön auf Bilder zugreifen, von denen man noch ungefähr in Erinnerung hat, wann sie entstanden sind. Aber wenn man auf der Suche nach einer Bilderserie ist, die man zeitlich nicht mehr so recht zuordnen kann, dann sucht man die berühmte Nadel im Heuhaufen.

Mit den Fotoalben soll die Möglichkeit für eine zweite Ansicht auf den Datenbestand geschaffen werden. Bilder, die während eines Urlaubs gemacht wurden, können zum Beispiel im Fotoalbum „Nordseeurlaub 2011“ abgelegt werden. Damit die Fotoalben übersichtlicher werden, können sie hierarchisch aufgebaut werden. Für das Urlaubsbeispiel heißt dies: Es wird das Fotoalbum „Urlaub“ angelegt und als Unteralbum das Fotoalbum „Nordseeurlaub 2011“. Dort kann dann wiederum ein Unteralbum für jeden Ausflug angelegt werden. In der Art und Weise, wie der Anwender seine Fotoalben anordnet, macht das Programm keinerlei Vorgaben. Wer im Extremfall die  Fotoalben nicht benötigt, benutzt sie einfach nicht.

Um mit den Fotoalben arbeiten zu können, sind mehrere Funktionen notwendig: Es müssen Fotoalben angelegt, umgeändert und gegebenenfalls auch gelöscht werden können. Weiterhin ist es notwendig, das Fotos mit Fotoalben verknüpft werden können. Das Konzept sieht hier vor, das ein Foto auch zu mehreren Fotoalben gehören kann. Und zu guter letzt müssen die Fotos, die einem Album zugeorndet wurden, auch angezeigt werden.

Alle diese Funktionen sind in der neuen Programmversion 2.0.0.18 umgesetzt. Allerdings fehlen noch einige Feinheiten. So ist es zum Beispiel nicht möglich, das übergeordnete Album eines Albums zu verändern. Aktuell wird das übergeordnete Album noch nicht einmal angezeigt. An der einen oder anderen Stelle wird es sicherlich noch Änderungen an der Oberfläche geben, da die jetzige noch nicht perfekt ist.

Eine weitere Idee von mir ist, das alle Bilder, die keinem Fotoalbum zugeordnet wurden, in eine Art „virtuellen Schuhkarton“ geworfen werden, damit man als Anwender leichter sehen kann, welche Bilder noch nicht sortiert worden sind. Eine ganz große Idee, die das Sortieren erleichtern wird, wartet ebenfalls noch auf ihre Umsetzung. Dazu aber erst mehr, wenn ich sie umsetzen werden.

Screenshot der Bilddatenbank BVASystem 2.0.0.18

Screenshot der Bilddatenbank BVASystem 2.0.0.18

Für die nächsten Wochen habe ich mir vorgenommen, die Feinheiten der Fotoalben links liegen zu lassen, um stattdessen den Rohbau für ein weiteres Zimmer erstellen zu können. Beim Benutzen des Programmes ist mir aufgefallen, das die waagerechte Anordnung der Thumbnails nur bedingt geeignet ist, wenn man auf der Suche nach einem bestimmten Bild in der Liste ist. Daher möchte ich eine zweite Ansicht schaffen, in der es kein großes Vorschaubild gibt und der Platz stattdessen für eine Matrix auf Thumbnails genutzt werden kann.

Oberflächenprogrammierung und andere kleine Katastrophen

Verfasst am: Freitag, 04. Mrz. 2011 um 12:32

Die erste kleine Katastrophe gleich vorne weg: Die nächste Version vom BVASystem wird sich etwas verzögern. Zum einen habe ich mir für den Versionssprung recht viel vorgenommen und zum zweiten plagt mich seit einigen Tagen ein Margen-Darm-Infekt. Mal schauen, ob ich den einen oder anderen Punkt in die nächste Version verschieben muss, um den Abstand zwischen den Versionen nicht zu groß werden zu lassen.

Die größere Katastrophe stemmt sich mir allerdings in der Oberflächengestaltung entgegen. Für die nächste BVASystem Version hatte ich mir vorgenommen, einen Dialog zu schaffen, mit dem Fotoalben angelegt und editiert werden können. Grundsätzlich ist der Dialog  ja auch bereits fertig, aber optisch bin ich damit irgendwie noch nicht richtig zufrieden. Auch nach mehreren versuchten Designänderungen bleibt eine gewisse Unzufriedenheit zurück.

Störend empfinde ich zum Beispiel, dass ich die Anzeige des Fotoalbums, welches dem zu erstellenden Fotoalbum übergeordnet ist, noch nicht realisieren konnte. Vorgestellt habe ich mir dort eine ähnliche Darstellung, wie sie neuerdings im Explorer von Windows 7 zu finden ist. Aber natürlich bietet Delphi so eine Darstellung von Hause aus nicht an. Das heißt dann also selber schreiben und selber schreiben heißt Zeit. Aus Angst mich jetzt gänzlich beim Schreiben der Komponente zu verzetteln, habe ich sie erstmal einfach weggelassen bzw. auf später verschoben.

Ähnlich sieht es für den Bereich aus, in dem Metadaten festgelegt werden sollen. Hier ist es aber weniger kritisch, da die Metadaten aktuell eh noch nicht gebraucht werden.

Fazit des ganzen ist also: Oberflächenprogrammierung ist immer aufwendiger als man denkt, braucht meist mehrere Anläufe und macht nicht wirklich Spaß.

Fotoalben

Verfasst am: Sonntag, 20. Feb. 2011 um 23:47

Heute bin ich ziemlich stolz auf mich. In nur 11 Tagen habe ich es diesmal geschafft, den mir selbst gesteckten Plan für die Version 2.0.0.17 abzuarbeiten und das, obwohl ich während der Entwicklung noch auf das eine oder andere kleine Problemchen gestoßen bin.

Größte Neuerung ist natürlich die, für die angekündigten Fotoalben, angepasste Datenbankstruktur. Es ist also mal wieder notwendig, die Datenbankstruktur zu aktualisieren. Die dafür notwendige Workbench-Projektdatei befindet sich, wie immer nach der Installation, im Unterverzeichnis db des Programmverzeichnisses. Ich hoffe, das ich beim Erstellen der Struktur alles bedacht habe und damit in den nächsten Monaten so auskommen werde.

Nachdem die Datenbankstruktur angepasst wurde, können in der ersten Entwicklungsstufe der Fotoalben, mit dem Testbutton in der Menüleiste, Alben angelegt werden. Die angelegten Fotoalben werden anschließend dann im Baum auf der linken Seite angezeigt.

Fotoalben im Rubrikenbaum

Fotoalben im Rubrikenbaum

Nicht wirklich spektalutär, aber ich bin dabei auf ein größeres Problem gestoßen. Ich habe mich ja dazu entschieden, alle Änderungsoperationen über den Worker abzuarbeiten. Wenn nun aber gerade ein Bildimport läuft, dann wird zum Beispiel das neue Fotoalbum erst nach dem Abschluss des Bildimports erstellt.

Da man bei anderen Programmen auch nicht während eines Bildimports andere Sachen tun kann, habe ich mich entschlossen an dem Worker Konzept festzuhalten. Schließlich ist es eine Verbesserung, wenn man sich während des Importes weiter in der Datenbank umsehen kann. Außerdem habe ich aus dem Problem 2 Lehren gezogen: 1. Es muss dem Anwender bei jeder Datenänderung immer ersichtlich sein, das die Änderungen nicht sofort ausgeführt werden. 2. Wenn eine Datenänderung eine Aktualisierung der Oberfläche bewirkt, so darf die Aktualisierung erst nach dem Abschluss der Workeraufgabe erfolgen. Erfolgt die Aktualisierung gleich nach der Erstellung der Workeraufgabe, so kann es dazu kommen, das unglültige Einträge im Baum oder in der Bildliste entstehen.

Um die beiden Punkte nicht auf die lange Bank zu schieben, habe ich sie sofort bei den bestehenden Workeraufgaben korrigiert. Gerade beim Löschen von Bildern musste ich einige Inkonsistenzen verbessern. Ich hoffe, das ich keine Stelle übersehen habe. Falls doch, werde ich sie in einer der nächsten Versionen korrigieren.

Als kleinen Ausblick auf die nächste Version möchte ich auf darauf hinweisen, das ich vorhabe, eine Möglichkeit zu schaffen, mit der Bilder zu Fotoalben zugeordnet werden können. Außerdem habe ich mir vorgenommen, das ein Dialog entsteht, in dem alle Parameter eines Fotoalbums eingestellt werden können. Damit kann der Testknopf aus dem Hauptmenü wieder verschwinden.