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, niet 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.

Reacties (53)

[cricque]

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

[RobertMe]

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.

[dmantione]

Ik ben nog niet helemaal overtuigd dat het zo zal gaan als systemd. Ook bij systemd was er weerstand en waren er wat initiatieven om sysV in leven te houden of alternatieve init-systemen te ontwikkelen. De kwestie bij X is evenwel:

• Er zijn nog steeds gaten in de functionaliteit van Wayland
• Er is een fork van X11, XLibre die zeer actieve ontwikkeling krijgt
• Er is een nieuwe X server in ontwikkeling, Phoenix, die van mening is dat niet X11 het probleem is, maar Xorg. Ook Phoenix wordt zeer actief ontwikkeld
• Met name de BSD's lijken partij te kiezen voor doorontwikkeling van X11 en tegen Wayland.

De tijd zal moeten leren in hoe verre dit levensvatbaar is, maar de hoeveelheid ontwikkeling in Xlibre en Phoenix verbaast.

[drmacfaulty]

Die Debian fork heet Devuan: https://www.devuan.org/ Voor de geïnteresseerden.

[Jeanpaul145]

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.

[cricque]

Ik gebruik nu al jaren mint (cinnamon) bijvoorbeeld, denk zelfs al +- 10 jaar (kan zelfs langer zijn). En daar is het dus experimenteel. Vroeger met plezier Redhat gebruikt en nog fedora, echter geen fan van het rpm package systeem. Je zal eerder iets vinden voor apt dan voor andere systemen. Manjaro/Arch laat ik buiten beschouwing, zou ik graag draaien maar verzekering verplicht me om secure boot op te staan hebben ... En dat is toch wel wat extra werk waar ik geen zin in heb. Draai ik wel trouwens op een laptop, maar niet op mijn "werkpc". Ik lig er echt niet wakker van, zolang het maar werkt, dat is mijn enige zorg aangezien ik dit professioneel gebruik. En zelf programmeur zijnde kan ik goed verstaan dat het niet altijd gemakkelijk is "oude" dingen te blijven ondersteunen en dat een verse start soms helemaal geen slecht idee is. Uiteraard is dit geen klein dingetje dat je zomaar kan aanpassen. Maar ik heb veel desktopmanagers gebruikt vroeger die niet standaard waren, zoals bijvoorbeeld Enlightenment, maar dat was +- 20 jaar geleden. Toen moest het er "gelikt" uitzien, nu maakt het mij geen bal uit, het moet werken en 100% stabiel zijn. En die "rust" heb ik dus gevonden door gewoon mint te gebruiken. Maar er moet uiteraard wat vooruitgang zijn en je kan niet eeuwig "legacy" dingen blijven ondersteunen, wat voor mij ook niet nodig is

[UPPERKEES]

Wayland zit al 10 jaar in Fedora. Werkt prima.

[cricque]

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]

[TheVivaldi]

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).

[Sandor_Clegane]

X11 over SSH is geweldig. X11 is een prima architectuur(conceptueel), misschien was het bijschaven gewoon handiger geweest dan die hele wayland handel.

[MAXed_out]

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

[Sandor_Clegane]

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]

[Llopigat]

Toen ze begonnen met wayland was het modern. Alles lokaal terwijl X11 gemaakt is om over een netwerk te kunnen werken. In die tijd zaten we in de piek van personal computing..

Maar nu gaan we weer steeds meer in de richting van cloud computing als aanvulling op lokaal. Dus had het weer handig geweest. Echter hadden er wel dingen aangepakt moeten worden om X11 verder te helpen. Security en latency, X11 is erg afhankelijk van vraag/antwoord API's waardoor ooit nomachine nx is bedacht om die te cachen.

Maar tegenwoordig wordt het echt tijd voor een redesign, zeg maar een X12, als ze er mee verder willen.

Ik gebruik het zelf ook nog maar dat is omdat er nog problemen zijn met wayland op mijn OS.

[Reactie gewijzigd door Llopigat op 7 februari 2026 01:45]

[Arumes]

