Ontwikkeling

Tussen januari 2022 en maart 2026 landde Ansel 297 niet-merge commits met betrekking tot het lichttafel-raster, de miniaturen daarvan en hun renderpipeline en caching. Ik heb geprobeerd het zo lang mogelijk uit te houden met de sjofele Darktable-lichttafelcode, alleen ontvet, maar helaas was het pure technische schuld en het was pijnlijk traag.

Darktable „beheert" namelijk de belabberdheid van zijn lichttafel door de omvang ervan te verkleinen: de linker- en rechterzijpanelen nemen veel weergaveoppervlak in beslag, waardoor er nog minder ruimte overblijft voor de lichttafel om opnieuw te tekenen. Sinds Ansel het rechterzijpaneel verwijderde en de inhoud daarvan samenvoegde met het linkerpaneel en het globale menu, was er meer oppervlak om te tekenen, meer CPU-werk te doen, en werd het verschrikkelijke ontwerp van de lichttafel des te schadelijker.

In december 2019 vroeg ik of iemand ervoor wilde zorgen dat er AppImage-pakketten werden aangeboden  voor Darktable. Het voor de hand liggende voordeel zou zijn geweest dat vroeg testen mogelijk werd, vóór de uitgave, door mensen die de broncode niet zelf kunnen bouwen, om zo hopelijk vroege feedback te geven en te helpen met debuggen voordat er werd uitgegeven. Dit is nooit een prioriteit geweest, wat betekende dat het prima was om zowel vóór de uitgave als na de uitgave in een stormloop bugs te moeten fixen.

Ansel erft van Darktable de ruggengraat van zijn database: de niet-destructieve bewerkingsgeschiedenissen worden per foto opgeslagen in een SQLite-database, samen met metadata en andere door de gebruiker gedefinieerde gegevens. De database bewust maken van nieuwe foto’s gebeurt door foto’s te „importeren" van een schijf of een geheugenkaart. Daar komt de importtool in beeld.

Helaas is de Darktable-importeur nog zoiets dat rond 2020 werd verminkt en omgevormd tot iets diep verontrustends, want het is een bestandsverkenner die op geen enkele eerder bekende bestandsverkenner lijkt, en die erin slaagt om basisfuncties te missen (zoals Ctrl+F of EXIF-voorbeeld) terwijl hij tegelijk overladen is met nutteloze (zie hieronder). Hier verliezen we menig toekomstig gebruiker, en het is nog maar stap 0 van de workflow. Wat een geweldig visitekaartje van wat een „workflow-app" kan doen!

Ik heb heel lang gedacht dat er een of ander noodstopmechanisme op de pixelpipeline zat. Het gebruiksscenario is het volgende:

1. je verandert een moduleparameter,
2. de voorbeeldweergaven (die in het midden van de donkere kamer en de miniatuur in het linkerpaneel, ook gebruikt voor het histogram en de kleurenkiezers) herberekenen hun pipeline om rekening te houden met die verandering,
3. een van de voorbeeldweergaven is klaar met renderen vóór de andere, en het resultaat is duidelijk niet wat je wilde,
4. je verandert de moduleparameter opnieuw, zonder te wachten tot de herberekening klaar is.

In dat geval wil je alle actieve pipelines afbreken, omdat hun uitvoer toch niet gebruikt zal worden, en meteen alles opnieuw beginnen te berekenen met de nieuwe parameters. Alleen doet Darktable dat niet, het laat de pipeline eerst afronden voordat die opnieuw wordt gestart, en gezien de commentaren in de broncode lijkt het een vrij recente regressie te zijn en niet het oorspronkelijk bedoelde gedrag.

Darktable heeft zijn eigen GUI-widgetbibliotheek, voor schuifregelaars en comboboxen (ook wel keuzelijsten of selectievakken genoemd), genaamd Bauhaus (in de broncode staat die in src/bauhaus/bauhaus.c). Hoewel ze Gtk als backend gebruiken, zijn Bauhaus-objecten aangepaste objecten. En zoals veel dingen in Darktable geldt: aangepast staat gelijk aan rot.

In 2022 ‍merkte ik parasitaire hertekeningen en vertragingen  op bij het gebruik ervan, wat tot een frustrerende gebruikerservaring leidde: het hertekenen van de widget leek te wachten tot de herberekeningen van de pipeline waren voltooid, wat betekende dat gebruikers niet echt zeker wisten of hun waardewijziging was geregistreerd, waardoor ze het opnieuw konden proberen en zo een nieuwe cyclus van dure herberekening startten, en hun computer effectief enkele zeer frustrerende minuten bevroren met nutteloze tussentijdse herberekeningen van de pipeline.

Ik ontdekte per ongeluk dat het Linux-buildscript een „package"-build gebruikte, wat betekent dat de CPU-optimalisaties beperkt zijn tot generieke optimalisaties om portable binaries te produceren die op elk x86-64-platform geïnstalleerd kunnen worden. Met „gebruikte" bedoel ik dat de package-build niet expliciet was uitgeschakeld, dus was hij standaard ingeschakeld.

Hoe dan ook, dit is nu standaard uitgeschakeld, aangezien de eigenlijke packages (.exe en .appimage) niet via dat script gebouwd worden, dat in de eerste plaats bedoeld is om eindgebruikers te helpen. Om het vorige gedrag terug te krijgen, zou je het volgende moeten uitvoeren:

2022 was zo slecht wat betreft rommelmails en ruis dat ik ben begonnen met de Virtual Secretary , een Python-framework om intelligente e-mailfilters te schrijven door informatie tussen verschillende bronnen te combineren om te raden wat inkomende e-mails zijn en of ze belangrijk/urgent zijn of niet. Als ik het over rommelmails heb, gaat het ook over Github-meldingen, pings op pixls.us (goddank heb ik mijn account op dat stomme forum opgeheven), YouTube, en directe e-mails van mensen die hopen in het privé wat hulp te krijgen.

Het is ongeveer 3 maanden geleden dat ik „R&Darktable" (wat niemand goed leek te snappen) omdoopte tot „Ansel", vervolgens de domeinnaam kocht en de website vanaf nul opbouwde met Hugo (ik had nog nooit in Golang geprogrammeerd, maar het is grotendeels templatecode).

Daarna besteedde ik in totaal 70 uur om de nightly-pakketbuilds voor Windows en Linux werkend te krijgen voor continuous delivery, iets wat Darktable nooit goed voor elkaar kreeg („je kunt zelf builden, het is niet moeilijk"), om vervolgens de bugtracker te zien ontploffen na de release (niets beter dan de pre-release-sprint aaneenrijgen met een post-release-sprint om je levensverwachting te verkorten).