Även om jag skrivit program som gör fler och mer avancerade saker än H.VHS, så har inget av dem någonsin blivit så omfattande. Förmodligen beror det inte minst på att jag brukat använda Scheme, medan detta är skrivet i C++, och givetvis att jag än så länge kodar hellre än smart i Qt/C++/Windows-miljön.
Men det ska inlägget inte handla om. När jag hade rivit ut och ersatt mer eller mindre allt som sker bakom kulisserna i programmet, lyckats knyppla ihop hämtningsmetoder för TV3, TV4, TV6 och TV8, och därför trodde mig vara färdig att släppa nästa version, så dök två problem upp.
- TV4 Play vägrade plötsligt komma överens med rtmpdump (och därför även librtmp, som H.VHS använder).
- På en helt färsk dator syntes inga SVG-ikoner i verktygsfälten.
Lösningen på det första problemet var enklare än jag tänkt mig: De senaste, inofficiella versionerna av librtmp har inga problem att hantera "Handshake 9"-problemet, som det visst kallas, så lösningen fick bli att rulla en egen librtmp-dll. Lätt värt besväret, eftersom programmet dessutom blir av med den statiska länkningen till PolarSSL, som är GPL-licensierat, till förmån för OpenSSL, som passar bättre in i licensblandningen.
Det krångligare problemet var att lista ut hur man egentligen får Qt att snällt ladda SVG-grafik. Frågan har ställts massor av gånger på nätet, men inga svar verkar ha hjälpt de stackarna som försökt. Det hela försvåras dessutom av att på datorer där hela Qt finns installerat så fungerar allting som det ska – det är först på användarsidan som felen uppstår.
Så steg ett är att se till att själv drabbas av samma problem redan i produktionsmiljön.
- Infoga följande kod i main().
Det är de tre raderna i krullklasen som gör arbetet. Eftersom det blir stökigt att lagra alla stödfiler direkt i bygg-katalogen (där även alla objektfiler hamnar) så vill jag inte ha det här bekymret annat än när jag bygger en release, som jag sedan kopierar till en katalog ("dist") där QtGui4.dll och alla de andra ligger och väntar.
Med detta uppstår problemet även på min knädator. Nästa steg är förstås att också lösa det.
- SVG-grafik kräver QtSvg4.dll, som i sin tur vill ha QtXml4.dll, så de ska ligga direkt i
dist-katalogen, tillsammans med binären.dist\HuggpunktVHS.exe
dist\QtGui4.dll
…
dist\QtSvg4.dll
dist\QtXml4.dll
Man kunde tro att det skulle räcka – minns jag inte fel så gjorde det faktiskt det någon gång tidigare – men icke!
- Till sist måste ett plugin distribueras tillsammans med binären, och de måste placeras riktigt i förhållande till den. Så här:
dist\imageformats\qsvg4.dll
Det ska räcka. Men beroende på vad man vill göra kan även de följande filerna vara bra att skicka med, inte minst därför att de behövs för att komponenter som QWebView ska kunna använda diverse bildformat:
dist\imageformats\qtiff4.dll
dist\imageformats\qmng4.dll
dist\imageformats\qgif4.dll
dist\imageformats\qico4.dll
dist\imageformats\qjpeg4.dll
dist\iconengines\qsvgicon4.dll
Så principen tycks vara, att när man som i steg 1 sagt åt Qt att enbart leta efter stödfiler i den katalog som binären ligger i, så begränsar sig Qt lydigt till att leta efter sina moduler där. Men när det kommer till plugins, så måste de ändå ligga i korrekta underkataloger till dist-katalogen.
Och vilka de korrekta underkatalogerna är, det ser man för övrigt här:
C:\QtSDK\Desktop\Qt\4.7.3\mingw\plugins
Så här är det inte utan att man börjar fundera på att bygga allting statiskt i stället.
Uppdatering 2 juli. Så pass tveksam kände jag mig efter att faktiskt ha tänkt över det här Qt-knögglet, att jag tänkte om. Någonstans kring version 0.4–0.5 kommer en stor del av programmet (den jag kallar Hugg.Play) att skrivas om i Scheme. C++ är helt enkelt inte tillräckligt roligt. Eventuellt kommer Qt-beroendet försvinna helt och hållet vid något senare tillfälle.
Det finns dock en del buggar i version 0.3.1 som vore bra att få ordning på så snart som möjligt, så 0.3.2 kommer släppas som planerat.


