Warum eine Galerie zu KistePix?
KistePix ist ein Editor, die Galerie ein Katalog. Die Faustregel: Ein Editor arbeitet an einem Ding zur Zeit — öffnen, malen, speichern; seine Datenhaltung sind die Bilddateien. Ein Katalog stellt Fragen quer über viele Dinge: „alle Landschaften, nach Datum sortiert". Deshalb hat die Galerie eine echte Datenbank und KistePix keine. Zusammen ergeben sie ein rundes Paar: in KistePix malen, mit einem Klick an die Galerie senden, dort sammeln und für Spiele-Engines exportieren.
So gebaut
Die Pixel-Galerie ist ein reines Kiste-Programm. Sie nutzt db
(SQLite — die Bibliothek mit Titeln, Sammlungen und Datum), bild
(Miniaturen und Farb-Analyse), gui (die ganze Oberfläche auf einer
elastischen Leinwand), pack (ZIP-Export) sowie datei,
pfad und json.
Was drinsteckt
- Eine echte Bibliothek: die Galerie besitzt ihre Werke (Aufnehmen kopiert, Löschen löscht) — im Benutzerordner, also installierbar
- Sammlungen anlegen, umbenennen, löschen; ein Werk kann in mehreren liegen
- Live-Suche beim Tippen, Sortieren nach Name, Datum, Größe
- Werke nach Datum als Kalender-Heatmap und Größen-Verteilung
- Export: ZIP, Sprite-Sheet (mit Aseprite-JSON), animiertes GIF und
Farbpaletten (
.gplund.kpal) - KistePix-Briefkasten: fertige Werke wandern per „An Galerie senden" herüber
Ein Katalog fragt quer über alles
Suchen, Filtern und Sortieren sind keine Handarbeit, sondern eine Datenbank-Abfrage. Deshalb bleibt die Live-Suche auch bei vielen Werken sofort.
// Die Galerie ist ein KATALOG: sie fragt quer über alle Werke.
// Suchen, Filtern und Sortieren sind eine einzige SQL-Zeile —
// bei ein paar hundert Werken unmessbar schnell.
nimm werke = db.abfrage(d,
"SELECT id, datei, titel, breite, höhe FROM werke " +
"WHERE titel LIKE :q ORDER BY erstellt_unix DESC",
{"q": "%" + suche + "%"})Die Bibliothek besitzt ihre Werke
Aufnehmen heißt kopieren — die Galerie legt eine eigene Kopie in ihre Bibliothek und merkt sie sich in der Datenbank. Das Original, wo auch immer es liegt, wird nicht angefasst. Löschen entfernt die Kopie, nicht dein Bild anderswo.
// Aufnehmen heißt KOPIEREN: die Galerie besitzt ihre Werke.
// Das Original irgendwo auf dem PC bleibt unangetastet.
funktion nimm_auf(d, quelle, titel, sammlung, wann) {
nimm name = freier_name(pfad.dateiname(quelle))
datei.kopiere(quelle, werk_pfad(name)) // in die Bibliothek
nimm b = bild.lade(werk_pfad(name))
db.ausführe(d, "INSERT INTO werke (datei, titel, breite, höhe, " +
"erstellt_unix) VALUES (:d, :t, :b, :h, :u)",
{"d": name, "t": titel, "b": bild.breite(b), "h": bild.höhe(b), "u": wann})
}Der Briefkasten zu KistePix
Die zwei Programme teilen sich keinen Zustand. KistePix legt ein Bild samt kleinem Zettel (dem Titel) in einen Briefkasten; die Galerie holt es beim Start ab und verschiebt es in ihre Sammlung. Lose gekoppelt, robust — jedes Programm läuft auch ohne das andere.
// KistePix legt fertige Werke in den Briefkasten. Die Galerie holt
// sie beim Start ab und VERSCHIEBT sie in die Bibliothek — kein
// gemeinsamer Zustand, beide Programme laufen auch für sich allein.
funktion briefkasten_leeren(d) {
wiederhole name in datei.einträge(briefkasten()) {
wenn text.endet_mit(name, ".png") {
nimm titel = text.beschnitten(datei.inhalt(zettel_zu(name)))
nimm_auf(d, quelle, titel, "Ohne Sammlung", datei.geändert_unix(quelle))
datei.lösche(quelle) // verschoben, nicht kopiert → leerer Eingang
}
}
}Die Pixel-Galerie zeigt die andere Seite von Kiste: nicht ein einzelnes großes Werkzeug, sondern ein Ökosystem — zwei Programme, die zusammenspielen, jedes für sich offen zum Anschauen, Verändern und Selber-Bauen.