Precies, ik gebruik dat ook nog steeds. Ik gebruik nog steeds een netbook, en door de browser op m'n desktop te draaien en alleen de GUI naar die netbook te sturen kan ik nog steeds comfortabel webbrowsen met een moderne browser.

Aan de ene kant snap ik dat veel van die oude code slecht geschreven is, volgens mij is XTerm daar een bekend voorbeeld van. Aan de andere kant ben ik ook wel van de "if it ain't broke" kant. En de mythe "herstarten is makkelijker dan X11 bij de tijd brengen" kunnen we na 17 jaar denk ik ook wel ontkrachten. Stel je voor dat die devs de afgelopen 17 jaar dezelfde energie in X11 hadden gestoken... Maar ja, iets nieuws programmeren is gewoon leuker dan iets bestaands onderhouden/bugfixen.

[Sandor_Clegane]

Yep, zie mijn andere post voor een rewrite van X11 in Zig.

[deadinspace]

X11 over SSH is geweldig.

Ik vind X over SSH met moderne applicaties onwerkbaar traag eigenlijk, zeker als je dat over het internet wil doen in plaats van het lokale netwerk.

In mijn ervaring is waypipe over SSH echt aanzienlijk sneller. Dat is tegenwoordig dus een voordeel voor Wayland ipv X11!

[StefanJanssen]

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.

[reinouts]

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.

[kozue]

En hoeveel mensen gebruiken zo'n setup? Ik heb daar iig nog nooit behoefte aan gehad. Ik heb het dan weer andersom. In Wayland zijn bepaalde dingen gewoon stuk die onder X11 prima werken. Onder andere IntelliJ was heel erg kapot, maar blijkbaar zijn ze dat al aan het aanpakken. Misschien kan ik het dan weer eens op m'n werklaptop gaan proberen.

Maar ik vind het dan weer opvallend dat je juist zoomfactors op multimonitor aanprijst als voordeel. Ik gebruik maar 1 monitor (ik heb toch maar 1 paar ogen), en had daar al problemen met scaling. Als ik een andere resolutie dan native gebruik wordt alles een beetje wazig. En als ik de native resolutie gebruik, maar scaling aan zet, zijn de meeste X11 applicaties (ja daar zijn er nog best veel van) te groot of te klein. Dus die scaling onder Wayland vind ik maar dramatisch eigenlijk. En die monitoren op kantoor zijn onleesbaar op hun native resolutie zonder scaling. Niks is te lezen op een 4K monitor (en mijn ogen zijn prima hoor).

[Arumes]

Zomaar uit nieuwsgierigheid, ik heb nog geen ervaring met Wayland: is dit een specifiek probleem van X11-apps onder Wayland? Kan je dan niet (zoals bij X11 zelf) de grootte van de lettertypes en de DPI-instelling aanpassen, als dat niet automatisch goed gaat?

Ikzelf zit op XFCE, en dus nog X11, zit nu zo'n 20 jaar op Linux, en kan me eigenlijk geen tijd herinneren waarin ik de lettertypes en de DPI-waarde van mijn scherm niet kon aanpassen. Ik gebruik nu schermen van 92 DPI (24" 1920x1080) tot 163 DPI (27" 3840x2160) en heb eigenlijk nooit problemen. Schaling staat overal uit, heb gewoon de juiste DPI ingevuld en het gewenste letterformaat ingesteld. Een 8-punts font is op alle schermen even groot, en op hogere DPI's dus juist beter leesbaar omdat de letters meer detail krijgen.

Voor de duidelijkheid: geen multimonitor met verschillende zoomfactors, maar verschillende computers met elk één scherm.

[kozue]

Kan je dan niet (zoals bij X11 zelf) ... aanpassen

Wayland en aanpassen? Zoals ik Wayland ken is het een one-size-fits-all automatische oplossing zonder configuratie bestand. Alle configuratie dient via GUI tooltjes te lopen (zoals de display config van je desktopomgeving). En voor XWayland (de emulatie laag waar X11 apps in draaien) valt er al helemaal niks in te stellen. Zeker geen DPI. Als dat wel zo is hoor ik het graag.

