Websida | Om MC | Inläggsindex | RSS | Atom
Ganska nyligen rensade jag ordentlig i min hemkatalog, flyttade alla kritiska konfigurationsfiler till en särskild katalog och började versionshantera dem; allt sådant som jag borde ha gjort för länge sedan. Jag fick mycket rensat och det är mycket lättare att hitta i min hemkatalog.
Något senare installerade jag om FreeBSD på min huvudsakliga maskin, min Thinkpad X60s, och återställde hemkatalogen från backup. Jag insåg då att jag inte hade räddat min konfiguration för musikspelaren moc!
Naturligtvis hade jag gjort tangentbordsbindningarna i moc ganska Emacs-lika. Tyvärr lyckades jag inte fullt ut och fick inte Meta-tangenter att fungera. Men nu var alltså min konfiguration borta.
Hellre än att göra om min konfiguration började jag leta efter andra musikspelare med ett trevligt användargränssnitt eftersom jag ändå stört mig lite på moc. Mina krav är ändå ganska enkla:
Fri programvara! Naturligtvis.
Textbaserad, curses (eller libslang eller något motsvarande), inte CLI.
Inga enbart dekorativa utsmyckningar, som ramar eller färger som inte fyller någon funktion. moc har till exempel en irriterande ram som inte kan konfigureras bort, tyvärr.
Tangentbordsbindningar som kan användas utan piltangenter eller PgUp, PgDn, et cetera. Gärna vänliga för någon som har Emacs eller vi i ryggmärgen. I brist på detta duger förstås alldeles utmärkt om det går att binda om tangenterna.
Kan spela FLAC, Ogg Vorbis och MP3.
Kan spara och ladda spellistor som vanliga filer.
Kan välja ljudfiler från katalogstruktur.
Extra poäng, men inte absoluta måsten:
Förstå sig på ID-taggar i ljudfilerna.
Skriven i ett programspråk jag behärskar.
Jag hittade efter lite letande en lovande kandidat som jag inte hört talas om tidigare: Herrie. Det visar sig dessutom att den är utvecklad av FreeBSD-hackern Ed Schouten!
Herrie har ett enkelt användargränssnitt som visar en fillista och en spellista. Överst visas nu spelande låt. Det går att skapa spellistor från fillistan och vandra runt med hjkl, som i vi eller Nethack. TAB byter mellan vyerna. Det verkade trevligt.
Programmet är skrivet i C, använder vanliga curses och förstår sig enligt websidan på att spela åtminstone MP3, Ogg Vorbis och FLAC och förstår dessutom ID-taggar i filerna om det finns några.
Jag installerade så klart Herrie för att testa. Tyvärr visar det sig att Herrie som paket inte kan FLAC! WTF!?
% herrie -v
herrie 2.2 (Two-clause BSD license, using GNU GPL licensed libraries)
Global configuration file: /usr/local/etc/herrie.conf
Audio output: oss
Support for AudioScrobbler: yes
Support for HTTP streams: yes
Support for XSPF playlists (`spiff'): yes
Supported audio file formats:
- Ogg Vorbis
- MP3
Av någon för mig okänd anledning har paketversionen inte länkat med libsndfile som också ger FLAC-stödet. Nåväl, in med ports-versionen i stället:
% herrie -v
herrie 2.2 (Two-clause BSD license, using GNU GPL licensed libraries)
Global configuration file: /usr/local/etc/herrie.conf
Audio output: oss
Support for AudioScrobbler: yes
Support for HTTP streams: yes
Support for XSPF playlists (`spiff'): no
Supported audio file formats:
- Ogg Vorbis
- MP3
- libsndfile
Och jodå, nu kunde den spela FLAC (och WAV, om jag nu skulle vilja).
Gränssnittet blir mycket trevligare om jag slår av färgerna helt och hållet med:
gui.color.enabled=no
i .herre/config. Det ser då ut så här i en urxvt:
Kort sagt: Det uppfyller i stort sett alla mina punkter i den lilla kravlistan ovan. Rekommenderas!
Postad av MC 2010-07-31 21:51 | Permalink
I slutet av min dmesg:
ukbd0: <Topre Corporation HHKB Professional, class 0/0, rev 1.10/1.02, addr 3> on usbus4
kbd2 at ukbd0
Muhahaha! Jag har fått det! Min langare kom förbi med det igår. Jag talar förstås om Extravagant Födelsedagspresent #2: ett Happy Hacking Keyboard Professional 2. Jag skaffade mig den svarta modellen med blanka tangenter, modellnummer PD-KB400BN. Mitt exemplar är tillverkat i februari 2010.
Det är väldigt, väldigt skönt att skriva på och ger ifrån sig ett distinkt ljud, men inte alls lika högljutt som somliga mekaniska tangentbord (Model M på gamla PS/2:or!). Good feeling of oneness with cup rubber, indeed:
Min inmatningsmiljö ser alltså nu ut så här:
(Blixten gör att tangentbordet ser ljusare ut än vad det är. Det är mattsvart rakt igenom.)
Det känns helt rätt.
Jag skriver ganska bra på det, trots tangenter utan märkning. De enda problemen jag märkt hittills är när jag skall logga in på min nätbank: Då håller jag vanligen inloggningsdosan med ena handen och försöker alltså knappa in en sifferkod med andra handen utan visuell feedback att jag knappar in rätt siffror, för bankens gränssnitt ger mig bara punkter. Det går inget vidare. Jag får nog lägga ifrån mig dosan, helt enkelt.
Det andra fallet är om jag försöker skriva något med en hand och håller dottern med andra handen. Det går dock att argumentera för att jag inte skall försöka skriva något på datorn i det läget och i stället ägna mig åt dottern. Ho hum.
Postad av MC 2010-07-27 11:03 | Permalink
När jag nyligen nyinstallerade FreeBSD på min bärbara till 8.1RC2 så fick jag förstås också rätt nya paket och däribland en ny X-server, som nu är version 1.7.5. Plötsligt fungerade inte min xmodmap för Happy Hacking Keyboard!
Jag upptäckte två problem:
Höger Meta genererade inte längre keycode 143. Den gav i stället
129 om jag undersökte med i xev(1).
Ordningen på Mode_switch och Shift spelade plötsligt roll!
Det första problemet var förstås lätt fixat. Jag ändrade helt enkelt koden i min xmodmap-fil för HHKB. Fixat!
Varför i hela friden X-servern plötsligt anser att just den tangenten har en ny keycode har jag ingen aning om. Om något stort gjorts i ändringen av keycode-hanteringen tycker jag mer saker än just min högra Meta-tangent borde gå sönder. Om någon vet vad det är fråga om får ni gärna berätta för mig.
Det andra problemet tog lite längre tid att lista ut: Jag har alltså Mode_switch på höger Alt på mitt HHKB. Jag trycker på höger Alt i kombination med åäö för att få }{| och med Shift för att få ][\. Jag trycker också på den tillsammans med några andra tangenter.
Plötsligt spelade det alltså roll om jag tryckte ner höger Alt eller Shift-tangenten först. Jag fick inte längre någon Mode_switch-funktion om jag tryckte ner Shift före Alt!
En xev-undersökning visade att höger Alt gav keysym NoSymbol om jag tryckte ner Shift först! Nämen! Jag har alltid sett Mode_switch som en modifier (knuten till Mod5 i mitt fall), ungefär som Control! De skall ju inte byta keysym om man trycker på dem tillsammans med Shift. Det har det i alla fall inte gjort tidigare.
Lösningen är att peta in Mode_shift även på Shift-platsen för xmodmap, resulterande i:
keycode 113 = Mode_switch Mode_switch
Det löste problemet. Enkelt, när jag tänker på det. Duh! Men varför har beteendet ändrats och när gjorde det det? Jag har inte sett något någonstans om det här. Någon?
Hur som helst kanske det här inlägget kan hjälpa andra i samma knipa.
Postad av MC 2010-07-26 23:37 | Permalink
I år tänkte jag köpa två lite extravaganta födelsedagspresenter åt mig själv. Den ena har jag redan inhandlat, även om det är ungefär en månad för tidigt. Den andra hoppas jag få om någon vecka. Min agent är på väg mot inköpsstället i landet Far, far away (nåja, han kallar det semester).
Den första presenten är en ny extern skärm, en Hewlett Packard ZR24w, här kopplad till trotjänaren brain, min Thinkpad X60s, som nu har fyra på nacken (blixten gör att den ser riktigt dammig ut – med blotta ögat är det inte riktigt lika hemskt):
Monitorn är tyvärr ansluten via VGA men brain har ingen annan videoutgång. Skärmen har VGA, DVI och DisplayPort. DisplayPort hade varit fint att prova.
VGA-anslutningen fungerar ändå bra. Skärmen synkar automatiskt på ett bra sätt utan att jag behöver göra något, vare sig på skärmen eller på brain. Den Samsung 24-tummare vi normalt har till Playstation 3:an krävde lite pillande för att fungera bra när jag testade den mot brain.
Den nya HP-skärmen är också en 24-tummare. Den har en H2-IPS-panel som ger 178 graders betraktningsvinkel och, tycker amatören MC, väldigt bra färgåtergivning. Panelen sitter monterad på en piedestal, där jag kan justera den riktigt mycket och dessutom rotera skärmen 90 grader. Piedestalen och de riktiga knapparna (inte hemska touchknappar!) är några av anledningarna att det blev just den här skärmen.
En kul detalj är att det gick att stänga av den blå power-LEDen. Tack och lov. Blå LED rakt i ögonen! Vad tänkte folk? PS3:ans skärm har också det och där är det mer irriterande, speciellt om man skall titta på film i ett mörkt rum. Jag har funderat på att tejpa över...
Det är lite oklart vad det HP kallar H2-IPS är för något, men troligen en variant av H-IPS. Helt klart är i alla fall att det är totalt överlägset TN-panelerna här hemma, även om det är väldigt tydligt på vår senaste Samsung att TN-panelerna också utvecklats oerhört över åren.
Bäst av allt är ändå upplösningen, 1920x1200. 1200 pixlar vertikalt! Woho! 91 rader i Emacs!
Bisarrt nog hade jag 1200 pixlar på höjden senast 1999, när jag fortfarande jobbade på Cendio (tidigare Signum Support). Där hade jag i några år en Eizo 6600M. En fantastisk skärm som jag ibland fortfarande saknar.
6600:an var en gråskaleskärm med 1024 gråtoner i varje fysisk pixel. Ingen dot pitch! Vanlig CRT, förstås, men inte lika tung som motsvarande färgskärmar (28 kg jämfört med nästan 40 kg) och inte heller lika djup. Och mycket skarpare! Den var också mycket, mycket billigare än motsvarande färgskärmar. Jag tror den kostade 12000 kronor när den köptes in, antingen -97 eller -98. Färgskärmar i samma storlek och upplösning kostade tre, fyra gånger så mycket!
Min HP ZR24w kostade som jämförelse 3800 kronor. Ett kap, inte bara jämfört med priserna -97, -98 utan också jämfört med vad andra IPS-paneler fortfarande kostar. Jämför till exempel med Eizos IPS-paneler. Den närmaste konkurrenten med vettigare prisläge är nog Dell U2410. Jag tittade mycket på U2410-recensioner och i forum men blev lite mörkrädd för alla rapporter om de som haft problem med sina U2410:or. Jag bestämde mig till slut alltså för HP-skärmen.
Den är som levererad en smula ljus (ljusstyrkan var på 90%!), men lite rattande på ljusstyrka och kontrast löste det rätt bra. En mycket detaljerad recension med tips om till exempel just detta finns här:
http://www.tftcentral.co.uk/reviews/hp_zr24w.htm
Ett återstående litet ljusproblem är det som brukar kallas ”white glow” på IPS-paneler: väldigt mörka partier blir lite ljusare om de ses ur en ganska extrem vinkel. Jag märker det bara om rummet är ganska mörkt, även om mina terminalfönster alla har svart bakgrund! Jag kan alltså leva med det.
Å andra sidan köpte jag knappast skärmen för att bygga hemmabio. Hade jag varit ute efter något sådant hade jag kanske föredragit ännu svartare svart. Jag är framför allt ute efter att få plats med många rader och skarp text, som ni nog kunde gissa. Det får jag verkligen med råge med den här skärmen. Färgåtergivningen, den jämna färgen och extrema betrakningsvinklar är en bra bonus.
För att få saker att fungera med brain testade jag först med xrandr.
EDID-snacket fungerade och skärmen talade om vilka upplösningar den
förstod sig på. Jag hade varit lite nojig kring det här eftersom någon
sagt att de inte fått EDID att fungera mot ZR24w, fast det var oklart
med vilket system. Jag läste på för att försäkra mig om att det
faktiskt fortfarande gick att använda egentillverkade modelines, som
på den gamla onda tiden. Nu slapp jag tack och lov det. Med en
% xrandr --output VGA --mode 1920x1200
blev allt väldigt mycket roligare!
Ännu roligare blev det, i alla fall en stund, med
% xrandr --output VGA --right-of LVDS
som alltså gjorde att jag hade en virtuell skärm på 2944 x 1200,
fördelad på brains interna skärm och HP-skärmen. Tyvärr blev allting
också mycket långsammare och till exempel mplayer leker inte längre
med XVideo, utan kräver att jag använder -vo x11. Jag får alltså i
så fall titta på filmer utan hårdvaruacceleration. Det hettar upp
CPU:n, må ni tro, att köra med mjukvaruzoom till fullscreen!
För tillfället kör jag alltså i stället med den inbyggda skärmen avstängd när jag använder den externa. 1920x1200 räcker bra! Just nu, i alla fall...
Postad av MC 2010-07-16 08:54 | Permalink
Jag skrev i ett tidigare inlägg att jag skrivit en egen fönsterhanterare. Jag började tidigt använda den som min vardagliga fönsterhanterare och har fortsatt med det. Därmed har jag också mer eller mindre tvingat mig själv att stoppa in vad jag tyckte saknades och, förstås, rättat buggar som har dykt upp.
Det jag saknade mest sist jag skrev var virtuella skärmar. Det stoppade jag in 30:e juni. Det visade sig faktiskt inte vara särskilt svårt, så själva arbetet för det gick på någon timme.
Eftersom jag hela tiden startade om mcwm medan jag utvecklade blev det
ganska snart uppenbart att jag måste spara undan informationen om
vilka fönster som hörde till vilka workspaces någonstans utanför
själva fönsterhanteraren, som jag ju dödade hela tiden. Lyckligtvis
har Extended Window Manager Hints redan en hint för detta,
_NET_WM_DESKTOP. Stöd för det kunde jag plocka in ganska snabbt,
även om jag kanske gjorde det på ett något naivt sätt. Det betyder
alltså att även andra fönsterhanterare förstår var fönstren skall
placeras om jag nu startar en annan wm eller om en annan wm satt
fönstren på särskilda virtuella skärmar redan.
Tyvärr var det saker jag inte hade förstått. Exempel: Om du gjort en sökning i ett dokument med xpdf och sedan fortsatt läsa i filen så gör xpdf bara unmap på sökfönstret i stället för att förstöra det. Kanske sparar xpdf lite tid på det viset om du vill göra en sökning igen.
Om jag bytte workspace och bytte tillbaka så mappade min fönsterhanterare också sökfönstret, fast xpdf alltså inte ansåg att det var aktivt... Oops! Några andra program, till exempel Ghostscript-fronten gv, gjorde likadant.
Det tog lite tid att komma på ett bra sätt att hantera det. Rätt svar är troligen att hantera UnmapNotify-händelser i fönsterhanteraren och när vi får en sådan glömma bort fönstret helt och hållet, om det inte var vi själva som gjorde unmap för att vi håller på att byta workspace.
Det här innebar också att starten av fönsterhanteraren blev ändrad så att vi enbart hanterar fönster som faktiskt redan syns när vi startar. Förut hanterade den alla fönster som inte explicit sagt att de inte skall hanteras, alltså de med ”override redirect” satt.
En bieffekt av den ändringen är att jag nu låter mcwm dö på ett snyggare(?) sätt: Den mappar alla fönster den känner till och sätter om tangentbordsfokus till att automatiskt följa muspekaren (X:s default). Jag stoppade också in signalhanterare för att se till att mcwm dör på samma sätt ifall den skulle krascha.
De här ändringarna gör mycket riktigt att xpdf:s sökfönster och utskriftfönster inte längre mappas vid byte till dess workspace om de nu inte var aktiva. Om xpdf eller gv var igång och hade sådana subfönster när mcwm startade så kommer de inte heller att synas i onödan. Det fungerade!
Fokusbyte från tangentbordet stoppade jag in i samma veva som workspaces. Hittills är det bara en enkel fönsterring som gör att du kan gå runt mellan alla fönster som finns på skärmen. Det är kanske av begränsat värde jämfört med vad man skulle vilja ha, men det är en bit på väg.
Från början hade jag lite problem med hur jag skulle göra för fönster som är ”fixed”, alltså de som syns på alla workspaces. Hur skulle jag få in dem i fokusbytet? Jag löste det genom att sådana fönster alltid följer med in i den lista över fönster som finns på en workspace. När du byter workspace adderas alltså alla fönster som är ”fixed” till den workspace-listan också. De tas bort igen när du byter workspace.
mcwm kan nu också verkligen hantera att man vrider på sin skärm eller tar bort en skärm. Tidigare noterade den bara den nya skärmstorleken och lät dig flytta fönster lite längre. Nu hanterar den det lite snyggare.
Om du till exempel tar bort en skärm och det fanns fönster på den skärmen så flyttas de så att de blir synliga och får plats på den eller de skärmar som är kvar. Om du vrider på en skärm och en del fönster hamnat helt eller delvis utanför den nya geometrin så flyttas de in.
Jag är nästan feature-komplett och har nästan en miljö som ser ut och beter sig som min gamla fönstermiljö med evilwm och ctwm! Det som saknas är nog bättre fokus från tangentbordet (gå till fönster jag senast arbetade i snarare än en fönsterring) och ”snap to border”.
Nu kommer också de saker som gör mer än vad min gamla miljö kunde. Det jag framför allt tänker på är RandR-hantering för att ge mig en uppsättning workspaces per fysisk skärm.
Hur som helst så tror jag mcwm i sitt nuvarande skick inte längre är något enbart för självplågande utvecklare som jag själv. Det går faktiskt att använda den. Ta gärna ner och testa!
http://hack.org/mc/hacks/mcwm/
Postad av MC 2010-07-12 14:44 | Permalink
Jag har skrivit en fönsterhanterare. Jag kallar den i brist på bättre namn ”mcwm”. Namnförslag är välkomna.
Officiell websida här:
http://hack.org/mc/hacks/mcwm/
Här är en screenshot, där det visserligen inte syns något av fönsterhanteraren eftersom den inte ens ritat ramarna runt fönstren (den har dock satt färg och tjocklek på dem):
Det började lite som ett skämt. 'Alla' har ju skrivit en fönsterhanterare, så varför inte jag också?
Jag har länge använt gamla CTWM och till och med bidragit med några patchar. Jag har ändå länge funderat på att byta. Nu senast blev det aktuellt eftersom jag fick problem när jag bytte till UTF-8 på mitt system.
CTWM:s kod är ganska gammal och fylld med saker som väldigt få (någon?) längre förstår. Koden är tungrodd, smått ogenomtränglig och alldeles för stor för det som CTWM kan göra.
Tidigare har jag i perioder flörtat lite med åtminstone (i omvänd tidsordning) evilwm, ratpoison, wm2, fvwm och 9wm. Jag har använt samtliga länge nog för att bli skapligt nöjd med min konfiguration och/eller patchat mig till det (evilwm och 9wm).
Jag har förstås testat många andra fönsterhanterare också, inklusive tiling-modellen à la larswm. Hittills har jag varit alltför beroende av att fönster stannar kvar på samma ställe på skärmen för att vara nöjd med tiling. Jag tycker det är lite förvirrande.
När CTWM började krångla var mitt förstaval i stället evilwm. Jag använde den i några veckor tills jag började reta mig på en del saker som verkade kräva ganska stora ingrepp i koden.
Eftersom jag nyligen hört talas om XCB och funderat på att lära mig lite mer om det började jag i stället skriva lite testprogram för XCB. Man kanske kan säga att mina testprogram växte lite över förväntan...
XCB är en mer direkt mappning av X-protokollet jämfört med libX11. En speciellt intressant sak med det är att det grundar sig i en formell beskrivning av protokollet och att koden för att generera X-anropen är automatgenererad från den beskrivningen!
Det som är automatgenerat är alltså bara koden för själva X-protokollet. Naturligtvis är hjälpfunktionerna och -biblioteken i XCB skrivna för hand.
Vanliga libX11 är sedan en tid omskriven för att använda XCB, så det verkar som om XCB är framtiden för X-protokollet oavsett om man använder det direkt eller inte. Alla program som länkar mot libX11 använder alltså redan nu XCB, om än indirekt.
Jag hittade tyvärr inte så mycket dokumentation för XCB, men tack och lov finns själva X-protokollet beskrivet i form av Scheiflers X Window System Protocol. I fysisk form har jag dessutom ett dumpstrat ex av Adrian Nyes Xlib Programming Manual från O'Reillys serie om X Window System, som var rätt hjälpsam.
Inter-Client Communication Conventions Manual finns också fritt tillgänglig, men den har jag inte orkat ta mig igenom ännu. Dito för Extended Window Manager Hints. Nu stöder min lilla fönsterhanterare än så länge knappt några hints alls, men det är troligt att det blir stöd för åtminstone några fler när jag orkar läsa igenom och försöka förstå ovanstående.
I övrigt läste jag källkod från bland annat CTWM, evilwm och tinywm. Den senare är smått otroliga 56 rader kod!
När jag hade börjat hacka på min XCB-baserade wm hittade jag faktiskt också en annan fönsterhanterare som använt XCB från början: i3. Awesome har också nyligen portats från Xlib till XCB. Jag har dock inte provat någon av dem ännu. i3 har en dependency på ett JSON-lib som i sin tur kräver hela Ruby för att alls bygga! Awesome är beroende av massor av libraries.
För att utmana mig själv att göra min fönsterhanterare mer komplett började jag redan samma kväll använda den som min huvudsakliga fönsterhanterare: ”an itch to scratch”. Det fungerade! Dagarna efter hackade jag in nästan allting som jag tycker jag behöver i en fönsterhanterare.
Den är inte feature-komplett ännu (se WISHLIST och TODO i distributionen). Det som saknas mest är virtuella skärmar och att kunna byta fokus från tangentbordet. Det går dock alldeles utmärkt att använda den. Jag har använt den hela tiden sedan förra tisdagen då jag alltså började utveckla den.
En kul sak som jag inte sett hos någon annan fönsterhanterare är att jag utan att använda någon extension kunde få reda på om användaren hade kopplat in eller ur en skärm. Det visar sig att rootfönstret skickar en ConfigureNotify och talar om den nya storleken! Rätt naturligt, faktiskt, men jag tror inte många traditionella fönsterhanterare någonsin prenumerade på denna event, för vem trodde att root-fönstret någonsin skulle förändras? Så icke i dessa tider med RANDR.
I nuvarande skick fungerar min fönsterhanterare faktiskt med alla program jag normalt startar men det finns naturligtvis massor av buggar, nästan ingen felkontroll och en hel del fula antaganden kvar i koden. Var försiktiga om ni provar. Jag rekommenderar inte alls att testa den på en äldre maskin som inte är TrueColor.
Observera att den för att vara användbar kräver att du vet vilken tangent på ditt tangentbord som generar Mod1 (vanligen Alt, men det går inte att veta) och vilken som generar Mod2. Om du inte har koll och mappat ditt tangenbord själv vill du kanske kolla med xev(1) innan du försöker starta mcwm.
Min utvecklingsplattform är FreeBSD. För att bygga krävs följande paket:
men så vitt jag vet ingår de alla ändå om du alls har X installerat.
Igår kväll meddelade vännen Dennis att mcwm gick att kompilera under Ubuntu GNU/Linux. Jag har alltså inte själv testat den under Linux ännu men det verkar lovande. Återkommer om det.
Hackandet fortsätter.
Happy hacking,
MC
Postad av MC 2010-06-22 16:26 | Permalink
Tidigare skrev jag om automatiskt konfiguration av adresser i IPv6 och mitt program radns, som lagrar undan adresser till DNS-servrar. Arbetet med radns fortsätter sakta framåt.
31:a maj gjorde jag en ny release, som nu också innehåller:
I själva radns finns nu också följande funktionalitet:
I samband med att jag stoppade in stöd för integration med resolvconf behövde jag få reda på vilket gränssnitt som meddelandet kommit in på. Det gjorde tyvärr att programmet inte längre kompilerar på MacOS X, eftersom den OS-version jag testade på inte hade fullt stöd för Advanced Sockets API for IPv6 (RFC 3542), utan en äldre version. Kanske har det åtgärdats i senare OS X-versioner? Mac-användare får gärna höra av sig om de vill hjälpa till, för jag har ingen egen Macintosh.
Jag har ännu inte skrivit något startscript för SysV init, som till exempel finns i de flesta Linux-distributioner. (Väl? Det verkar vara något på gång här.) Om någon som sitter på ett sådant system och vill skriva ett startscript, skicka det gärna till mig!
Distribution här:
http://hack.org/mc/hacks/radns/
Postad av MC 2010-06-14 12:31 | Permalink
Jag har äntligen tagit steget till UTF-8. Antagligen är jag sist i Sverige med det. Jag körde visserligen UTF-8 på Plan 9 redan 1995, för Plan 9 kunde ju inte något annat, men jag har varit kvar i en Latin 1-locale på unixar ända tills nu.
Orsaken är nog mest feghet, tror jag. Jag har känt mig otrygg med vad som skall hända med alla filer (och en del filnamn!) jag har i ISO 8859-1. Kommer de program jag använder att ens tolerera dem om jag byter till en locale som säger att jag använder UTF-8?
Använder jag UTF-8 kan jag dessutom inte längre att kunna arbeta obehindrat i konsolläge i FreeBSD, eftersom konsollen ännu inte kan UTF-8. Det är i och för sig ett mindre problem jämfört med de många andra jag föreställde mig att jag skulle få.
Nu gjorde jag i alla fall härom dagen
export LANG=en_US.UTF-8
och det verkar fungera för det mesta.
Jag fick göra en del konverteringar, men mycket av det dagliga arbetet hjälper Emacs mig med. Emacs kan automagiskt känna igen en fil i Latin 1 och nästan vilken annan kodning som helst om jag får tro manualen. Det fungerar faktiskt förvånansvärt bra för det mesta. Emacs fortsätter att spara filen i den kodningen så länge jag inte stoppar in tecken som inte kan representeras. Sedan jag sist försiktigt experimenterade med det här har Emacs blivit mycket bättre på Unicode-hantering.
Jag var däremot inte alls lika nöjd med hur xterm klarade sig. Jag vill förstås att min terminalemulator när den dyker på en kodpunkt som inte finns definierad i defaultfonten skall försöka hitta en annan font som kan visa dem, men det fungerade inte. Trevligt nog hade jag på en hackjunta nyligen blivit visad rxvt-forken rxvt-unicode, så jag installerade den och experimenterade lite. Jag är mycket nöjd med resultatet. Jag borde inte ha blivit förvånad, men allt fungerar också i en screen över ssh.
Jag fick några trevliga X-resurser för urxvt från bland annat Anders Waldenborg och kombinerat med mina gamla xterm-resurser blev det här resultatet:
urxvt.background: #000000
urxvt.foreground: gray90
urxvt.color0: black
urxvt.color1: IndianRed
urxvt.color2: palegreen
urxvt.color3: goldenrod
urxvt.color4: SteelBlue3
urxvt.color5: PaleVioletRed
urxvt.color6: cyan3
urxvt.color7: gray90
urxvt.color8: gray30
urxvt.color9: red
urxvt.color10: cyan4
urxvt.color11: DarkOrange
urxvt.color12: RoyalBlue3
urxvt.color13: HotPink
urxvt.color14: VioletRed
urxvt.color15: white
urxvt.colorBD: #ffffff
! Amber:
urxvt.cursorColor: #ff7f24
urxvt.highlightColor: dimgrey
urxvt.scrollBar: false
urxvt.saveLines: 512
urxvt.secondaryScroll: true
urxvt.termName: xterm-88color
urxvt.font: FIXFONT
urxvt.visualBell: true
där FIXFONT är definierad som
#define FIXFONT -xos4-terminus-medium-r-normal--16-160-72-72-c-80-iso10646-1
Resten fungerar väl med defaultinställningarna, tycker jag.
När jag väl bytt började jag förstås leka med andra saker också, till
exempel trådmarkeringen i Gnus som jag nu plötsligt kan ha roligare
tecken i, oavsett om jag kör min Emacs som X-tillämpning eller i en
urxvt. Från min .gnus.el:
;;; Make threading look pretty with Unicode line-drawing.
(setq-default
gnus-sum-thread-tree-single-indent " "
gnus-sum-thread-tree-false-root ""
gnus-sum-thread-tree-root "┌ "
gnus-sum-thread-tree-vertical "│"
gnus-sum-thread-tree-leaf-with-other "├─>"
gnus-sum-thread-tree-single-leaf "└─>"
gnus-sum-thread-tree-indent "")
Det ser ut så här:
Dessutom stoppade jag in utf-8 och utf-16 i den här listan:
(setq mm-body-charset-encoding-alist
'((utf-16 . 8bit)
(utf-16be . 8bit)
(utf-16le . 8bit)
(utf-8 . 8bit)
(iso-8859-1 . 8bit)))
för att vara någorlunda säker på att vanliga brev skrivna med Unicode inte skickas i BASE64 eller något annat hemskt som inte är så lätt att greppa i.
Å andra sidan finns specialfallet PGP-signerade brev. Som bekant kan det hända att vägen MUA-MTA-MTA-MUA inte alltid är helt åttabitarsren och det kan, men måste inte, förekomma konverteringar på vägen. Om mitt fina åttabitarsbrev blivit konverterat till Quoted (un)Printables på vägen så validerar förstås inte längre min PGP-signatur hos mottagaren. Misär!
Alltså behövs en liten revidering, speciellt vad gäller just signerade brev i klartext:
(setq mm-content-transfer-encoding-defaults
'(("text/.*" 8bit)
("message/rfc822" 8bit)
("application/emacs-lisp" 8bit)
("application/x-emacs-lisp" 8bit)
("application/x-patch" 8bit)
("multipart/signed" qp) ; Obs!
(".*" base64)))
Kanske är det fegt att säga att allt annat skall kodas som BASE64. Jag vet inte. Jag måste nog utföra lite experiment för att bli trygg med något annat där.
I Emacs i övrigt hakade jag också in det här för att kunna knappa in
några vanliga tecken som annars inte finns på mitt tangentbord (ur min
.emacs.el):
; em-dash
(define-key global-map [(meta \-)] "—")
; en-dash
(define-key global-map [(meta \_)] "–")
; quotes
(define-key global-map [(meta \!)] "“")
(define-key global-map [(meta \")] "”")
Det var värre med mina websidor. De serveras av webservern thttpd som av någon anledning alltid skickar med ”charset=foo” för MIME-typerna ”text/*” där ”foo” är vad du sagt i konfigurationen eller som default iso-8859-1. Det är alltså inte beroende på vad filerna faktiskt råkar vara kodade i!
Jag är mycket nöjd med thttpd i övrigt, men just det här var bara korkat. Tyvärr går just detta inte att konfigurera bort, så det slutade med en omkompilering efter följande ändring i thttpd 2.25b:
--- mime_types.txt~ 2003-10-26 18:00:45.000000000 +0100
+++ mime_types.txt 2010-05-18 23:11:14.000000000 +0200
@@ -14,6 +14,7 @@
asc text/plain
asf video/x-ms-asf
asx video/x-ms-asf
+atom application/atom+xml
au audio/basic
avi video/x-msvideo
bcpio application/x-bcpio
@@ -52,8 +53,8 @@
gtar application/x-gtar
hdf application/x-hdf
hqx application/mac-binhex40
-htm text/html; charset=%s
-html text/html; charset=%s
+htm text/html
+html text/html
ice x-conference/x-cooltalk
ief image/ief
iges model/iges
@@ -161,7 +162,7 @@
tr application/x-troff
tsp application/dsptype
tsv text/tab-separated-values
-txt text/plain; charset=%s
+txt text/plain
ustar application/x-ustar
vcd application/x-cdlink
vrml model/vrml
Jag tog alltså helt enkelt bort att ”charset” skickas med överhuvudtaget i innehållsdeklarationen. Dessutom passade jag på att lägga till en MIME-typ för Atom-flöden, som ni ser. (Förresten validerar nu Atom-flödet enligt W3C Feed Validator, men det är nog ett annat bloginlägg.)
Efter den här förändringen litar jag dessvärre på att filerna som serveras som MIME-typerna ”text/*” själva skall tala om vad de har för teckenuppsättning. Det gör inte alla än, men i de browsers jag testat (w3m, Lynx, Firefox och Internet Explorer 7), så verkar den inbyggda heuristiken för att känna igen teckenuppsättningar ändå fungera ganska bra.
Jag ändrade också på mitt lilla script för att generera websidor, mdn, så att den deklarerar teckenuppsättning som UTF-8 i stället för ISO-8859-1. Samma ändring gjorde jag i Blosxom som genererar den här bloggen.
Jag skrev ett throw away-script för att konvertera alla inlägg i bloggen till UTF-8. Tyvärr var det lite buggigt, så det blev lite handpåläggning på några inlägg i alla fall. Hade jag inte gjort någon konverting hade det nästa gång jag skriver ett inlägg (nu, alltså!) blivit en intressant blandning av Latin 1 och UTF-8, med bara en innehållsdeklaration, åtminstone i HTML-filen.
En del andra filer konverterade jag med hjälp av iconv och passade i
en del fall på att dessutom börja använda min nya Markdown-baserade
märkning. Jag byter alltså långsamt från min gamla hackade txt2tags
till mitt eget mdn.
Slutsatsen är ändå att bytet till UTF-8 gått ganska bra, i alla fall än så länge. Jag får nog tacka Emacs och urxvt mest för det, tror jag.
Jag slutar med lite roande läsning i form av några brev från Rob Pike om tillblivelsen av UTF-8 som Marcus Kuhn sparat:
http://www.cl.cam.ac.uk/~mgk25/ucs/utf-8-history.txt
サヨウナラ,
MC
(Sayōnara, alltså. Jag kan inte ens lite japanska, men det är ju ett kul test av UTF-8.)
Postad av MC 2010-05-22 20:39 | Permalink
Jag föredrar normalt bitmappade typsnitt. De flesta av dagens datorskärmar har väldig låg upplösning, så det blir svårt för vektoriserade typsnitt att komma till sin rätt. Jag tycker det är väldigt svårt för dem att tävla med handgjorda glyfer för en viss storlek. Det finns kanske undantag. Läs vidare!
Upplösningen på min bärbara dator, brain, är 106x105 DPI på den interna skärmen. När jag ibland använder en extern skärm är DPI:n ofta ännu sämre. I tryck så är DPI vanligen som allra minst 600 DPI även om fototypsättare och liknande har mycket högre upplösning, till exempel 2540 eller till och med 4800 DPI! När det gäller tryck så flyter dessutom bläcket ut lite grann i papperet och ger ännu mjukare kurvor. Så är det förstås inte på skärmar.
Det finns knep för att få ett skalbart typsnitt att se bättre ut även på lägre upplösningar. Ett sådant knep är kantutjämning, oftast känt med det engelska uttrycket anti-aliasing (nedan "AA"). På en LCD går det till och med att göra det på nivån av de subpixlar som bygger upp en vanlig färgpixel. Resultatet, tycker jag, är ganska dåligt, alldeles särskilt om det är fråga om vit text på svart botten, något jag ofta använder i till exempel terminaler och i min Emacs.
Subpixel-AA ger värst effekt. Jag ser de enskilda färgerna i subpixlarna, vilket alltså betyder att kanterna på glyferna blir röd, grön och blå. AA utan subpixelanpassning blir bara suddig, speciellt med vitt på svart. Skärpan är mycket bättre om jag slår av AA, men då ser jag i stället förstås hur dålig upplösning jag har om jag använder ett skalbart typsnitt. Det ser helt enkelt inte bra ut.
Kanske är det här framför allt fråga om problem som finns i en särskild implementation av AA, specifikt FreeType i kombination med RENDER-utökningen i X.org-servern. Kanske fungerar AA med vit text på svart botten jättebra i något annat system.
Typsnitten jag för det mesta använder är som sagt bitmappade och ser ut så här:
Det här typsnittet heter "-misc-fixed-medium-r-normal--15-140-75-75-c-90-iso10646-1" i X Logical Font Description (XLFD), men är också känt som 9x15. Det har funnits länge i X, men har på senare tid fått en del Unicode-tecken tillagt. Jag använder den framför allt i Emacs.
Tidigare använde jag Gacha 8x16 i Emacs, här i en xterm:
Gacha var defaulttypsnitt i fönsterystemet MGR, fast då vanligen på mycket större skärmar än på min bärbaras lilla 13-tummare. Var typsnittet kommer ifrån ursprungligen vet jag inte. Jag har sett det på skärmdumpar från SunView också, så det var tydligen inte begränsat till MGR. Om någon vet varifrån det kommer och vem som gjort det får ni gärna berätta för mig.
Jag har gjort om MGR-typssnittet till PCF, som moderna X-servrar använder:
http://hack.org/mc/files/gacha-8x16.pcf
Jag har också gjort om det till ett VGA-typsnitt för konsollanvändning under FreeBSD och Linux. Det fungerar antagligen under MS-DOS och FreeDOS också.
http://hack.org/mc/files/gacha-8x16.vga
Gacha täcker tyvärr bara Latin 1. Jag använder därför inte den längre i min Emacs. Även om jag fortfarande kör en Latin 1-locale så kan Emacs hantera tecken utanför Latin 1 och får jag till exempel ett mail med tecken utanför Latin 1 använder Emacs plötsligt ett annat typsnitt för just det tecknet, även om det skulle råka vara till exempel en genitivapostrof. Jag fann det så irriterande att jag bytte till 9x15.
För sena nätter och/eller långa arbetsdagar brukar jag ibland köra Terminus 24, som också ger en skön retrokänsla tillbaka till tiden då jag satt framför en 80x24-terminal, fast nu med klart bättre upplösning:
(Klicka på den lilla bilden ovan för hela bilden så det går att se hur skarp och enorm den är.)
Jag har definierat en fånig liten elispfunktion för att byta till den:
(defun night-font ()
"Change default font to something huge."
(interactive)
(set-frame-font
"-xos4-terminus-medium-r-normal--24-240-72-72-c-120-iso10646-1" t))
Terminus är överhuvudtaget ett ganska begagligt typsnitt av Dimitar Zhekov:
Jag har bara testat det ett kort tag och kan kanske övertygas om att 8x14- eller 8x16-varianten kan bli min nya default i Emacs.
I typiska xtermar är jag annars förtjust i Lucida Typewriter:
Dess fulla namn i XLFD är: "-b&h-lucidatypewriter-medium-r-normal-sans-12-120-75-75-m-70-iso8859-1".
Den finns också i en Unicode-variant, men jag kör som sagt fortfarande i en Latin 1-locale i mitt skal.
Det finns ett intressant projekt som heter GNU Unifont som försöker verkar täcka hela Unicode BMP:
http://unifoundry.com/unifont.html
Tyvärr verkar den inte fungera något vidare med Emacs, i alla fall inte i den version jag testade. Emacs blev rejält förvirrad och de redan lite störande "fringes" blev någon centimeter breda! Jag vet inte varför ännu.
Ett annat intressant typsnitt är Liberation Mono, som finns med de andra Liberation-typsnitten här:
https://fedorahosted.org/liberation-fonts/
Red Hat har tydligen beställt dem från typsnittsmakaren Ascender för att få typsnitt som är storleksmässigt kompatibla med Microsofts Windows-typsnitt. De har dessutom haft den goda smaken att släppa dem som GPL med några tillägg.
Liberation Mono fungerar faktiskt förvånansvärt bra som programmeringstypsnitt, tycker jag, speciellt för att vara ett skalbart typsnitt. Här i en xterm med en emacsclient:
Här är några andra kul genomgångar av typsnitt för programmerare:
http://www.codeproject.com/KB/work/FontSurvey.aspx
http://hivelogic.com/articles/top-10-programming-fonts
X Window System har nu för tiden två sätt att hantera typsnitt. Det ena kallas ibland "core fonts" och ibland "server-side fonts" och det andra går vid lite olika namn beroende på vad man tänker på. Ibland kallas det Fontconfig-systemet och ibland Xft, men ett bättre namn är nog "client-side fonts", eftersom typsnitten inte alls behöver renderas av just Xft (X FreeType Library Interface), utan lika gärna kan renderas av något annat.
Fontconfig, i sin tur, är ett system för att hitta typssnittsfiler och används tillsammans med till exempel just FreeType för att tala om hur renderingen skall gå till.
Client-side är det nyare sättet att hantera typsnitt på. Tillämpningarna själva renderar typsnitten, vanligen med hjälp av ett bibliotek som Freetype eller Cairo, och skickar det färdigrenderade resultatet till X-servern, som alltså bara skall visa resultatet.
I klassiska core fonts så laddas i stället hela typsnittet över till X-servern som sedan renderar det. I bitmapfallet betyder detta troligen bara att blitta över en bitmap från en plats i minnet till en annan.
De flesta core fonts är alltså bitmapbaserade, men de behöver inte vara det. Moderna X-servrar har till exempel direkt stöd för att själva rendera typsnitt i TrueType-formatet.
På samma sätt är de flesta client-side-typsnitt vektorbaserade, men behöver inte vara det. Det går att stoppa in bitmaps i dem, till och med enbart för vissa storlekar medan man samtidigt har en generell vektorbeskrivning.
För att lista de installerade typsnitten använder man xlsfonts för
server-side och fc-list för client-side.
Typiskt sätt att manuellt använda ett typsnitt i client-side är så här:
% xterm -fa "Bitstream Vera Sans Mono" -fs 10
xterm är dock notoriskt slö på uppdateringar när man använder sådana typsnitt. På förra hackjuntan fick jag se hur alternativet urxvt sprang cirklar runt xterm när det gäller hanteringen av just typsnitt i client-side och scrollning. Ingen flicker alls!
En intressant sak är att moderna X-servrar som jag skrev ovan kan rendera TrueType själva, så program som normalt inte använder Freetype-biblioteket kan ändå visa samma typsnitt, fast troligen renderade lite annorlunda, i alla fall om det är ett skalbart typsnitt. Om du vill använda detta, leta reda på typsnittskatalogen. Gör sedan:
% cd /path/till/katalogen
% ttmkfdir -o fonts.dir
% xset fp+ /path/till/katalogen
% xset fp rehash
Nu borde typsnitten synas med en vanlig xlsfonts. De anges vanligen
med "0" i stället för storlekarna eftersom de är skalbara, exempelvis:
-redhat-liberation mono-medium-r-normal--0-0-0-0-p-0-iso10646-1
Du använder dem genom att helt enkelt stoppa in lagom storlek på rätt plats, exempelvis:
xterm -fn '-redhat-liberation mono-medium-r-normal--0-100-0-0-p-0-iso10646-1'
för att få en 10-punktersskalning.
För att permanent få med de här typsnitten i din X-server, stoppa in
FontPath "/path/till/katalogen"
i Files-sektionen i din xorg.conf. Finns vanligen i
/etc/X11/xorg.conf
De program som använder client-side och FreeType använder oftast också
kantutjämning (anti-aliasing, AA). Som jag skrev ovan ogillar jag det,
men det går tack och lov att stänga av. För att stänga av AA, skapa en
~/.fonts.conf och stoppa in:
<?xml version="1.0"?>
<!DOCTYPE fontconfig SYSTEM "fonts.dtd">
<fontconfig>
<match target="font">
<edit name="antialias" mode="assign">
<bool>false</bool>
</edit>
</match>
</fontconfig>
TrueType-typsnitt kan innehålla hinting i form av bytekod som skall evalueras av renderaren. Detta är patenterat av Apple i USA, om jag förstår det rätt, så det är inte säkert att FreeType-biblioteket på din plattform stöder det. Du kan bli tvungen att kompilera om FreeType. Se då till att slå på BCI (ByteCode Interpreter), i alla fall om du 1) inte befinner dig i ett land där Apples patent är giltigt, 2) har köpt en licens av Apple, eller, 3) skiter i patent.
FreeType har som default en autohinter, men jag tycker den ger ganska hemskt resultat som du speciellt ser om du har slagit av AA.
För att slå på användning av bytekoderna och slå av den automatiska
hintningen, ändra i ~/.fonts.conf eller local.conf för hela
systemet:
<match target="font" >
<edit mode="assign" name="hinting" >
<bool>true</bool>
</edit>
<edit name="autohint" mode="assign">
<bool>false</bool>
</edit>
</match>
Ser du skillnaden?
Postad av MC 2010-05-11 16:35 | Permalink
I det här inlägget skrev jag om att jag börjat använda Markdown i Blosxom så jag slipper skriva inläggen i HTML. Jag var rätt seg med att upptäcka att det överhuvudtaget fanns en plugin för Blosxom för Markdown, faktiskt. Det låter skumt, med tanke på hur illa jag tycker om att skriva HTML och hur länge jag använt verktyg som txt2tags.
Jag hann alltså skriva en hel del inlägg innan jag började använda Markdown. Tyvärr blev de äldre inläggen lite trasiga när jag började använda denna plugin.
Det skall nu vara lagat. Natten till i dag ("i nättras", som det så fint heter på gotländska) använde jag först Aaron Swartz html2text för att konvertera de äldre inläggen, sedan iconv för att konvertera teckenuppsättning mellan UTF-8 och Latin 1 och till slut fick jag tyvärr också fixa en hel del för hand. Det betalade sig, tycker jag. Nu validerar bloggens indexsida som XHTML 1.0 Strict!
RSS-flödet validerar också. Jag hade gjort ett misstag när jag angav språkkoden och skrivit "se_SV" i stället för "se-SV", märkte jag.
Atom-flödet validerar dessvärre inte. Det ser ut att vara buggar i den Atom-plugin jag använder till Blosxom. Jag skall se om jag kan hitta felen i koden eller se om det finns en modernare plugin eller en ersättare.
Postad av MC 2010-05-09 11:31 | Permalink
Websida | Om MC | Inläggsindex | RSS | Atom