Hur jag rankar fönsterhanterare för Linux

Upptäck skillnaderna mellan Linux-fönsterhanterare och lär dig hur de påverkar ditt arbetsflöde, inklusive viktiga kriterier som layout, konfiguration och användning av Wayland eller X11.

Ytan sett ser de flesta Linux-fönsterhanterare bedrägligt lika ut. Det är först när du börjar använda dem som du inser hur olika de hanterar ditt arbetsflöde. Här är en snabb sammanställning av hur Linux-fönsterhanterare skiljer sig åt—och vilka jag rankar högst.

Vad är de huvudsakliga sakerna jag letar efter i en Linux-fönsterhanterare?

Det finns tre huvudpunkter jag letar efter i en Linux-fönsterhanterare (WM): hur den hanterar fönsterlayouter, hur dess konfigurationssystem fungerar, och om den körs på Wayland eller X11. Här är en mer detaljerad sammanställning av hur dessa faktorer påverkar ditt övergripande arbetsflöde.

Hur hanterar fönsterhanteraren fönstren?

Det finns tre grundläggande sätt som en fönsterhanterare kan hantera dina fönster på: flytande, kakel och den helt nya—skrollande.

Flytande fönsterhanterare—även kända som staplande fönsterhanterare—är vad de flesta redan är bekanta med från att använda Windows eller en standard Ubuntu-skrivbordsmiljö. Appfönster flyter fritt på skärmen, kan överlappa varandra, och flyttas främst med musen—tänk på det som att organisera papper på ett skrivbord. Det är intuitivt, men ju fler papper (fönster) du lägger till, desto svårare blir det att hitta det du behöver. Vanliga exempel inkluderar Openbox, IceWM, och Fluxbox.

Nästa är kakelfönsterhanterarna. De överger papperliknande metaforen och behandlar istället din skärm som ett rutnät av kakel. Varje fönster får sin egen dedikerade plats (kakel), och inget överlappar som standard. Du kan fortfarande låta vissa fönster—som en miniräknare eller mediaspelare—flyta, men de flesta fönster kommer att kakla automatiskt.

Nu finns det två huvudmetoder för kakling: manuell och dynamisk. Med manuell kakling bestämmer du var varje fönster ska placeras och hur mycket skärmutrymme det får. i3 och Sway är populära exempel på denna stil. Med dynamisk kakling väljer du från fördefinierade layoutalgoritmer—som master-stack eller monocle—och fönsterhanteraren arrangerar automatiskt fönstren enligt den layouten. AwesomeWM, dwm, och XMonad är välkända exempel.

Personligen föredrar jag dynamisk kakling. Men om du just har kommit igång kan manuell kakling kännas mer förutsägbar. När du väl har identifierat de layouter du återkommer till kan du byta till en dynamisk fönsterhanterare och automatisera dessa layouter, vilket kan effektivisera ditt arbetsflöde avsevärt.

Skrollande fönsterhanterare är de nyaste och mest nischade av de tre. Istället för att passa in fönster i ett fast rutnät arrangerar de dem på en oändligt skrollbar duk—ofta horisontellt—så att du navigerar genom ditt arbetsområde istället för att omorganisera kakel. Niri är för närvarande det mest anmärkningsvärda exemplet på denna metod. Här är en 1-minuters YouTube-video som visar hur det fungerar:

Är den konfigurerbar med ett riktigt programmeringsspråk?

På GNOME, KDE Plasma, eller andra skrivbordsmiljöer får du en grafisk inställningssida med reglage och rullgardinsmenyer för att hjälpa dig att konfigurera dess beteende. Men alla populära fönsterhanterare konfigureras genom en konfigurationsfil—en ren textfil där du definierar exakt hur du vill att allt ska bete sig.

Nu skapas inte alla konfigurationsfiler lika. Vissa fönsterhanterare—som i3 och Hyprland—använder en egen syntax. Du skriver enkla, lättlästa textdirektiv som talar om för WM vad den ska göra. Det är lätt att plocka upp och förstå, även utan en programmeringsbakgrund. Nackdelen är att du är begränsad till de alternativ som utvecklaren har valt att exponera. Om du vill ha en funktion som inte stöds av syntaxen måste du ta till externa skript eller tredjepartsplugins.

Därefter finns det fönsterhanterare där konfigurationsfilen i praktiken är ett fullständigt programmeringsspråk. Till exempel använder Qtile Python, AwesomeWM använder Lua, och XMonad använder Haskell. Detta gör att anpassningsmöjligheterna i praktiken blir nästan oändliga. Den enda verkliga begränsningen är din bekantskap med språket. Eftersom jag inte är programmerare håller jag mig till WMs med anpassad syntax—och ärligt talat, för de flesta användningsområden är de mer än kapabla.

Med moderna AI-verktyg, att inte veta ett programmeringsspråk...

Språk är inte längre den barriär det en gång var. Du kan använda AI för att vibra kodkonfigurationssnuttar, testa dem i en virtuell maskin och distribuera dem när du är säker på att allt fungerar som förväntat.

Använder det Wayland eller X11?

De flesta moderna fönsterhanterare är byggda ovanpå antingen X11 eller Wayland som sitt displayprotokoll, och valet formar vilket mjukvara som är tillgänglig för dig, hur ditt system beter sig och vilken typ av upplevelse du får. I vår diskussion om fönsterhanterare är den mest relevanta skillnaden mellan X11 och Wayland att X11 är modulär och fönsterhanteraren och kompositorn är olika, medan kompositorn i Wayland ersätter displayservern och integrerar funktionaliteten för fönsterhantering.