[reinouts]

Ik werk regelmatig op verschillende flexwerkplekken waarbij de externe monitoren diverse resoluties hebben, terwijl mijn laptop een 4k-resolutie heeft. Dan is het uitermate handig om meerdere fractionele tezoomfactoren hebben voor meerdere schermen.

Nogmaals ik heb geen idee wat er onder Wayland "stuk" is maar ik gebruik al jaren IntelliJ op Fedora onder Wayland zonder noemenswaardige issues.

[kozue]

Nogmaals ik heb geen idee wat er onder Wayland "stuk" is maar ik gebruik al jaren IntelliJ op Fedora onder Wayland zonder noemenswaardige issues.

Volgens mij is dat het grootste probleem met Wayland. Het draait goed bij sommigen en bij anderen totaal niet. En het waarom is niet bekend. Wayland is gewoon nog niet volwassenen genoeg.

[fastedje]

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.

[UPPERKEES]

Rocky zou ik niet gebruiken als desktop, probeer Fedora eens.

[kozue]

Jij gebruikt IntelliJ onder Wayland? Ik vond het onbruikbaar toen ik het een keer uitprobeerde. Wat me het meest bij stond was dat ik niet kon wisselen tussen meerdere openstaande projecten (en ik heb er altijd minstens 2 open, en dezelfde bleef altijd op de voorgrond), maar er waren nog andere dingen ook die ik me nu even niet kan herinneren.

[mxttie]

Er is nog geen deftige accessibility ondersteuning

[Aphax]

Ik draai wayland op m'n laptop (ook Fedora), ben erg blij met hoe het draait tegenwoordig en dat monitor hot plugging feilloos werkt. Voelt echt heel goed allemaal. En ik geloof ook dat Wayland de toekomst is.

Maar... ik merk wel dat er qua performance iets niet lekker gaat. Animaties en bewegingen zijn op mijn tweede scherm een stuk haperiger dan op het interne display. Alsof er iets helemaal fout gaat met de v-sync. Ook lijkt een hoge CPU load veel meer impact te hebben op hoe mijn desktop presteert. Zo kan ik m'n muis niet echt goed bewegen als ik in m'n IDE (Intellij) zit en er wat data geindexeerd moet worden en dus veel I/O doet.

Ik hoop dat dat nog verbeterd kan worden, dat voelt wel als een flinke stap achteruit t.o.v. Xorg.

[UPPERKEES]

Nvidia?

[Aphax]

Intel Arc integrated GPU (weet niet precies welke model/specs, maar hij zit in een Lenovo Yoga Slim 7 14IMH9, met een Intel Core Ultra 7 155H CPU)

[kozue]

Die ervaring had ik ook sinds ik m'n thuisdesktop vorige maand als test omgeschakeld heb. Vooral na het opstarten is de muis heel laggy voor een tijdje. En bij hoge load ook. Alsof het renderen van het scherm een te lage prioriteit krijgt tov andere processen, of misschien is Wayland zelf gewoon een resource hog? Met X11 had ik dat nooit. Ik snap die hele heisa rondom het doordrukken niet. Wayland is gewoon nog niet klaar, punt. Alles wat nu X11 aan het laten vallen is, is kortzichtig bezig (looking at you, Fedora & GNOME).

[JeroenED]

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.

[closefuture]

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.

[kozue]

Maar Wayland en Systemd zijn dan ook niet te vergelijken. Systemd is alleen om je processen op te starten. Iedere gebruiker zou zelf z'n opstart scripts aan kunnen passen aan Systemd. En Systemd ondersteuning toevoegen aan je applicatie is een klein klusje, als developer. Maar een applicatie die X11 gebruikt heb je niet zomaar even omgeschreven. Dat kan alleen de developer zelf. Tenzij je zelf developer bent en er de tijd en moeite in wilt steken. Systemd was een veel makkelijker doelwit voor een migratie.

[closefuture]

Maar Wayland en Systemd zijn dan ook niet te vergelijken. Systemd is alleen om je processen op te starten. [..] En Systemd ondersteuning toevoegen aan je applicatie is een klein klusje, als developer.

