IntelliJ-ide's krijgen op Linux voortaan standaard Wayland-ondersteuning

De ontwikkelomgevingen (ide's) van IntelliJ voor Linux gaan in de toekomst standaard gebruikmaken van Wayland. Het gaat om IntelliJ IDEA en andere op IntelliJ gebaseerde software, zoals Android Studio en WebStorm. X11 is momenteel nog de standaard, maar Wayland neemt die rol over. X11 blijft daarbij voorlopig wel ondersteund.

JetBrains, het bedrijf achter IntelliJ, kondigt de wijziging aan in een blogpost. Vanaf versie 2026.1, die in het voorjaar verschijnt, wordt Wayland de standaard displaydriver voor alle op het IntelliJ‑platform gebaseerde ide's.

In principe verandert er weinig aan de voorkant van de software, zegt JetBrains, al zullen er wel wat kleine wijzigingen zijn. Zo zullen niet alle vensters en dialoogvensters precies in het midden van het scherm staan en kunnen andere pop-ups, zoals de algemene zoekfunctie, worden versleept naar andere plekken.

JetBrains blijft X11 wel ondersteunen. Dat maakt de software nog steeds bruikbaar op Linux-distro's zonder Wayland. Ook wijst JetBrains erop dat gebruikers implementaties zoals XWayland kunnen gebruiken voor compatibiliteit.

Wayland IDE

Door Tijs Hofmans

Nieuwscoördinator

06-02-2026 • 15:12

29

Reacties (29)

Sorteer op:

Weergave:

X11 zal nog wel ettelijke jaren blijven bestaan en zal nooit volledig verdwijnen volgens mij. Aangezien je zelf kan kiezen wat je wilt. Sommige willen wel wayland pushen, maar dat is dan weer een kip & een ei probleem
Volgens mij is er zowel door GNOME als door KDE al een moment (datum / versie) aangekondigd waarna de ondersteuning van X11 zal stoppen. En dat zal voor het grote gros van de desktop environments / window managers wel gelden. Dat ze ooit de ondersteuning van X11 stoppen (ook die wat momenteel zelfs nog geen Wayland ondersteuning hebben). Of..., uiteindelijk belanden ze in een niche markt.

Beetje vergelijkbaar met de systemd migratie. Eerst kreeg software ondersteuning voor systemd. Distro's die voorop liepen maakte vervolgens de volledige overstap naar systemd i.p.v. initd en dergelijke (Arch Linux bv, en Fedora IIRC ook). Later volgde de meer conservatieve distro's (Debian), soms met zelfs nog backwards compatibility (wederom Debian die het zelfs nog in Trixie heeft). En de distro's zonder systemd zijn een niche en eerder een fork/afgeleide van de distro's die de overstap al gemaakt hebben (IIRC kwam hier laatst nog een Debian afgeleide voorbij die "gewoon Debian" is alleen dan zonder systemd).
En hetzelfde zal vast gebeuren met X11. X11 zal wel niet "dood" gaan. Maar uiteindelijk zullen er steeds minder (main stream) distro's zijn die X11 nog leveren (o.a. doordat er ook geen DEs/window managers met support ervoor zullen zijn). Waarmee het een niche wordt.
Wayland zit al 10 jaar in Fedora. Werkt prima.
Ik zeg niet dat het niet werkt, maar er zijn genoeg mensen die er het nut niet van inzien met de insteek "if it ain't broke, don't change/fix it". Ik gebruik gewoon het meest voor de hand liggende, het zal mij worst wezen wat het is (gebruik al linux sinds 96-97). Zolang ik alles wat ik wil draaien werkt. Waar ik wel iets tegen hebben, dan is het flatpak, dan snap etc, dat is het enige wat mij dikwijls stoort voor bepaalde applicaties en als het mogelijk is, laat ik deze dan ook links liggen. Als het echt niet via apt kan (of eender welke package manager dat default is voor de distributie die ik gebruik) dan moet het toch echt iets zijn dat ik nodig heb, of het komt er niet op

[Reactie gewijzigd door cricque op 6 februari 2026 15:53]

Er zijn ook andere redenen om X11 te gebruiken. Als je bijvoorbeeld fan bent van TDE of Cinnamon, dan zit je voorlopig nog aan X11 vast (Cinnamon heeft wel een experimentele Wayland-sessie, maar met de nadruk op experimenteel).
X11 over SSH is geweldig. X11 is een prima architectuur(conceptueel), misschien was het bijschaven gewoon handiger geweest dan die hele wayland handel.
Vrijwel iedereen die veel aan X11 ontwikkeld zegt dat het niet langer geschikt is voor moderne doelen en Wayland een verse start is om verder op te bouwen.
Begrijp mij niet verkeerd X11 is heel goed waar het oorspronkelijk voor ontworpen was! Maar multi-monitor, VRR, HDR, security ivm met key en screen-capture is onhandig achteraf geïmplementeerd of simpelweg onmogelijk
Mwoah, dat valt wel mee.

Zo kan het ook: https://git.dec05eba.com/phoenix/about/
FAQ

Isn't it easier to write a Wayland compositor?

Despite popular belief, writing a simple X server that works in practice for a wide range of applications is easier to do than it is to write a Wayland compositor (+ related software).
Not many people have attempted to write an X server from scratch or have a proper understanding of the protocol, but if you do you can see that it's quite simple.
Wat jij zegt is een beetje zo'n aangenomen waarheid geworden.

[Reactie gewijzigd door Sandor_Clegane op 6 februari 2026 21:06]

Zowel X11 en Wayland hebben veel grote problemen. Bij X11 is het fundamenteel niet geweldig om die problemen op te lossen. Bij Wayland staat het fundament een stuk stevviger maar missen er een tal van belangrijke features.
Ik weet niet precies welke belangrijke features ontbreken, maar ik weet wel dat Wayland meerdere monitoren ondersteunt met afzonderlijke zoomfactors. En dat is iets dat X11 niet kan.
Toch ercaar ik nog regelmatig crashes van IntelliJ op Wayland. Verder ontbreekt op Rocky9 van KDE Plasma support voor gamma setttings. Als je color profiles wilt hebben dan moet je zelf een scriptje in elkaar flansen om die profiles aan te maken, zonder deze profiles is het beeld op veel schermen niet om aan te zien.

Misschien is de X11 code base niet te onderhouden, maar Wayland heeft nog heel wat in te halen.
Rocky zou ik niet gebruiken als desktop, probeer Fedora eens.
Het eeuwige legacy vraagstuk volgens mij. Op fosdem een talk gezien waarbij de insteek was dat iemand in 2018 of zo nog een pc met Microsoft Bob gebruikte en die pc moest migreren. Ik denk dat wel nog dergelijke mensen zijn. Feit blijft ook dat er tal van bedrijven zijn die denken "if it ain't broke, don't fix it" en dan maar een imac uit 2007 van de V&A kopen om die software daar opnieuw op te installeren wanneer de oude gecrasht is.
Aangezien je zelf kan kiezen wat je wilt.
Enkel in theorie. In de praktijk gaat dat een lastige worden. Bijvoorbeeld Xorg is altijd uit Fedora 43. Fedora is altijd wel een voorloper maar andere distro's zullen uiteindelijk volgen. Er zijn simpelweg vrij weinig maintainers die zowel Xorg als Wayland willen blijven onderhouden.

Je kunt praktisch gezien ook niet om systemd heen in Linux.
Nou ik vermoed dat mainstream distros liever eerder dan later van de familie aan Xorg packages af willen.
De Xorg maintainers hebben (inmiddels jaren geleden) aangegeven dat het hele subsystem praktisch niet te onderhouden is, wat weer (bewust of onbewust) een vorm van druk is op package maintainers om daarvan af te willen.
Zelf heb ik daar gemengde gevoelens bij: aan de ene kant vind ik dat 't pas weg moet wanneer elke Xorg use case door Wayland ondersteund wordt, maar aan de andere kant als Xorg echt zo ononderhoudbaar is, is dat geen activa maar een enorme passiva, niet in de laatste plaats vanwege de enorme security holes (sommigen daarvan bij design) die nooit gepatcht zullen worden.
Dat maakt ook niet zoveel uit, voor de eindgebruiker omdat X-apps gewoon draaien onder Wayland met Xwayland.
De kwestie Wayland/X11 is vooral zaak van de onderliggende GUI-toolkit, zolang GTK en Qt e.d. X11 ondersteunen, is er voor eindgebruikersapplicaties geen reden om de één of de ander niet te ondersteunen.

Verder vind ik dat ontwikkeltools de laatsten moeten zijn die ondersteuning stopzetten: Programmeurs kunnen allerhande reden hebben om oudere software te willen onderhouden en dus is het ook belangrijk dat ontwikkelgereedschappen ook voor lange tijd oude omgevingen blijven ondersteunen.

[Reactie gewijzigd door dmantione op 6 februari 2026 15:28]

De IDE is dan wel op Java gebaseerd en gebruikt de sterk verouderde Java Swing toolkit. Dat zou in de toekomst de nodige beperkingen met zich mee kunnen brengen zodat X11 niet meer te handhaven is. Dat heb je met laagjes, je hebt alleen controle over het laagje wat je zelf maakt.
Dat zou in de toekomst de nodige beperkingen met zich mee kunnen brengen zodat X11 niet meer te handhaven is.
Het lijkt erop dat je niet een volledig beeld hebt van wat hier nu gebeurt.

De changes die IntellIJ nodig heeft voor Wayland zitten nu op dit moment in een fork van OpenJDK die Jetbrains mee distribueert met IntellIJ. Echter zijn de changes onderdeel Project Wakefield, het project om Wayland ondersteuning aan OpenJDK toe te voegen.
De IDE is dan wel op Java gebaseerd en gebruikt de sterk verouderde Java Swing toolkit.
Nee, het gebruikt de Java XToolkit (en straks de Java WLToolkit) op Linux, de Java LWCToolkit op mac OS en de Java WToolkit op Windows
edit:
toolkits voor macOS en Windows aangevuld

[Reactie gewijzigd door aikebah op 6 februari 2026 16:10]

Java-applicaties maken geen gebruik van GTK of Qt (daarom dat die heel vaak ook minder native aanvoelen). Hetzelfde is tevens van toepassing op Windows en MacOS; Java maakt geen gebruik van de default toolkits. Dus dat is niet aan de orde in dit geval.

[Reactie gewijzigd door RobinJ1995 op 6 februari 2026 15:40]

De omgeving waar je de code typt, hoeft natuurlijk niet dezelfde te zijn als waar je de code uitvoert.

Docker en virtual machines bestaan daarvoor...
Wat ik wel weer grappig vond:
The splash screen on IDE startup will not appear as it cannot be reliably centered on the screen.
En:
You may notice a few changes in the UI when running these Wayland-by-default versions of IntelliJ IDEs. For instance, some windows and dialogs, like Project Structure or various alerts, may not always center on your screen or stick to their previous locations. This happens because the window manager in Wayland has complete control over where windows sit, and apps cannot always override that.
Ik moet zeggen dat ik nog geen 2026.1 heb geprobeerd op KDE met Wayland, dus ben er zelf nog niet tegenaan gelopen.
Dit heeft ook te maken dat applicaties teveel misbruik maakten van deze feature. Om dit misbruik tegen te gaan mogen applicaties niet meer exact de plaatsing van de popup bepalen. Het is ook meer een veiligheids feature dan dat het een bug is in Wayland.

Zo zijn er wel meer dingen die applicatie bouwers misschien vervelend vinden. Maar het idee van wayland is dat de gebruiker in control is niet de applicatie bouwer.

Dit geeft mogelijkheden om context popups bijvoorbeeld op een ander scherm te projecteren of zelfs misschien in een klein schermpje in je toetsenbord. Als applicatie bouwers in control zouden zijn zou dit niet kunnen.
Het is vooral een uitdaging als je gebruik maakt van de feature om panelen in losse vensters te stoppen en je workflow af te laten hangen van dat IntelliJ die vensters op zijn plek houdt bij openen/sluiten. Een beetje zoals de hele ouderwetse Photoshop/GIMP-manier van werken.

De functie "zet venster terug waar hij was" zit ook al in zo'n beetje iedere DE, al is de mate waarin je die kunt tweaken natuurlijk verschillend per omgeving. Je workflow kan dus blijven bestaan met die methode, maar je zult het vanaf nu met je bureaubladomgeving moeten uitvechten.

Ik denk niet dat dit veel mensen zal raken. Een andere groep mensen die voorheen hacks nodig hadden (bijvoorbeeld bij de i3-stijl windowmanager zoals Sway) zullen juist een kreet van opluchting slaken: eindelijk baas over eigen vensters, geen tegenstribbelen meer van de IDE.
Dat is inderdaad leuk van dat perspectief gezien, maar als applicatie ontwikkelaar is het tegelijkertijd weer een nachtmerrie. Tuurlijk moet de gebruiker altijd de baas zijn over hun eigen omgeving maar het letterlijk onmogelijk maken van bepaalde features en of use cases helpt gewoon niet.

Zelfs apple geeft escape hatches voor alle vage restricties die je tegenwoordig hebt op macOS, en op Linux zijn we blij met het iOS model tegenwoordig? Het is echt raar.
Zal dit ook een verbetering geven waarbij Intellij op een WSL2 machine draait? Nu toch af en toe problemen met verliezen van beeld na een netwerk onderbreking o.i.d.
Wist niet eens dat dit kon, geweldig!
Waarschijnlijk niet.

Als je IntellJ voor Linux op WSL2 hebt geïnstalleerd werk je effectief via RDP over een virtuele pijp tussen Windows en de virtuele WSL2-machine. Die virtuele machine draait een Wayland-compositor, maar puur om RDP aan te bieden (tenzij je hem zelf helemaal anders instelt natuurlijk).

Als je X11 forwarding met een Windows X-server gebruikt, verandert er niks, omdat dit alleen Wayland-modus beïnvloedt.

Als je in die setups je netwerkverbinding verliest, zit iets te klooien met je netwerkinterfaces tijdens het slaap/wakkerwordtproces. X11 heeft de mogelijkheid om zijn verbinding terug te krijgen (al is dat makkelijker gezegd dan gedaan), als bij Wayland de renderpipeline sterft dan is het over het algemeen voorbij. De virtuele WSL2-machine is verbonden via een virtuele adapter, dus er is geen hardwaredriver van derden als het goed is.

Wat wel zou kunnen is dat je bijvoorbeeld in de Hyper-V-instellingen de standaardnetwerkkaart van WSL2 hebt toegewezen aan een bridge voor een fysieke netwerkkaart. Die bridge kan verdwijnen als de netwerkkaart uit gaat. In dat geval kun je beter de WSL2-adapter resetten en een losse adapter maken voor je Hyper-V-virtual machines.

Als je IntelliJ op Windows draait in de modus dat die containers/commando's binnen WSL uitvoert, verandert er ook niks, want Windows gebruikt noch Wayland noch X11.

Om te kunnen reageren moet je ingelogd zijn