Denna arkitektur gör X11 mer modulär. Om kompositorn till exempel går sönder, kommer du fortfarande ha en fungerande fönsterhanterare—men med en nedgång i visuell kvalitet. Dessutom har X11 varit standarddisplayprotokoll sedan slutet av 80-talet, vilket innebär att dussintals fönsterhanterare har byggts ovanpå det—släpp en pil blint, så kommer du nästan helt säkert att träffa en X11-baserad fönsterhanterare.

Med det sagt, detta är inte en situation där gammalt är guld. X11 har väl dokumenterade säkerhetsbrister—appar kan logga dina tangenttryckningar eller fånga innehållet i andra fönster. Det är vanligtvis inte ett problem om du är försiktig, men en mer säker plattform bör finnas, och det är vad Wayland erbjuder. Projektet startade 2008 och, förutom att vara mer säkert, erbjuder det några verkliga moderna fördelar som bättre flera-skärmsupport, VRR, fraktionell skalning och inbyggd vsync.

Å andra sidan, att göra en Wayland-baserad fönsterhanterare är något mer komplicerat eftersom det "äger hela stacken"—vilket betyder att utvecklaren måste bygga (eller implementera bibliotek för) hela ekosystemet, inklusive skärmlåsning, inaktivitetshantering och bakgrundshantering. Tillsammans med det faktum att det är ett relativt nytt protokoll, och att det inte finns så många Wayland-baserade alternativ att välja mellan. Några anmärkningsvärda exempel inkluderar Hyprland, Sway, River, Wayfire och Niri.

En annan fråga med att välja Wayland är att många appar och arbetsflöden som var kompatibla med X11 kanske inte fungerar. Lyckligtvis har XWayland-kompatibilitetslagret löst detta i stor utsträckning. Dessutom är det värt att överväga att detta problem bara är tillfälligt eftersom gemenskapen i stort rör sig mot att standardisera Wayland och ersätta X11.

Vilka andra faktorer är värda att överväga?

Utöver de tre huvudkriterier jag just har täckt finns det några andra faktorer att ha i åtanke när du väljer en fönsterhanterare—saker som hur tangentbordscentrerad den är, hur mycket tid du kommer spendera på att ställa in den, och den övergripande storleken på gemenskapen. Personligen har dessa punkter inte så stor påverkan, så jag fokuserar inte mycket på dem.

Till exempel, eftersom du rör dig mot fönsterhanterare, är det en självklarhet att du vill ha ett mer tangentbordscentrerat arbetsflöde. Det finns några fönsterhanterare som Ratpoison (dvs, gift för din mus) och XMonad som går till den extrema punkten och gör musen praktiskt taget värdelös i ditt arbetsflöde. Men de flesta fönsterhanterare behåller fortfarande viss musbaserad användbarhet—du kan använda den för att få tillgång till en högerklicksmeny, fokusera på fönster, eller till och med flytta dem. Som en fönsterhanterare-användare bör dock prioriteten vara att bli mer tangentbordsinriktad.

Nästa fråga är hur minimal fönsterhanteraren verkligen är. Till exempel, XMonad är berömd för att vara grundläggande och levereras med ingenting—ingen panel, ingen systemtråg, ingen appstartare, ingen bakgrundshanterare. Du behöver göra allt detta själv. Å andra sidan, AwesomeWM och Qtile kommer med en förkonfigurerad panel, ett systemtråg och en informationsrad—vilket är användbart för vissa och överflödigt för andra. Specifikt föredrar jag att ha något snarare än inget, särskilt eftersom dessa verktyg är superminimalistiska och kan lätt bytas ut om jag inte gillar dem.

Slutligen behöver vi prata om gemenskapens storlek. Om du är någon som gillar att bläddra på forum, ställa frågor eller hämta andras konfigurationsfiler och skript för att använda som utgångspunkt, är det logiskt att välja en mer populär fönsterhanterare—större gemenskaper betyder fler delade resurser. Jag tillhör också denna grupp. Men om du är bekväm med att läsa dokumentation och lista ut saker på egen hand, kan du gå med något nischat eller populärt—det spelar egentligen ingen roll.

Så, vilken Linux-fönsterhanterare toppar min lista?

Även om mitt huvudarbetsystem kör KDE Plasma har jag testat Linux-fönsterhanterare på ett avslappnat sätt i lite mer än ett år nu.

Denna gång har jag använt fem fönsterhanterare: Openbox, i3, AwesomeWM, Qtile och Hyprland. Här är en snabb översikt av varje:

Nu anser jag mig vara en "avancerad" nybörjare i världen av Linux fönsterhanterare—och, utifrån min erfarenhet, skulle jag sätta i3 högst upp på min lista. Det är den enklaste fönsterhanteraren att börja med. Hyprland kommer på en nära second eftersom det kan se så bra ut med några timmars installation och konfiguration. Det sagt, om du är bekväm med programmering och vill lära dig Lua, så tycker jag att AwesomeWM är ett bra alternativ, även för nybörjare.

Nu när du har läst klart Hur jag rankar fönsterhanterare för Linux, inbjuder vi dig att utforska kategorin Linux ytterligare. Där hittar du fler intressanta artiklar som kommer att utöka dina kunskaper och hålla dig informerad. Sluta inte läsa och upptäcka mer!