Systemd is niet enkel een initd framework om processen te starten. Het omvat veel meer dan dat. Het regelt sessie management, is een vervanger van ConsoleKit, etc. In deze blog post kun je lezen hoe bijvoorbeeld Gnome met systemd omgaat.

[kozue]

Dat is nog steeds alleen een zorg voor je desktopomgeving. Applicaties hebben daar verder niks mee van doen.

[Soldaatje]

Dat maakt ook niet zoveel uit, voor de eindgebruiker omdat X-apps gewoon draaien onder Wayland met Xwayland.

[kozue]

In theorie ja. In de praktijk werkt dat niet altijd zo. Zeker met complexe software als IntelliJ niet.

[dmantione]

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]

[gimbal]

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.

[closefuture]

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.

[aikebah]

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]

[RobinJ1995]

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]

[Jimbolino]

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...

[Solopher]

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.

[rjd22]

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.

[GertMenkel]

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.

[jabwd]

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.

[GertMenkel]

iOS-model? Wat dramatisch, zeg. Een vensterbeheerder beheer geven over vensters is weinig controversieel. Genoeg mensen die i3 of Pop_OS draaien, waar je als applicatieontwikkelaar de controle over hun vensters al ontnomen is.

Overigens heb je natuurlijk API's als layer-shell waarmee je meer controle krijgt, maar dat is alleen als de compositor en gebruiker het daarmee eens zijn. Dingen als vensters sleur & pleuren zitten al in het protocol, evenals positioners die context geven over waar welke popups ongeveer geplaatst moeten worden om UI-vaagheden als menu's buiten het scherm te voorkomen.

De hacks die je in oude programma's terug ziet komen (zoals nieuwe top-level-vensters op een coordinaat op het scherm proberen te spawnen om een tooltip te weergeven, die dan aan de andere kant van het scherm eindigt omdat scaling een ding bleek te zijn) worden onmogelijk gemaakt maar daar waar features ontbreken zijn oplossingen of worden nieuwe oplossingen gevonden.

Er zijn vast situaties te bedenken waar het voordelig kan zijn om top-level-vensters zomaar te verplaatsen, maar als eindgebruiker kan ik er maar weinig bedenken, eerlijk gezegd. Die paar programma's die echt niet zonder kunnen, zullen de komende jaren wellicht in XWayland blijven draaien.

[jabwd]

Layer-shell is idd waar ik nu op terug val om het werkend te krijgen (wel leuk trouwens dat je het linkt, want duurde even voordat ik het zelf tegenkwam toen ik er mee bezig was!).

Either way het probleem waar ik voornamelijk tegenaan loop is dat er geen linux-systeem is om te targetten; je kan simpelweg wat dingen verwachten en hopen dat het werkt maar daar blijft et bij. Distributie is gewoon vervelend op linux, hoe je het ook went of keert. Snaps of Flatpacks zijn een pleister op een groter probleem.

Misschien is het iOS-model noemen te kort door de bocht, je lijkt er meer over te weten dan ik aangezien je layer-shell nogal snel gevonden (of waarschijnlijker al wist) had, maar er zijn meer van dit soort kleine dingen waar je tegenaan blijft lopen (aldaniet wayland met security als hoofd redenering zoals met user input). Hierdoor moet ik bijv. op USB input luisteren, en daarvoor ook weer permissies toekennen die ik niet weet hoe ik die goed kan scopen of gebruiks vriendelijk maak.

Daarentegen is het een enkele API op macOS waar de gebruiker "ja" of "Nee" tegen kan zeggen, en dat ook kan afhandelen in de code zonder enige poespas. Wayland voelt voor mij als de verkeerde plek om de keuzes te maken wat wel en niet mag, misschien is dat DE niveau maar eerlijk gezegd heeft linux gewoon een base system nodig dat werkt, en niet al deze hacks en workarounds.

[Cuball]

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.

[GertMenkel]

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.

[demianmonteverd]

Wist niet eens dat dit kon, geweldig!