Mir ist das jetzt zu aufwändig selber was zu schreiben und hab deshalb mal "Why is Wayland better than X" in google eingegeben und z.B. das hier gefunden: http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1
Der verlinkte Artikel wurde von Daniel Stone gegengelesen und mit Input versorgt. Dem kann man in diesen Fragen völlig vertrauen und seine Meinung ist da besser als meine.
Daniel Stone ist einer der wenigen lebenden Menschen, die Teile von X verstehen und aktiv bei Wayland involviert. Er ist jemand, dessen Meinung ich voll unterstütze. Wenn du meine Meinung willst, dann kopiere ich einfach den Text und schreibe meinen Namen drunter.
Xorg ist Software aus den 80ern. Gibt 2 Gründe, warum das für das ganze Open Source Ökosystem fatal ist:
1. Es müssen ständig Sachen gepatcht werden, nur um neue Funktionalität zu bringen. Das mag einige vielleicht nicht interessieren, aber es gibt Sachen, die wir auf Xorg nur sehr schwer machen können, die aber auf dem Stand von 2003 sind. Compositing, gescheiter Vsync in Videos, banale Sachen wie, dass das System eben nicht 10x das Bild scannt, nur um zu sehen, ob Xorg richtig geraten hat, wo ich das Video oder das Bild hinhaben will. Das sind alles Sachen, die Wayland kann, man es Xorg aber umständlich beibringen muss, weil es wie ein verwirrter Höhlenmensch ist, den man mit einer Zeitkapsel in unsere Zeit geholt hat und nun lehren will, wie er als moderner Mensch leben soll.
Aber lassen wir mal einen ex-Xorg Dev und jetzigen Wayland Dev zu Wort kommen, der hat das viel besser und einfacher erklärt als ich (dauert allerdings ne drei Viertel Stunde):
https://www.youtube.com/watch?v=RIctzAQOe44
2. Sicherheit
Lest euch den anderen Blog Beitrag von Martin Grässlin durch, wo er darauf eingeht, warum ein sicherer Lock Screen in X nicht möglich ist:
3. Kommt mir bitte nicht mit Netzwerk-Transparenz! Die wird in die Widgets ausgelagert werden. Zumindest wird das bei QT5 und GTK3 der Fall sein. Wenn andere Widgets da nicht mitziehen aus irgendwelchem konservativen "Früher war alles besser" Getue, dann sei's drum! Und wirklich? Ihr habt noch Admin Tools die in Motif oder GTK1 geschrieben sind? Pech gehabt! Benutzt Konsoletools oder schreibt sie mal eben in QT5 um -- bin sicher, dass das viel einfacher ist, als damals, als ihr es für Motif geschrieben habt.
Wenn ich solche Diskussionen oder Monologe lese, dann fällt mir imemr auf, dass Wayland-Befürworter größtenteils nur die Nachteile von Xorg im Vergleich zu Wayland darstellen.
Warum schreibt man denn einfach nicht darüber, welche Vorteile Wayland gegenüber Xorg besitzt und was darin an Neuem existiert, was in Xorg noch gar nicht vorhanden ist?
Aus Deinem Punkt 1. kann ich nicht wirklich herauslesen, was die genauen (vielleicjt auch entscheidenden) Vorteile von Wayland gegenüber Xorg sind. Wayland macht anscheinend irgendetwas besser als Xorg, nur was genau? Compositing z.B. gibt es auch im Xorg-Bereich.
Punkt 2. ist sicher nicht unwichtig, falls Wayland das hinbekommt und Xorg nicht, dann ist es in diesem einem Punkt etwas besser als Xorg. Der Hauptvorteil von Wayland gegegnüber Xorg kann das aber auch nicht wirklich sein.
Punkt 3. zeigt, dass Wayland etwas nicht vermag, was Xorg nun kann und das ist IMO deshalb kein Vorteil für Wayland. Wayland ist jetzt ja wohl nicht deshalb der große Wurf, weil es die Xorg-Netzwerktransparenz nicht mehr besitzt. Die Xorg-Netzwerktransparenz ist geradezu genial, auch wenn man diese heute gerade als Nutzer gar nicht mehr benötigt.
Argumentativ hängt das Ganze meiner Meinung nach etwas schief. Wayland ist bestimmt nicht charakterisierbar als Xorg minus Xorg-Features, die man heute als antiquiert ansieht.
Wayland macht anscheinend irgendetwas besser als Xorg, nur was genau? Compositing z.B. gibt es auch im Xorg-Bereich.
Um da mal ein Beispiel zu nennen: in Wayland sind alle status Änderungen zu einer "Surface" (sowas wie ein Fenster) double buffered und werden erst aktiv wenn der Client sagt "jo ist jetzt alles gesetzt, Status ist konsistent".
Unter X11 gibt es so was nicht. Status Änderungen werden direkt umgesetzt. Also z.B. Fenstermanger setzt eine neue Fenstergröße auf ein Fenster. Alles in X11 meint dann, dass dies die neue Fenstergröße ist, aber das Fenster hat dann noch nichts davon gehört, geschweige denn neu gezeichnet. Nun gibt es komplizierte sync Protokolle um das weg zu kaschieren, aber es bleibt: X11 meldet bei einem resize falsche Fenstergrößen. Es ist nicht ein "hey Fenster geh mal bitte auf diese Größe und sag mir wenn du damit fertig bist", sonder ein "das ist jetzt die Größe".
Solche konzeptionellen Fehler gibt es viele in X11. Diese zu behben braucht ein neues Protokoll. Könnte man X12 nennen oder halt Wayland.
"Wenn ich solche Diskussionen oder Monologe lese, dann fällt mir imemr auf, dass Wayland-Befürworter größtenteils nur die Nachteile von Xorg im Vergleich zu Wayland darstellen."
Ja, und die Nachteile überwiegen doch in den meisten Fällen. Außer der mythischen Netzwerktransparenz und dem Totschlagargument "Es ist nicht fertig" habe ich keine guten Argumente gehört. Die Netzwerktransparenz ist noch nicht da, aber sie wird eh Sache der Widgets werden. Du siehst also, dass ich durchaus auch diskutiere und keine Monologe führe
"Warum schreibt man denn einfach nicht darüber, welche Vorteile Wayland gegenüber Xorg besitzt und was darin an Neuem existiert, was in Xorg noch gar nicht vorhanden ist?"
Habe ich doch schon: besserer Vsync, kein Videofenster, dass 3 Sekunden länger braucht, um mit dem Browser in den es eingebettet ist hinterherzukommen, keine Fenster, die raten müssen, wo X was hinknallt und das dann mit mehr Resourcen kompensieren müssen. Übrigens alles Sachen, die im Video erklärt sind. Würde es dir sehr empfehlen, weil es dort eben kein Laie wie ich erklärt, sondern ein ehemaliger X Entwickler/heutiger Wayland Entw.
"Aus Deinem Punkt 1. kann ich nicht wirklich herauslesen, was die genauen (vielleicjt auch entscheidenden) Vorteile von Wayland gegenüber Xorg sind. Wayland macht anscheinend irgendetwas besser als Xorg, nur was genau? Compositing z.B. gibt es auch im Xorg-Bereich."
Ja, Compositing gibt es, aber wie schon vorher gesagt, wird es sehr schlecht gemacht. Der Videolink erklärt es ganz gut.
"Punkt 2. ist sicher nicht unwichtig, falls Wayland das hinbekommt und Xorg nicht, dann ist es in diesem einem Punkt etwas besser als Xorg. Der Hauptvorteil von Wayland gegegnüber Xorg kann das aber auch nicht wirklich sein."
Wie, die Tatsache, dass jeder halbwegs gute Programmierer mit sehr wenig Mühe jede Lock Screen Implementation knacken kann ist kein guter Grund gegen Xorg? Wow! Es war allerdings auch nur 1 Beispiel davon, wieviele Löcher der schweizer Käse namens Xorg hat. Siehe auch diese Meldung, wo sich rausstellt, dass der Code mittlerweile so komplex ist, dass Leute extra dieses Monster auditen und dann 23 Jahre alte Sicherheitsklücken finden: http://www.phoronix.com/scan.php?page=news_item&px=MTU1NzA
"Punkt 3. zeigt, dass Wayland etwas nicht vermag, was Xorg nun kann und das ist IMO deshalb kein Vorteil für Wayland. Wayland ist jetzt ja wohl nicht deshalb der große Wurf, weil es die Xorg-Netzwerktransparenz nicht mehr besitzt. Die Xorg-Netzwerktransparenz ist geradezu genial, auch wenn man diese heute gerade als Nutzer gar nicht mehr benötigt."
Warum ist sie genial und warum ist es schlecht, wenn das in die Widgets ausgelagert wird?
Aber in der Linuxwelt scheint alles, was an Code Ü30 ist, den selben Stellenwert zu haben wie der alte, vermeintlich weise Greis in der Sippschaft, der sich so jedweder Kritik immer entzieht.
"Argumentativ hängt das Ganze meiner Meinung nach etwas schief.
Warum?
"Wayland ist bestimmt nicht charakterisierbar als Xorg minus Xorg-Features, die man heute als antiquiert ansieht."
Gerade das will es ja sein. Es ist bei weitem noch nicht so weit, wie wir es gern hätten, das stimmt, aber es hat schon sehr viel geschafft.
Punkt 3. zeigt, dass Wayland etwas nicht vermag, was Xorg nun kann und das ist IMO deshalb kein Vorteil für Wayland. Wayland ist jetzt ja wohl nicht deshalb der große Wurf, weil es die Xorg-Netzwerktransparenz nicht mehr besitzt. Die Xorg-Netzwerktransparenz ist geradezu genial, auch wenn man diese heute gerade als Nutzer gar nicht mehr benötigt.
Prepare for a shock: https://youtu.be/RIctzAQOe44?t=1071
Falls du es (aus welchem Grund) nicht anschauen willst. Was er dort sagt ist: X ist nicht mehr netzwerk-transparent, da praktisch ausschließlich SHM und DRI2 verwendet werden, welche nicht netzwerk-transparent sind. Es ist netzwerk-fähig.
Und in dem von Martin verlinkten Artikel wird das auch noch klassifiziert, dass es wie eine schlecht implementierte Version von VNC funktioniert. Mit anderen Worten: Dieses Netzwerktransparenzargument (was ein Wort ;)) gibt es nicht mehr.
Das Problem liegt bei X doch tiefer, nicht beschränkt auf Bildschirmsperren - jede Anwendung kann die Eingaben jeder anderen Anwendung abgreifen (zumindest manches davon scheint Wayland besser zu machen; eine weitergehende Lösung bietet Qubes): http://theinvisiblethings.blogspot.de/2011/04/linux-security-circus-on-gui-isolation.html
Vorteile aus meiner Sicht: - X11 als Abstraktionsschicht hat über 20 Jahre Altlasten, was zu sehr vielen Schwierigkeiten in der Wartung (sowohl von X.org als auch Anwendungen die dessen diverse APIs benutzen) führt und langfristig Arbeitskräfte/Arbeitszeit an sich bindet, die woanders sinnvoller eingesetzt wären. Da Wayland von 0 anfing aber aus den Erfahrungen von X und anderen Plattformen gelernt hat, ist Wayland im Vergleich eine extrem dünne, leichte Abstraktionsschicht, die aber dennoch wahrscheinlich sogar besser die Anforderungen moderner Desktops/(oder jeder andere Formfaktor) erfüllt, da mehr Flexibilität eingebaut ist und die GUI-Toolkits sozusagen bei vielen Dingen "freie Hand" bekommen, die vorher unheimlich komplixiert über X liefen oder gar nicht erst ohne Workaround gingen. - Wayland wurde von den teilweise wichtigsten X.org Entwicklern initiiert, es ist also nicht so dass eine Gruppe die andere übertrumpfen wollte, die X-Entwickler selber (z.B. Keith Packard) wussten halt am besten, dass die Modernisierung von X aufgrund der Altlasten ein Auslaufmodell ist. - X läuft zwar bei mir auch wirklich stabil, dass ich als User auch nicht meckern kann, aber als Entwickler hab ich z.B. schon öfter Probleme gehabt meine Ideen umzusetzen wegen den begrenzten Möglichkeiten einer GUI unter X. Bin bestimmt nicht der einzige der sich deswegen mit Features "zurückhalten" musste, weil es einfach keinen Sinn machte 6 Monate an einem Workaround zu arbeiten, das auf einer besseren Platform in einer Stunde möglich wäre. - Wenn man eine Wayland-Session startet egal ob nestet unter X oder direkt, und selbst nur ein Terminal drauf bedient, merkt man wenn man für sowas empfindlich ist definitiv, dass die Reaktionszeiten besser sind (weniger Roundtrips, leichtere Platform/Bibliotheken/Infrastrutur). Das muss einen jetzt nicht umwerfen und dazu bringen X zu hassen und auf Wayland sehnsüchtig zu warten, aber es zeigt halt, dass Wayland den Weg Richtung Zukunft weist, während X selbst nach 20 Jahren Optimierung letztenendes sich selbst im Weg steht.
Das sind die Punkte interessanten Punkte aus meiner Sicht.
Suche übrigens einen Job im Linux-Open-Source-Bereich, oder der damit zu tun hat, wenn jemand denkt er hat was für mich, könnte er mir vielleicht nen Hinweis hinterlassen.
Von jean michel jarre am Di, 30. Juni 2015 um 15:22 #
Vorneweg, Wayland wird hier als Synonym verwendet.
Kannst dabei auch die Vorteile von X aufzählen: - X funktioniert. Stabil, nicht nur auf Linux, erprobt, alle gängigen Bibliotheken können damit umgehen. Wird noch Jahre dauern damit Wayland da gleichzieht. - Wayland wurde von keinen X-Entwickler initiert. Diese sind wie Programmierer nun mal sind, zu den neuen Fancy-Stuff gewechselt. Bei X ist die Entwicklung sehr langsam und konservativ. - X wird von einen unabhängigen Organisation entwickelt. Wayland hingegen stark linuxzentriert. - Wayland ist nicht erwachsen, bis heute wird am Unterbau rumgeschraubt.
Frag doch mal den Martin, seine Bude sucht doch immer fähiges Personal.
Kristian Høgsberg hat an X mitgearbeitet, z.B. AIGLX. Evtl. war er nicht einer der Hauptentwickler, aber wen interessiert das schon. Wichtig ist, dass viele die früher an X mitgearbeitet haben und vor allem X so halbwegs verstehen von Wayland überzeugt sind und das Konzept mittragen.
- X wird von einen unabhängigen Organisation entwickelt. Wayland hingegen stark linuxzentriert.
Wie kommst du darauf? Wayland selbst hat keine Plattformabhängigkeit. Beim Compositor sieht es schon anders aus, aber da wird es auch welche für BSD geben. Prinzipiell sollten es sogar leichter sein Wayland-Clients auf Windows zu portieren als das mit X der Fall ist.
- Wayland ist nicht erwachsen, bis heute wird am Unterbau rumgeschraubt.
Ja, aber wie in dem von Link versionisiert. Wenn Programm X nur libwayland-1.0 unterstützt, dann bekommt es auch genau das.
Das einzige Argument, dass hier Sinn macht ist: Wayland ist unfertig. Alles andere ist deine Meinung. Ich kann dir zig Dinge nennen, warum Xorg nicht stabil für mich ist: Ständige Vsync Regressionen, Speicherleck hier und da, kein Alt-Tab möglich zwischen z.B. Videospiel und Desktop, und und und... "Bei X ist die Entwicklung sehr langsam und konservativ." Da gebe ich dir Recht, deshalb hat sich da seit 30 Jahren nichts gescheites getan. Um nochmal auf dein einzig nutzbares Argument zurückzugehen: Wayland ist nicht fertig, nein. Aber X11 wird auch nicht einfach so von heute auf morgen abgelöst werden. Es wird an Wayland rumgeschruabt, aber es kriegt in weniger Entwicklungszeit mehr hin, als Xorg in 30 Jahren.
Wayland als Protokoll und als Bibliothek ist fertig. Was nicht fertig sind, sind die Portierungen der Desktop Umgebungen.
Ich nutze schon seit einiger Zeit ein Smartphone welches Wayland als Fenstersystem einsetzt. Das sollte eigentlich Beweis genug sein, dass Wayland fertig ist.
Ich nutze schon seit einiger Zeit ein Smartphone welches Wayland als Fenstersystem einsetzt. Das sollte eigentlich Beweis genug sein, dass Wayland fertig ist.
Nur Bedingt.
Die Anforderungen für verschiedene Geräte können unterschiedlich sein. Das merkt ja auch das Plasma Team immer wieder, wenn es um Tablets und Smartphones geht.
Es gibt ja durchaus noch offene Fragen bei Wayland und deshalb auch neue Releases, aber die Grundlagen sind gelegt und die Portierung der Desktop Umgebungen ist tatsächlich momentan das größte Hindernis, da hast du auf jeden Fall recht.
Man bedenke auch dass das X Window System 31 Jahre alt ist (wenn ich korrekt gerechnet habe). Für eine Software ist das ein Imenses Alter. Obwohl ich (sebstverständlich) davo ausgehe, dass sich alle Entwicker Mühe geben - da schleppt man einfach irgendwann Altlasten mit. Erst recht bei einem derart grossen Projekt. Das ist ein bisschen Mehr Code als bei einem Java Taschenrechner
Jeder der Programiert weis, das bei jedem Projekt irgendwann der Punkt kommt, and dem man am besten neu anfängt. Ganz einfach weil die Technologie nichtmehr dieselbe ist wie for 30 Jahren, und das ewige herumgepatche irgendeinmal nur noch einen riesen Flickentepich. Also: Einstapfen -> Neu anfangen.
Im Endeffekt wird man als User erstmal nicht wirklich viel davon haben, aber das muss ja auch gar nicht der Fall sein. Langfristig wird es sich sicherlich bemerkbar machen.
ja wollte auch gerade den link posten, 18:30min is funny, Was mich an X stoert ist das beim bildschirmschoner es nicht moeglich ist die Lautstaerke zu aendern! (erklaerung auch im video)
Im Endeffekt wird man als User erstmal nicht wirklich viel davon haben, aber das muss ja auch gar nicht der Fall sein.
Ich wäre schon froh, wenn ich von den Nachteilen von Wayland verschont bliebe. Und da bin ich womöglich nicht der Einzige.
Ich muss mich mit den Nachteilen herumschlagen und dabei benutzte ich Wayland noch nicht einmal. So sind GNOME 3-Anwendungen außerhalb deren Desktopumgebung leider zur Zumutung geworden, da man wegen Wayland auf einen Fenstermanager verzichtet - auch unter X11. Jede GNOME 3-Anwendung ist nun selbst für ihr Fenster und dessen Steuerelemente verantwortlich.
Endlich lassen sich ausgelastete Applikationen - so wie unter Microsoft Windows gewohnt - nicht mehr in der Größe ändern, maximieren, verschieben, beenden usw. Auf diesen Rückschritt hätte ich gut und gerne auch die nächsten 30 Jahre verzichten können.
Zudem verlieren Monitore seit Jahren immer weiter an Höhe (4:3 -> 16:10 -> 16:9), wer da auf die Idee kommt die Titelleiste der Fenster nun doppelt so hoch zu zeichnen...
Wayland mutiert indirekt bereits zur Usability-Katastrophe bevor man es überhaupt einsetzt. Das ist traurig. Die Usability des Desktops hat sich in den letzten Jahren ohnehin kaum weiterentwickelt. Sicher, überall gibt es nette Effekte und alles sieht toll aus, das Eye Candy ist super aber das hat nichts mit Usability zu tun. Es gibt kaum Stellen an denen ein moderner Desktop tatsächlich die Produktivität steigert. Wir können es uns überhaupt nicht leisten, Usability über Bord zu werfen.
Würde man auf den Fenstermanager verzichten können, würde es nicht so großen Aufwand bedeuten, KWin zu portieren, oder?
Der einzige Unterschied ist, dass sich Primär- und Sekundärbzeichnung verschoben haben.
Bei X11 hatten Fenstermanager, wie z.B. KWin, auch die Aufgabe des Compositor übernommen. Bei Wayland übernehmen Compositor, z.B. KWin, auch die Aufgabe des Fenstermanager.
D.h. Fenstermanager mit eingebautem Compositor erfüllen weiter beide Aufgaben, nur Fenstermanager ohne Compositor wird vermutlich nicht mehr geben.
Die Aufgaben des Fenstermanagers können unter Wayland clientseitig oder serverseitig umgesetzt werden. Der Compositor muss diese Aufgabe nicht übernehmen und tut es im Falle von Weston (Wayland-Referenzimplementierung) und GNOME 3 auch nicht. Es wird erwartet, dass diese Aufgaben die Anwendung selbst übernimmt, im Falle von GNOME 3 gilt diese Änderung selbst unter X11.
Du liegst etwas falsch. Der Fenstermanager hat unter Wayland sogar noch viel mehr Kontrolle und Macht als unter X11. Unter X11 konnten Anwendungen Fenstermanager spielen, dies ist unter Wayland nicht mehr möglich. Eine Anwendung kann nicht sagen, dass sie jetzt ganz oben im Stack ist und dass sie jetzt sich Input nimmt.
Die Aufgaben des Fenstermanagers sind damit weiterhin beim Fenstermanager und nicht bei den Anwendungen.
Du scheinst mir den Fenstermanager auf Fensterdekos zu reduzieren. Hierzu kleiner Hinweis: X11 und Wayland haben genau die gleichen Vorgaben zu dem Thema: keine!
Nein, ich meine nicht nur die Fensterdeko. Ich meine in der Hauptsache die Steuerelemente des Fensters welche dem Fenster zur eigentlichen Funktion verhelfen. Die Deko erfüllt üblicherweise keinen Selbstzweck sondern ist in erster Linie dazu da, die Steuerelemente des Fensters einzubetten.
Beides sind klassische Aufgaben des Fenstermanagers und auch wenn X11 keine Vorgaben macht so ist es seit gefühlten Ewigkeiten üblich, diese Aufgaben durch einen Fenstermanager umzusetzen.
Möglicherweise müssen alle Protagonisten erstmal wieder alle Möglichkeiten durchspielen, bis sich der Status quo erneut einstellt. Möglicherweise war dies bei X genauso, nur ist dies glücklicherweise schon 30 Jahre her. Dem Desktop wird dies IMHO kurz- und mittelfristig kaum nützen.
Wayland erfordert nicht, dass Fensterdekos von den Anwendungen erstellt werden müssen. Dies ist eine Design Entscheidung von GNOME. Dafür ist einzig GNOME verantwortlich, bitte mach dafür Wayland nicht verantwortlich.
Nicht die Referenzimplementierung von Wayland, sondern die Referenzimplementierung für einen Wayland compositor. Ein kleiner aber in diesem Fall feiner Unterschied.
Ich kann deinen Einwand aus Entwicklersicht nachvollziehen. Für den Entwickler ist Wayland in erster Linie das Protokoll und dessen Library. Der Nutzer nimmt Wayland hingegen vielmehr als Projekt wahr.
Jetzt gibt es noch nicht so viele Implementierungen des Wayland-Compositors, aber gibt es neben KWin überhaupt noch einen, der die üblichen Fenstermanager-Aufgaben serverseitig implementiert?
Führt es nicht ins Chaos und zur weiteren Abspaltung der unterschiedlichen Desktopumgebungen, wenn es jeder zweite Compositor anders implementiert?
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 01. Jul 2015 um 17:48.
Ich würde davon ausgehen, dass der Compositor immer auch der Fenstermanager ist, weil er der einzige Prozess im Gesamtaufbau ist, der alle Fenster kennt, alle Benutzereingaben bekommt, usw.
Martin kann das sicher genauer ausführen, aber nur der Compositor entscheidet, ob, wo und wie er ein Fenster anzeigt. Die Anwendungen können, wie bei einem X11 Fenstermanager, maximal um bestimmte Positionierung bitten.
Bei Weston, der Wayland-Referenzimplementierung (des Compositors), sowie bei GNOME 3 werden die Aufgaben des Fenstermanagers vom Client, also von der jeweiligen Anwendung umgesetzt. Bei GNOME 3 erfolgte diese Änderung wegen der Wayland-Integration selbst unter X11.
Sämtliche GNOME 3-Fenster verhalten sich deshalb als Fremdkörper, wenn diese nicht unter der GNOME 3-Desktopumgebung genutzt werden.
Die grundsätzlichen, funktionalen Nachteile, wenn die Anwendung Fenstermanager-Aufgaben übernimmt, hatte ich bereits genannt.
Bei KWin sollen Fenstermanager-Aufgaben hingegen serverseitig erfolgen, als Teil des Compositors. Das dürfte mit dem unter X11 üblichem Verhalten vergleichbar sein (aus Nutzersicht).
Es ist unter Wayland keineswegs selbstverständlich, dass sich der Fenstermanager im Compositor befindet. Es gib bereits zwei Implementierungen, darunter die Referenzimplementierung des Wayland-Projektes welches es anders machen und im Falle von GNOME 3 hat dies selbst Auswirkungen auf X11-Nutzer.
Was ich meine habe ich in meinem ersten Beitrag dargelegt. Ich habe dort u. a. den Fensterdekorationen einen Seitenhieb verpasst. Ebenso habe ich auf die Steuerelemente des Fensters Bezug genommen.
In deinem ersten Beitrag bist du fälschlicherweise davon ausgegangen, dass man bei Wayland auf einen Fenstermanager verzichtet: "...da man wegen Wayland auf einen Fenstermanager verzichtet..."
Das ist, wie Martin unter anderem dann genauer erklärt hat, nicht der Fall. Unter Wayland sogar noch weniger als unter X11.
Der klassische Fenstermanager ist unter X11 ein eigenständiges Programm. Wayland kennt das Konzept eines eigenständigen Fenstermanagers hingegen nicht. Darauf bezog sich meine Aussage.
Die Aufgaben des Fenstermanagers fallen natürlich weiterhin an und müssen umgesetzt werden. Ich habe deshalb in den Folgebeiträgen versucht von den Aufgaben des Fenstermanagers zu sprechen (versucht, aber leider nicht konsistent durchgehalten).
Du hast mich irgendwo abgehängt. Was ist denn für dich der Unterschied zwischen "Fensterdekorationen" und "Steuerelemente des Fensters"? Für mich ist das das gleiche!
Ist sicher eine Definitionsfrage, unter einer Dekoration verstehe ich die Ausschmückung rund um das Fenster, also eine passive Komponente. Der Hinweis mit der doppelt so hohen Titelleiste bezog sich auf die Dekoration.
Die Steuerelemente sind hingegen die aktiven Komponenten. Da gehören die Buttons wie minimieren, maximieren, schließen dazu aber auch beispielsweise das Verschieben des Fensters über die Titelleiste. Alles was eine Funktion ingangsetzt, welche sich auf das Fenster auswirkt.
Edit: Dekoration: Ausschmückung rund um das Fenster Steuerelemente: Funktionen des Fensters
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 02. Jul 2015 um 15:42.
Auch wenn der Teil geklärt ist, verstehe ich deinen Einwand weiter oben trotzdem nicht:
Der Fenstermanager hat unter Wayland sogar noch viel mehr Kontrolle und Macht als unter X11. Unter X11 konnten Anwendungen Fenstermanager spielen, dies ist unter Wayland nicht mehr möglich. Eine Anwendung kann nicht sagen, dass sie jetzt ganz oben im Stack ist und dass sie jetzt sich Input nimmt.
Unter Wayland gibt es nach meinem Verständnis überhaupt keinen dedizierten Fenstermanager mehr. Einige Aufgaben des Fenstermanagers können wahlweise auch von den Clients übernommen werden (ich habe es in "einige Aufgaben" korrigiert um deinem berechtigten Einwand Rechnung zu tragen). So kann jede Applikation selbst ihre Fensterdeko malen und die dazugehörigen Funktionen zu den Steuerelementen bereitstellen. Unter X11 war dies zwar ebenfalls möglich, aber absolut unüblich.
Die Aufgaben des Fenstermanagers sind damit weiterhin beim Fenstermanager und nicht bei den Anwendungen.
Es ist wohl eher so, dass sich die Aufgaben des Fenstermanagers zwischen Client und Server aufteilen können.
Spätestens dann wird es spannend werden, wenn ein GNOME-Nutzer unter Wayland eine KDE-Applikation startet. GNOME erstellt die Fensterdekoration und dazugehörige Steuerelemente nicht im Compositor und die KDE-Applikation erstellt sie nicht clientseitig... Und schon wird jemand Teile des Fenstermanagers doppelt implementieren müssen (falls der User nicht im Regen verweilen soll).
Bitte reduziere die Aufgabe eines Fenstermanagers nicht auf Fensterdeko und Steuerelemente. Das ist z.B. in KWin doch nur ein sehr kleiner Bereich (5 kSLOC von insgesamt 120 kSLOC).
Bitte auch vertraue Leuten, die sich damit auskennen. Ich bin der Maintainer eines X11 Fenstermanager/Compositors und portiere den gerade nach Wayland. Ich habe gerade KWindowSystem API nach Wayland portiert und in den meisten Methoden nur ein debug Statement eingetragen wie "This plugin does not support minimizing windows". Wayland erlaubt praktisch keine Client seitige Fenstermanager features. Beispiel von Qt's Client side decorations: void QWaylandWlShellSurface::setMinimized() { // TODO: There's no wl_shell_surface API for this }
Ja genau, alle Steuerelemente können in Wayland im Client umgesetzt werden, ausser wenn es nicht geht.
Ich habe dein Argument bezüglich der Reduzierung der Aufgaben des Fenstermanagers auf Fensterdeko und Steuerelemente bereits eingeräumt, indem ich von "einigen Aufgaben des Fenstermanagers" gesprochen habe. Welchen Anteil Fensterdeko und Steuerelemente an einer Fenstermanager-Compositor-Combo haben kann aber doch nichts daran ändern, dass es sich um klassische Aufgaben des Fenstermanagers handelt.
Ich habe übrigens kein Problem dir in Sachen KWin zu vertrauen. Soweit ich informiert bin hast du ja auch nicht vor, besagte Aufgaben auf die Clients zu verlagern.
Und wie ich bereits in einem anderen Kommentar schrieb: auch unter X11 gibt es keine Aussagen dazu, ob der Fenstermanager die Fensterdekos kontrolliert. Sowohl X11 als auch Wayland machen dazu keine Angaben.
Ich verstehe daher nicht, dass du dies als eine klassische Aufgabe eines Fenstermanagers bezeichnest. Oder warum du Wayland dafür kritisierst, dass es wie X11 keine Angaben dazu macht (übrigens setze ich mich dafür ein unter Wayland klare Angaben dazu zu machen im Gegensatz zu X11).
Des weiteren muss ich einfach mal darauf hinweisen, dass die Tatsache ob die Fensterdeko im Client oder im Server erstellt wird zu einem großen Teil ein Implementierungsdetail ist. Zumindest in Qt wäre es ohne Problem möglich die gleiche Deko zu laden wie sie in KWin verwendet wird (die neue kdecoration API wurde mit dieser Zielsetzung designed). Dass es unter GTK Anwendungen heute Probleme gibt, sind design Entscheidungen des GNOME Teams und das hat nichts mit Wayland oder X11 zu tun.
Und wie ich bereits in einem anderen Kommentar schrieb: auch unter X11 gibt es keine Aussagen dazu, ob der Fenstermanager die Fensterdekos kontrolliert. Sowohl X11 als auch Wayland machen dazu keine Angaben.
Ich verstehe daher nicht, dass du dies als eine klassische Aufgabe eines Fenstermanagers bezeichnest.
Weil dies unter X seit gefühlten Ewigkeiten so üblich ist und umgesetzt wird. Bis auf Einzelapplikationen welche aus der Reihe tanzen mussten (wo dies aber auf Applikationsebene umstellbar war) habe zumindest ich in den letzten ~20 Jahren unter X nichts anderes kennen gelernt.
Oder warum du Wayland dafür kritisierst, dass es wie X11 keine Angaben dazu macht
Ich habe in erster Linie GNOME 3 kritisiert mit der seit jahrzehnten üblichen Konvention unter X zu brechen und dies auf die fehlenden Vorgaben unter Wayland zurückgeführt. Letzteres hat zwei Gründe, ich hatte zum Einen mehrfach gelesen, dass dieses GNOME-Verhalten den für Wayland durchgeführten Anpassungen geschuldet ist. Zum Zweiten kann ich mich noch an die Anfänge von Wayland erinnern wo eine zeitlang so getan wurde als wären clientseitige Fensterdekos erforderlich. Ich denke es warst sogar du, der dies richtiggestellt hat.
göööb hat hierzu noch einen interessanten Gesichtspunkt in die Diskussion eingebracht (bezüglich Menüs in die Fensterdeko verlagern), was nachvollziehbar erscheint. Immerhin liese sich damit erklären, weshalb man bei GNOME auf clientseitige Fensterdekos drängt. Die Parallelen sind aber immer noch nicht von der Hand zu weisen und mit Zufällen bin ich eher vorsichtig.
(übrigens setze ich mich dafür ein unter Wayland klare Angaben dazu zu machen im Gegensatz zu X11)
Das ist löblich, aber wenn ich mir ansehe was GNOME macht, dann habe ich für serverseitige Fensterdekos als Vorgabe leider derzeit keine große Hoffnung.
Also können wir deine Kritik darauf runterbrechen, dass Leute im GNOME Lager fälschlicherweise ihre CSDs mit Wayland begründet haben. Hat also alles nichts mit Wayland zu tun Gut, dass wir uns nun in dem Punkt einig sind.
Das ist löblich, aber wenn ich mir ansehe was GNOME macht, dann habe ich für serverseitige Fensterdekos als Vorgabe leider derzeit keine große Hoffnung.
Darum geht es mir auch nicht, sondern eher darum, dass Fenstermanager und Fenster sich miteinander austauschen und kommunizieren was der Wunsch des Fensters und des Fenstermanagers ist und man sich dann einigt. Auch dass der Fenstermanager für Fenster, die wirklich eigene Dekos machen wollen klare Vorgaben geben kann (wir haben einen Minimieren Knopf und den zeichnest du, auch wenn du in GNOME Shell den nicht zeichnest).
Ich kann deinen Einwand aus Entwicklersicht nachvollziehen. Für den Entwickler ist Wayland in erster Linie das Protokoll und dessen Library. Der Nutzer nimmt Wayland hingegen vielmehr als Projekt wahr.
Weston ist halt kein Compositor mit dem Fokus bei Usern zur Anwendung zu kommen, sondern dient vielmehr Demonstrationszwecken und Beispiel, wie sowas umzusetzen ist.
Dementsprechend würde es das Projekt aber nur völlig unnötig aufblähen, wenn man dann anfängt Features zu implementieren, die hier eigentlich nicht nötig sind.
Mal abgesehen davon, dass man Weston nicht so häufig in realer Verwendung finden wird, selbst die Smartphones, die Wayland einsetzen nutzen einen anderen Compositor, soweit mir bekannt.
Was Gnome da macht ist Gnome-Sache, hat aber nichts mit Wayland zu tun. Die Motivationen sind da andere, deshalb wäre das auch mit X11 so passiert, wenn es Wayland nicht geben würde.
Weston ist halt kein Compositor mit dem Fokus bei Usern zur Anwendung zu kommen, sondern dient vielmehr Demonstrationszwecken und Beispiel, wie sowas umzusetzen ist.
Klar, ich verwende zu "Demonstrationszwecken wie sowas umzusetzen ist" auch immer möglichst ungeeignete Beispiele
Dementsprechend würde es das Projekt aber nur völlig unnötig aufblähen, wenn man dann anfängt Features zu implementieren, die hier eigentlich nicht nötig sind.
Die Funktionen des Fenstermanagers mussten so und so implementiert werden, die einzige Frage war, ob server- oder clientseitig.
Was Gnome da macht ist Gnome-Sache, hat aber nichts mit Wayland zu tun. Die Motivationen sind da andere, deshalb wäre das auch mit X11 so passiert, wenn es Wayland nicht geben würde.
GNOME gibt es nicht erst seit gestern und so lange GNOME nur für X11 verfügbar war hat man immer auf einen Fenstermanager gesetzt. Erst mit der Wayland-Implementierung hat sich dies geändert.
Wayland führt zur Situation, dass manche Desktopumgebungen die Aufgaben des Fenstermanagers clientseitig implementieren und andere serverseitig. Das kann sich niemand ernsthaft wünschen.
Ich frage mich ja was wird wohl passieren, wenn ein GNOME-Nutzer unter Wayland eine KDE-Applikation startet? GNOME erstellt die Fensterdekoration und dazugehörige Steuerelemente nicht im Compositor und die KDE-Applikation erstellt sie nicht clientseitig...
Klar, ich verwende zu "Demonstrationszwecken wie sowas umzusetzen ist" auch immer möglichst ungeeignete Beispiele ;-)
Ob Beispiele geeignet oder ungeeignet sind hängt doch davon ab was man zeigen will. Qt liefert z.B. einen Browser mit, als Beispiel wie man einen Browser mit Qt auf Webkit (bzw. zukünftig Webengine) aufbauen kann. Würdest du dann auch meckern, dass er keine Tabs kann (was er übrigens kann)? Darauf aufbauend kann es aber durchaus Projekte geben, die den Funktionsumfang derart erweitern, dass es möglich ist. Aus dem Qt Demo Browser sind z.B. schon 2-3 Browser Projekte entstanden, eines davon (Qupzilla) ist sogar noch recht lebendig und recht gut benutzbar.
Bedenke, dass so ein Demo-Projekt nicht immer den Sinn haben muss denn man selbst darin gerne sehen würde.
Die Funktionen des Fenstermanagers mussten so und so implementiert werden, die einzige Frage war, ob server- oder clientseitig.
Nur, wenn man Weston soweit ausbauen will, dass es auf einem Desktop sinnvoll eingesetzt werden kann. Wenn das nicht der Fall ist, dann nicht. Im Endeffekt wird es wohl eine pragmatische Entscheidung gewesen sein, nach dem Motto: "Wir wollen da jetzt keine Zeit investieren, also machen wir das (jetzt) nicht." Ist aber auch nur eine Vermutung.
GNOME gibt es nicht erst seit gestern und so lange GNOME nur für X11 verfügbar war hat man immer auf einen Fenstermanager gesetzt. Erst mit der Wayland-Implementierung hat sich dies geändert.
Das ist im Prinzip richtig, trotzdem ist die Motivation eine andere, nämlich, dass man bei bei gnome gerne Einfluss auf die Fenster-Deko hätte, so wie das ja auch unter Windows inzwischen häufig genutzt wird (d.h. Menüs dorthin verlagern). Das ist mit dieser Implementation etwas leichter. Ich halte das also eher für eine zufällige Überschneidung, der wesentliche Anstoß zu dieser Änderung hat meiner Meinung nach unter Windows stattgefunden (evtl. auch OS X).
Wayland führt zur Situation, dass manche Desktopumgebungen die Aufgaben des Fenstermanagers clientseitig implementieren und andere serverseitig. Das kann sich niemand ernsthaft wünschen.
Keine Frage, ich finde das auch furchtbar und bei mir führt es dazu, dass ich um GTK3 Anwendungen einen großen Bogen mache und sehr froh bin, dass die meisten GTK Anwendungen, die ich nutze weder Teil von gnome sind noch auf GTK3 portiert wurden, sondern noch Version 2 nutzen. Bei manchen (GIMP, Darktable) ist leider der Port schon in Arbeit. :-/
Was macht Wayland besser als X11? Es ist neuer, aber was soll Wayland besser machen?
Mir ist das jetzt zu aufwändig selber was zu schreiben und hab deshalb mal "Why is Wayland better than X" in google eingegeben und z.B. das hier gefunden: http://www.phoronix.com/scan.php?page=article&item=x_wayland_situation&num=1
viel spass beim Lesen
Deine Meinung als Entwickler hätte ich gern. Nicht das was im Internet geschrieben steht
Entwickler denken oft anders
Der verlinkte Artikel wurde von Daniel Stone gegengelesen und mit Input versorgt. Dem kann man in diesen Fragen völlig vertrauen und seine Meinung ist da besser als meine.
Um so mehr, will ich eben deine Meinung dazu lesen
Ich weiß nicht wer Daniel Stone ist.
Daniel Stone ist einer der wenigen lebenden Menschen, die Teile von X verstehen und aktiv bei Wayland involviert. Er ist jemand, dessen Meinung ich voll unterstütze. Wenn du meine Meinung willst, dann kopiere ich einfach den Text und schreibe meinen Namen drunter.
Ich finde ja du solltest dich geheert fühlen wenn dir einige so sehr an den Lippen hängen das sie genau das erwarten.
Hier riechts nach Troll.
Dann geh dich mal duschen!
Xorg ist Software aus den 80ern. Gibt 2 Gründe, warum das für das ganze Open Source Ökosystem fatal ist:
1. Es müssen ständig Sachen gepatcht werden, nur um neue Funktionalität zu bringen. Das mag einige vielleicht nicht interessieren, aber es gibt Sachen, die wir auf Xorg nur sehr schwer machen können, die aber auf dem Stand von 2003 sind. Compositing, gescheiter Vsync in Videos, banale Sachen wie, dass das System eben nicht 10x das Bild scannt, nur um zu sehen, ob Xorg richtig geraten hat, wo ich das Video oder das Bild hinhaben will. Das sind alles Sachen, die Wayland kann, man es Xorg aber umständlich beibringen muss, weil es wie ein verwirrter Höhlenmensch ist, den man mit einer Zeitkapsel in unsere Zeit geholt hat und nun lehren will, wie er als moderner Mensch leben soll.
Aber lassen wir mal einen ex-Xorg Dev und jetzigen Wayland Dev zu Wort kommen, der hat das viel besser und einfacher erklärt als ich (dauert allerdings ne drei Viertel Stunde):
https://www.youtube.com/watch?v=RIctzAQOe44
2. Sicherheit
Lest euch den anderen Blog Beitrag von Martin Grässlin durch, wo er darauf eingeht, warum ein sicherer Lock Screen in X nicht möglich ist:
http://blog.martin-graesslin.com/blog/2015/01/why-screen-lockers-on-x11-cannot-be-secure/
3. Kommt mir bitte nicht mit Netzwerk-Transparenz! Die wird in die Widgets ausgelagert werden. Zumindest wird das bei QT5 und GTK3 der Fall sein. Wenn andere Widgets da nicht mitziehen aus irgendwelchem konservativen "Früher war alles besser" Getue, dann sei's drum! Und wirklich? Ihr habt noch Admin Tools die in Motif oder GTK1 geschrieben sind? Pech gehabt! Benutzt Konsoletools oder schreibt sie mal eben in QT5 um -- bin sicher, dass das viel einfacher ist, als damals, als ihr es für Motif geschrieben habt.
Wenn ich solche Diskussionen oder Monologe lese, dann fällt mir imemr auf, dass Wayland-Befürworter größtenteils nur die Nachteile von Xorg im Vergleich zu Wayland darstellen.
Warum schreibt man denn einfach nicht darüber, welche Vorteile Wayland gegenüber Xorg besitzt und was darin an Neuem existiert, was in Xorg noch gar nicht vorhanden ist?
Aus Deinem Punkt 1. kann ich nicht wirklich herauslesen, was die genauen (vielleicjt auch entscheidenden) Vorteile von Wayland gegenüber Xorg sind. Wayland macht anscheinend irgendetwas besser als Xorg, nur was genau? Compositing z.B. gibt es auch im Xorg-Bereich.
Punkt 2. ist sicher nicht unwichtig, falls Wayland das hinbekommt und Xorg nicht, dann ist es in diesem einem Punkt etwas besser als Xorg. Der Hauptvorteil von Wayland gegegnüber Xorg kann das aber auch nicht wirklich sein.
Punkt 3. zeigt, dass Wayland etwas nicht vermag, was Xorg nun kann und das ist IMO deshalb kein Vorteil für Wayland. Wayland ist jetzt ja wohl nicht deshalb der große Wurf, weil es die Xorg-Netzwerktransparenz nicht mehr besitzt. Die Xorg-Netzwerktransparenz ist geradezu genial, auch wenn man diese heute gerade als Nutzer gar nicht mehr benötigt.
Argumentativ hängt das Ganze meiner Meinung nach etwas schief. Wayland ist bestimmt nicht charakterisierbar als Xorg minus Xorg-Features, die man heute als antiquiert ansieht.
Um da mal ein Beispiel zu nennen: in Wayland sind alle status Änderungen zu einer "Surface" (sowas wie ein Fenster) double buffered und werden erst aktiv wenn der Client sagt "jo ist jetzt alles gesetzt, Status ist konsistent".
Unter X11 gibt es so was nicht. Status Änderungen werden direkt umgesetzt. Also z.B. Fenstermanger setzt eine neue Fenstergröße auf ein Fenster. Alles in X11 meint dann, dass dies die neue Fenstergröße ist, aber das Fenster hat dann noch nichts davon gehört, geschweige denn neu gezeichnet. Nun gibt es komplizierte sync Protokolle um das weg zu kaschieren, aber es bleibt: X11 meldet bei einem resize falsche Fenstergrößen. Es ist nicht ein "hey Fenster geh mal bitte auf diese Größe und sag mir wenn du damit fertig bist", sonder ein "das ist jetzt die Größe".
Solche konzeptionellen Fehler gibt es viele in X11. Diese zu behben braucht ein neues Protokoll. Könnte man X12 nennen oder halt Wayland.
"Wenn ich solche Diskussionen oder Monologe lese, dann fällt mir imemr auf, dass Wayland-Befürworter größtenteils nur die Nachteile von Xorg im Vergleich zu Wayland darstellen."
Ja, und die Nachteile überwiegen doch in den meisten Fällen. Außer der mythischen Netzwerktransparenz und dem Totschlagargument "Es ist nicht fertig" habe ich keine guten Argumente gehört. Die Netzwerktransparenz ist noch nicht da, aber sie wird eh Sache der Widgets werden. Du siehst also, dass ich durchaus auch diskutiere und keine Monologe führe
"Warum schreibt man denn einfach nicht darüber, welche Vorteile Wayland gegenüber Xorg besitzt und was darin an Neuem existiert, was in Xorg noch gar nicht vorhanden ist?"
Habe ich doch schon: besserer Vsync, kein Videofenster, dass 3 Sekunden länger braucht, um mit dem Browser in den es eingebettet ist hinterherzukommen, keine Fenster, die raten müssen, wo X was hinknallt und das dann mit mehr Resourcen kompensieren müssen. Übrigens alles Sachen, die im Video erklärt sind. Würde es dir sehr empfehlen, weil es dort eben kein Laie wie ich erklärt, sondern ein ehemaliger X Entwickler/heutiger Wayland Entw.
"Aus Deinem Punkt 1. kann ich nicht wirklich herauslesen, was die genauen (vielleicjt auch entscheidenden) Vorteile von Wayland gegenüber Xorg sind. Wayland macht anscheinend irgendetwas besser als Xorg, nur was genau? Compositing z.B. gibt es auch im Xorg-Bereich."
Ja, Compositing gibt es, aber wie schon vorher gesagt, wird es sehr schlecht gemacht. Der Videolink erklärt es ganz gut.
"Punkt 2. ist sicher nicht unwichtig, falls Wayland das hinbekommt und Xorg nicht, dann ist es in diesem einem Punkt etwas besser als Xorg. Der Hauptvorteil von Wayland gegegnüber Xorg kann das aber auch nicht wirklich sein."
Wie, die Tatsache, dass jeder halbwegs gute Programmierer mit sehr wenig Mühe jede Lock Screen Implementation knacken kann ist kein guter Grund gegen Xorg? Wow!
Es war allerdings auch nur 1 Beispiel davon, wieviele Löcher der schweizer Käse namens Xorg hat. Siehe auch diese Meldung, wo sich rausstellt, dass der Code mittlerweile so komplex ist, dass Leute extra dieses Monster auditen und dann 23 Jahre alte Sicherheitsklücken finden:
http://www.phoronix.com/scan.php?page=news_item&px=MTU1NzA
"Punkt 3. zeigt, dass Wayland etwas nicht vermag, was Xorg nun kann und das ist IMO deshalb kein Vorteil für Wayland. Wayland ist jetzt ja wohl nicht deshalb der große Wurf, weil es die Xorg-Netzwerktransparenz nicht mehr besitzt. Die Xorg-Netzwerktransparenz ist geradezu genial, auch wenn man diese heute gerade als Nutzer gar nicht mehr benötigt."
Warum ist sie genial und warum ist es schlecht, wenn das in die Widgets ausgelagert wird?
Aber in der Linuxwelt scheint alles, was an Code Ü30 ist, den selben Stellenwert zu haben wie der alte, vermeintlich weise Greis in der Sippschaft, der sich so jedweder Kritik immer entzieht.
"Argumentativ hängt das Ganze meiner Meinung nach etwas schief.
Warum?
"Wayland ist bestimmt nicht charakterisierbar als Xorg minus Xorg-Features, die man heute als antiquiert ansieht."
Gerade das will es ja sein. Es ist bei weitem noch nicht so weit, wie wir es gern hätten, das stimmt, aber es hat schon sehr viel geschafft.
https://youtu.be/RIctzAQOe44?t=1071
Falls du es (aus welchem Grund) nicht anschauen willst. Was er dort sagt ist:
X ist nicht mehr netzwerk-transparent, da praktisch ausschließlich SHM und DRI2 verwendet werden, welche nicht netzwerk-transparent sind. Es ist netzwerk-fähig.
Und in dem von Martin verlinkten Artikel wird das auch noch klassifiziert, dass es wie eine schlecht implementierte Version von VNC funktioniert.
Mit anderen Worten: Dieses Netzwerktransparenzargument (was ein Wort ;)) gibt es nicht mehr.
Das Problem liegt bei X doch tiefer, nicht beschränkt auf Bildschirmsperren - jede Anwendung kann die Eingaben jeder anderen Anwendung abgreifen (zumindest manches davon scheint Wayland besser zu machen; eine weitergehende Lösung bietet Qubes):
http://theinvisiblethings.blogspot.de/2011/04/linux-security-circus-on-gui-isolation.html
Vorteile aus meiner Sicht:
- X11 als Abstraktionsschicht hat über 20 Jahre Altlasten, was zu sehr vielen Schwierigkeiten in der Wartung (sowohl von X.org als auch Anwendungen die dessen diverse APIs benutzen) führt und langfristig Arbeitskräfte/Arbeitszeit an sich bindet, die woanders sinnvoller eingesetzt wären. Da Wayland von 0 anfing aber aus den Erfahrungen von X und anderen Plattformen gelernt hat, ist Wayland im Vergleich eine extrem dünne, leichte Abstraktionsschicht, die aber dennoch wahrscheinlich sogar besser die Anforderungen moderner Desktops/(oder jeder andere Formfaktor) erfüllt, da mehr Flexibilität eingebaut ist und die GUI-Toolkits sozusagen bei vielen Dingen "freie Hand" bekommen, die vorher unheimlich komplixiert über X liefen oder gar nicht erst ohne Workaround gingen.
- Wayland wurde von den teilweise wichtigsten X.org Entwicklern initiiert, es ist also nicht so dass eine Gruppe die andere übertrumpfen wollte, die X-Entwickler selber (z.B. Keith Packard) wussten halt am besten, dass die Modernisierung von X aufgrund der Altlasten ein Auslaufmodell ist.
- X läuft zwar bei mir auch wirklich stabil, dass ich als User auch nicht meckern kann, aber als Entwickler hab ich z.B. schon öfter Probleme gehabt meine Ideen umzusetzen wegen den begrenzten Möglichkeiten einer GUI unter X. Bin bestimmt nicht der einzige der sich deswegen mit Features "zurückhalten" musste, weil es einfach keinen Sinn machte 6 Monate an einem Workaround zu arbeiten, das auf einer besseren Platform in einer Stunde möglich wäre.
- Wenn man eine Wayland-Session startet egal ob nestet unter X oder direkt, und selbst nur ein Terminal drauf bedient, merkt man wenn man für sowas empfindlich ist definitiv, dass die Reaktionszeiten besser sind (weniger Roundtrips, leichtere Platform/Bibliotheken/Infrastrutur). Das muss einen jetzt nicht umwerfen und dazu bringen X zu hassen und auf Wayland sehnsüchtig zu warten, aber es zeigt halt, dass Wayland den Weg Richtung Zukunft weist, während X selbst nach 20 Jahren Optimierung letztenendes sich selbst im Weg steht.
Das sind die Punkte interessanten Punkte aus meiner Sicht.
Suche übrigens einen Job im Linux-Open-Source-Bereich, oder der damit zu tun hat, wenn jemand denkt er hat was für mich, könnte er mir vielleicht nen Hinweis hinterlassen.
Gruß
Vorneweg, Wayland wird hier als Synonym verwendet.
Kannst dabei auch die Vorteile von X aufzählen:
- X funktioniert. Stabil, nicht nur auf Linux, erprobt, alle gängigen Bibliotheken können damit umgehen. Wird noch Jahre dauern damit Wayland da gleichzieht.
- Wayland wurde von keinen X-Entwickler initiert. Diese sind wie Programmierer nun mal sind, zu den neuen Fancy-Stuff gewechselt. Bei X ist die Entwicklung sehr langsam und konservativ.
- X wird von einen unabhängigen Organisation entwickelt. Wayland hingegen stark linuxzentriert.
- Wayland ist nicht erwachsen, bis heute wird am Unterbau rumgeschraubt.
Frag doch mal den Martin, seine Bude sucht doch immer fähiges Personal.
Kristian Høgsberg hat an X mitgearbeitet, z.B. AIGLX. Evtl. war er nicht einer der Hauptentwickler, aber wen interessiert das schon. Wichtig ist, dass viele die früher an X mitgearbeitet haben und vor allem X so halbwegs verstehen von Wayland überzeugt sind und das Konzept mittragen.
Wie kommst du darauf? Wayland selbst hat keine Plattformabhängigkeit. Beim Compositor sieht es schon anders aus, aber da wird es auch welche für BSD geben.Prinzipiell sollten es sogar leichter sein Wayland-Clients auf Windows zu portieren als das mit X der Fall ist.Ja, aber wie in dem von Link versionisiert. Wenn Programm X nur libwayland-1.0 unterstützt, dann bekommt es auch genau das.
Das einzige Argument, dass hier Sinn macht ist: Wayland ist unfertig. Alles andere ist deine Meinung. Ich kann dir zig Dinge nennen, warum Xorg nicht stabil für mich ist: Ständige Vsync Regressionen, Speicherleck hier und da, kein Alt-Tab möglich zwischen z.B. Videospiel und Desktop, und und und...
"Bei X ist die Entwicklung sehr langsam und konservativ."
Da gebe ich dir Recht, deshalb hat sich da seit 30 Jahren nichts gescheites getan.
Um nochmal auf dein einzig nutzbares Argument zurückzugehen: Wayland ist nicht fertig, nein. Aber X11 wird auch nicht einfach so von heute auf morgen abgelöst werden.
Es wird an Wayland rumgeschruabt, aber es kriegt in weniger Entwicklungszeit mehr hin, als Xorg in 30 Jahren.
Wayland als Protokoll und als Bibliothek ist fertig. Was nicht fertig sind, sind die Portierungen der Desktop Umgebungen.
Ich nutze schon seit einiger Zeit ein Smartphone welches Wayland als Fenstersystem einsetzt. Das sollte eigentlich Beweis genug sein, dass Wayland fertig ist.
Die Anforderungen für verschiedene Geräte können unterschiedlich sein. Das merkt ja auch das Plasma Team immer wieder, wenn es um Tablets und Smartphones geht.
Es gibt ja durchaus noch offene Fragen bei Wayland und deshalb auch neue Releases, aber die Grundlagen sind gelegt und die Portierung der Desktop Umgebungen ist tatsächlich momentan das größte Hindernis, da hast du auf jeden Fall recht.
Nach der Logik ist aber X11 auch noch nicht fertig. Schließlich gibt noch offene Fragen (z.B. Present Extension) und deshalb auch noch neue Releases.
Kann man so sehen, ja.
Red Hat sucht:
https://blogs.gnome.org/uraeus/2015/01/21/want-to-join-our-innovative-development-team-doing-cool-open-source-software/
Man bedenke auch dass das X Window System 31 Jahre alt ist (wenn ich korrekt gerechnet habe). Für eine Software ist das ein Imenses Alter. Obwohl ich (sebstverständlich) davo ausgehe, dass sich alle Entwicker Mühe geben - da schleppt man einfach irgendwann Altlasten mit. Erst recht bei einem derart grossen Projekt. Das ist ein bisschen Mehr Code als bei einem Java Taschenrechner
Jeder der Programiert weis, das bei jedem Projekt irgendwann der Punkt kommt, and dem man am besten neu anfängt. Ganz einfach weil die Technologie nichtmehr dieselbe ist wie for 30 Jahren, und das ewige herumgepatche irgendeinmal nur noch einen riesen Flickentepich. Also: Einstapfen -> Neu anfangen.
https://www.youtube.com/watch?v=RIctzAQOe44
Viel Spaß beim Schauen.
Im Endeffekt wird man als User erstmal nicht wirklich viel davon haben, aber das muss ja auch gar nicht der Fall sein. Langfristig wird es sich sicherlich bemerkbar machen.
ja wollte auch gerade den link posten, 18:30min is funny, Was mich an X stoert ist das beim bildschirmschoner es nicht moeglich ist die Lautstaerke zu aendern! (erklaerung auch im video)
https://www.youtube.com/watch?v=GtXQJ0c5q0k
Auf meinem Jolla läuft auch Wayland.
Ich wäre schon froh, wenn ich von den Nachteilen von Wayland verschont bliebe. Und da bin ich womöglich nicht der Einzige.
Ich muss mich mit den Nachteilen herumschlagen und dabei benutzte ich Wayland noch nicht einmal. So sind GNOME 3-Anwendungen außerhalb deren Desktopumgebung leider zur Zumutung geworden, da man wegen Wayland auf einen Fenstermanager verzichtet - auch unter X11. Jede GNOME 3-Anwendung ist nun selbst für ihr Fenster und dessen Steuerelemente verantwortlich.
Endlich lassen sich ausgelastete Applikationen - so wie unter Microsoft Windows gewohnt - nicht mehr in der Größe ändern, maximieren, verschieben, beenden usw. Auf diesen Rückschritt hätte ich gut und gerne auch die nächsten 30 Jahre verzichten können.
Zudem verlieren Monitore seit Jahren immer weiter an Höhe (4:3 -> 16:10 -> 16:9), wer da auf die Idee kommt die Titelleiste der Fenster nun doppelt so hoch zu zeichnen...
Wayland mutiert indirekt bereits zur Usability-Katastrophe bevor man es überhaupt einsetzt. Das ist traurig. Die Usability des Desktops hat sich in den letzten Jahren ohnehin kaum weiterentwickelt. Sicher, überall gibt es nette Effekte und alles sieht toll aus, das Eye Candy ist super aber das hat nichts mit Usability zu tun. Es gibt kaum Stellen an denen ein moderner Desktop tatsächlich die Produktivität steigert. Wir können es uns überhaupt nicht leisten, Usability über Bord zu werfen.
Das an all diesen "Nachteilen" Walyland schuld sein soll bezweifle ich dann doch sehr...
Das Konzept auf den Fenstermanager zu verzichten stammt nunmal aus der Wayland-Ecke.
Würde man auf den Fenstermanager verzichten können, würde es nicht so großen Aufwand bedeuten, KWin zu portieren, oder?
Der einzige Unterschied ist, dass sich Primär- und Sekundärbzeichnung verschoben haben.
Bei X11 hatten Fenstermanager, wie z.B. KWin, auch die Aufgabe des Compositor übernommen.
Bei Wayland übernehmen Compositor, z.B. KWin, auch die Aufgabe des Fenstermanager.
D.h. Fenstermanager mit eingebautem Compositor erfüllen weiter beide Aufgaben, nur Fenstermanager ohne Compositor wird vermutlich nicht mehr geben.
Die Aufgaben des Fenstermanagers können unter Wayland clientseitig oder serverseitig umgesetzt werden. Der Compositor muss diese Aufgabe nicht übernehmen und tut es im Falle von Weston (Wayland-Referenzimplementierung) und GNOME 3 auch nicht. Es wird erwartet, dass diese Aufgaben die Anwendung selbst übernimmt, im Falle von GNOME 3 gilt diese Änderung selbst unter X11.
Du liegst etwas falsch. Der Fenstermanager hat unter Wayland sogar noch viel mehr Kontrolle und Macht als unter X11. Unter X11 konnten Anwendungen Fenstermanager spielen, dies ist unter Wayland nicht mehr möglich. Eine Anwendung kann nicht sagen, dass sie jetzt ganz oben im Stack ist und dass sie jetzt sich Input nimmt.
Die Aufgaben des Fenstermanagers sind damit weiterhin beim Fenstermanager und nicht bei den Anwendungen.
Du scheinst mir den Fenstermanager auf Fensterdekos zu reduzieren. Hierzu kleiner Hinweis: X11 und Wayland haben genau die gleichen Vorgaben zu dem Thema: keine!
Nein, ich meine nicht nur die Fensterdeko. Ich meine in der Hauptsache die Steuerelemente des Fensters welche dem Fenster zur eigentlichen Funktion verhelfen. Die Deko erfüllt üblicherweise keinen Selbstzweck sondern ist in erster Linie dazu da, die Steuerelemente des Fensters einzubetten.
Beides sind klassische Aufgaben des Fenstermanagers und auch wenn X11 keine Vorgaben macht so ist es seit gefühlten Ewigkeiten üblich, diese Aufgaben durch einen Fenstermanager umzusetzen.
Möglicherweise müssen alle Protagonisten erstmal wieder alle Möglichkeiten durchspielen, bis sich der Status quo erneut einstellt. Möglicherweise war dies bei X genauso, nur ist dies glücklicherweise schon 30 Jahre her. Dem Desktop wird dies IMHO kurz- und mittelfristig kaum nützen.
Wenn Martin "Fensterdekos" schreibt, dann meint er sicher inklusive der dort untergebrachten Steuerelemente.
Wayland erfordert nicht, dass Fensterdekos von den Anwendungen erstellt werden müssen. Dies ist eine Design Entscheidung von GNOME. Dafür ist einzig GNOME verantwortlich, bitte mach dafür Wayland nicht verantwortlich.
Das Verhalten entspricht der Referenzimplementierung von Wayland, ich habe mir deshalb erlaubt auch Wayland dafür indirekt verantwortlich zu machen.
Bei KWin geht ihr glücklicherweise einen anderen Weg und es ist gut, dass du dich zu Wort gemeldet hast.
Nicht die Referenzimplementierung von Wayland, sondern die Referenzimplementierung für einen Wayland compositor. Ein kleiner aber in diesem Fall feiner Unterschied.
Ich kann deinen Einwand aus Entwicklersicht nachvollziehen. Für den Entwickler ist Wayland in erster Linie das Protokoll und dessen Library. Der Nutzer nimmt Wayland hingegen vielmehr als Projekt wahr.
Jetzt gibt es noch nicht so viele Implementierungen des Wayland-Compositors, aber gibt es neben KWin überhaupt noch einen, der die üblichen Fenstermanager-Aufgaben serverseitig implementiert?
Führt es nicht ins Chaos und zur weiteren Abspaltung der unterschiedlichen Desktopumgebungen, wenn es jeder zweite Compositor anders implementiert?
Dieser Beitrag wurde 2 mal editiert. Zuletzt am 01. Jul 2015 um 17:48.Ich würde davon ausgehen, dass der Compositor immer auch der Fenstermanager ist, weil er der einzige Prozess im Gesamtaufbau ist, der alle Fenster kennt, alle Benutzereingaben bekommt, usw.
Martin kann das sicher genauer ausführen, aber nur der Compositor entscheidet, ob, wo und wie er ein Fenster anzeigt.
Die Anwendungen können, wie bei einem X11 Fenstermanager, maximal um bestimmte Positionierung bitten.
Bei Weston, der Wayland-Referenzimplementierung (des Compositors), sowie bei GNOME 3 werden die Aufgaben des Fenstermanagers vom Client, also von der jeweiligen Anwendung umgesetzt. Bei GNOME 3 erfolgte diese Änderung wegen der Wayland-Integration selbst unter X11.
Sämtliche GNOME 3-Fenster verhalten sich deshalb als Fremdkörper, wenn diese nicht unter der GNOME 3-Desktopumgebung genutzt werden.
Die grundsätzlichen, funktionalen Nachteile, wenn die Anwendung Fenstermanager-Aufgaben übernimmt, hatte ich bereits genannt.
Bei KWin sollen Fenstermanager-Aufgaben hingegen serverseitig erfolgen, als Teil des Compositors. Das dürfte mit dem unter X11 üblichem Verhalten vergleichbar sein (aus Nutzersicht).
Es ist unter Wayland keineswegs selbstverständlich, dass sich der Fenstermanager im Compositor befindet. Es gib bereits zwei Implementierungen, darunter die Referenzimplementierung des Wayland-Projektes welches es anders machen und im Falle von GNOME 3 hat dies selbst Auswirkungen auf X11-Nutzer.
Wie Martin schon weiter oben geklärt hat, hat eine Wayland Anwendung noch weniger direkte Kontrolle über ihre Fenster als eine X11 Anwendung.
Ohne Zustimmung des Compositors geht da praktisch nichts.
Was du meinst sind Fensterdekorationen, aber auch das hat Martin adressiert.
Was ich meine habe ich in meinem ersten Beitrag dargelegt. Ich habe dort u. a. den Fensterdekorationen einen Seitenhieb verpasst. Ebenso habe ich auf die Steuerelemente des Fensters Bezug genommen.
In deinem ersten Beitrag bist du fälschlicherweise davon ausgegangen, dass man bei Wayland auf einen Fenstermanager verzichtet: "...da man wegen Wayland auf einen Fenstermanager verzichtet..."
Das ist, wie Martin unter anderem dann genauer erklärt hat, nicht der Fall.
Unter Wayland sogar noch weniger als unter X11.
Der klassische Fenstermanager ist unter X11 ein eigenständiges Programm. Wayland kennt das Konzept eines eigenständigen Fenstermanagers hingegen nicht. Darauf bezog sich meine Aussage.
Die Aufgaben des Fenstermanagers fallen natürlich weiterhin an und müssen umgesetzt werden. Ich habe deshalb in den Folgebeiträgen versucht von den Aufgaben des Fenstermanagers zu sprechen (versucht, aber leider nicht konsistent durchgehalten).
Theoretisch ja, aber Fenstermanager und Compositor sind jetzt, unter X11, bereits meistens eine Einheit.
Und diese Kombination ist auch unter Wayland ein eigenständiges Programm.
Du hast mich irgendwo abgehängt. Was ist denn für dich der Unterschied zwischen "Fensterdekorationen" und "Steuerelemente des Fensters"? Für mich ist das das gleiche!
Ist sicher eine Definitionsfrage, unter einer Dekoration verstehe ich die Ausschmückung rund um das Fenster, also eine passive Komponente. Der Hinweis mit der doppelt so hohen Titelleiste bezog sich auf die Dekoration.
Die Steuerelemente sind hingegen die aktiven Komponenten. Da gehören die Buttons wie minimieren, maximieren, schließen dazu aber auch beispielsweise das Verschieben des Fensters über die Titelleiste. Alles was eine Funktion ingangsetzt, welche sich auf das Fenster auswirkt.
Edit:
Dieser Beitrag wurde 1 mal editiert. Zuletzt am 02. Jul 2015 um 15:42.Dekoration: Ausschmückung rund um das Fenster
Steuerelemente: Funktionen des Fensters
OK, das ist für mich beides die Fensterdeko.
Auch wenn der Teil geklärt ist, verstehe ich deinen Einwand weiter oben trotzdem nicht:
Unter Wayland gibt es nach meinem Verständnis überhaupt keinen dedizierten Fenstermanager mehr. Einige Aufgaben des Fenstermanagers können wahlweise auch von den Clients übernommen werden (ich habe es in "einige Aufgaben" korrigiert um deinem berechtigten Einwand Rechnung zu tragen). So kann jede Applikation selbst ihre Fensterdeko malen und die dazugehörigen Funktionen zu den Steuerelementen bereitstellen. Unter X11 war dies zwar ebenfalls möglich, aber absolut unüblich.
Es ist wohl eher so, dass sich die Aufgaben des Fenstermanagers zwischen Client und Server aufteilen können.
Spätestens dann wird es spannend werden, wenn ein GNOME-Nutzer unter Wayland eine KDE-Applikation startet. GNOME erstellt die Fensterdekoration und dazugehörige Steuerelemente nicht im Compositor und die KDE-Applikation erstellt sie nicht clientseitig...
Und schon wird jemand Teile des Fenstermanagers doppelt implementieren müssen (falls der User nicht im Regen verweilen soll).
Bitte reduziere die Aufgabe eines Fenstermanagers nicht auf Fensterdeko und Steuerelemente. Das ist z.B. in KWin doch nur ein sehr kleiner Bereich (5 kSLOC von insgesamt 120 kSLOC).
Bitte auch vertraue Leuten, die sich damit auskennen. Ich bin der Maintainer eines X11 Fenstermanager/Compositors und portiere den gerade nach Wayland. Ich habe gerade KWindowSystem API nach Wayland portiert und in den meisten Methoden nur ein debug Statement eingetragen wie "This plugin does not support minimizing windows". Wayland erlaubt praktisch keine Client seitige Fenstermanager features. Beispiel von Qt's Client side decorations:
void QWaylandWlShellSurface::setMinimized()
{
// TODO: There's no wl_shell_surface API for this
}
Ja genau, alle Steuerelemente können in Wayland im Client umgesetzt werden, ausser wenn es nicht geht.
Ich habe dein Argument bezüglich der Reduzierung der Aufgaben des Fenstermanagers auf Fensterdeko und Steuerelemente bereits eingeräumt, indem ich von "einigen Aufgaben des Fenstermanagers" gesprochen habe. Welchen Anteil Fensterdeko und Steuerelemente an einer Fenstermanager-Compositor-Combo haben kann aber doch nichts daran ändern, dass es sich um klassische Aufgaben des Fenstermanagers handelt.
Ich habe übrigens kein Problem dir in Sachen KWin zu vertrauen. Soweit ich informiert bin hast du ja auch nicht vor, besagte Aufgaben auf die Clients zu verlagern.
Und wie ich bereits in einem anderen Kommentar schrieb: auch unter X11 gibt es keine Aussagen dazu, ob der Fenstermanager die Fensterdekos kontrolliert. Sowohl X11 als auch Wayland machen dazu keine Angaben.
Ich verstehe daher nicht, dass du dies als eine klassische Aufgabe eines Fenstermanagers bezeichnest. Oder warum du Wayland dafür kritisierst, dass es wie X11 keine Angaben dazu macht (übrigens setze ich mich dafür ein unter Wayland klare Angaben dazu zu machen im Gegensatz zu X11).
Des weiteren muss ich einfach mal darauf hinweisen, dass die Tatsache ob die Fensterdeko im Client oder im Server erstellt wird zu einem großen Teil ein Implementierungsdetail ist. Zumindest in Qt wäre es ohne Problem möglich die gleiche Deko zu laden wie sie in KWin verwendet wird (die neue kdecoration API wurde mit dieser Zielsetzung designed). Dass es unter GTK Anwendungen heute Probleme gibt, sind design Entscheidungen des GNOME Teams und das hat nichts mit Wayland oder X11 zu tun.
Weil dies unter X seit gefühlten Ewigkeiten so üblich ist und umgesetzt wird. Bis auf Einzelapplikationen welche aus der Reihe tanzen mussten (wo dies aber auf Applikationsebene umstellbar war) habe zumindest ich in den letzten ~20 Jahren unter X nichts anderes kennen gelernt.
Ich habe in erster Linie GNOME 3 kritisiert mit der seit jahrzehnten üblichen Konvention unter X zu brechen und dies auf die fehlenden Vorgaben unter Wayland zurückgeführt. Letzteres hat zwei Gründe, ich hatte zum Einen mehrfach gelesen, dass dieses GNOME-Verhalten den für Wayland durchgeführten Anpassungen geschuldet ist. Zum Zweiten kann ich mich noch an die Anfänge von Wayland erinnern wo eine zeitlang so getan wurde als wären clientseitige Fensterdekos erforderlich. Ich denke es warst sogar du, der dies richtiggestellt hat.
göööb hat hierzu noch einen interessanten Gesichtspunkt in die Diskussion eingebracht (bezüglich Menüs in die Fensterdeko verlagern), was nachvollziehbar erscheint. Immerhin liese sich damit erklären, weshalb man bei GNOME auf clientseitige Fensterdekos drängt. Die Parallelen sind aber immer noch nicht von der Hand zu weisen und mit Zufällen bin ich eher vorsichtig.
Das ist löblich, aber wenn ich mir ansehe was GNOME macht, dann habe ich für serverseitige Fensterdekos als Vorgabe leider derzeit keine große Hoffnung.
Also können wir deine Kritik darauf runterbrechen, dass Leute im GNOME Lager fälschlicherweise ihre CSDs mit Wayland begründet haben. Hat also alles nichts mit Wayland zu tun
Gut, dass wir uns nun in dem Punkt einig sind.
Darum geht es mir auch nicht, sondern eher darum, dass Fenstermanager und Fenster sich miteinander austauschen und kommunizieren was der Wunsch des Fensters und des Fenstermanagers ist und man sich dann einigt. Auch dass der Fenstermanager für Fenster, die wirklich eigene Dekos machen wollen klare Vorgaben geben kann (wir haben einen Minimieren Knopf und den zeichnest du, auch wenn du in GNOME Shell den nicht zeichnest).
Dementsprechend würde es das Projekt aber nur völlig unnötig aufblähen, wenn man dann anfängt Features zu implementieren, die hier eigentlich nicht nötig sind.
Mal abgesehen davon, dass man Weston nicht so häufig in realer Verwendung finden wird, selbst die Smartphones, die Wayland einsetzen nutzen einen anderen Compositor, soweit mir bekannt.
Was Gnome da macht ist Gnome-Sache, hat aber nichts mit Wayland zu tun. Die Motivationen sind da andere, deshalb wäre das auch mit X11 so passiert, wenn es Wayland nicht geben würde.
Klar, ich verwende zu "Demonstrationszwecken wie sowas umzusetzen ist" auch immer möglichst ungeeignete Beispiele
Die Funktionen des Fenstermanagers mussten so und so implementiert werden, die einzige Frage war, ob server- oder clientseitig.
GNOME gibt es nicht erst seit gestern und so lange GNOME nur für X11 verfügbar war hat man immer auf einen Fenstermanager gesetzt. Erst mit der Wayland-Implementierung hat sich dies geändert.
Wayland führt zur Situation, dass manche Desktopumgebungen die Aufgaben des Fenstermanagers clientseitig implementieren und andere serverseitig. Das kann sich niemand ernsthaft wünschen.
Ich frage mich ja was wird wohl passieren, wenn ein GNOME-Nutzer unter Wayland eine KDE-Applikation startet? GNOME erstellt die Fensterdekoration und dazugehörige Steuerelemente nicht im Compositor und die KDE-Applikation erstellt sie nicht clientseitig...
Darauf aufbauend kann es aber durchaus Projekte geben, die den Funktionsumfang derart erweitern, dass es möglich ist. Aus dem Qt Demo Browser sind z.B. schon 2-3 Browser Projekte entstanden, eines davon (Qupzilla) ist sogar noch recht lebendig und recht gut benutzbar.
Bedenke, dass so ein Demo-Projekt nicht immer den Sinn haben muss denn man selbst darin gerne sehen würde.
Nur, wenn man Weston soweit ausbauen will, dass es auf einem Desktop sinnvoll eingesetzt werden kann. Wenn das nicht der Fall ist, dann nicht.Im Endeffekt wird es wohl eine pragmatische Entscheidung gewesen sein, nach dem Motto: "Wir wollen da jetzt keine Zeit investieren, also machen wir das (jetzt) nicht."
Ist aber auch nur eine Vermutung.Das ist im Prinzip richtig, trotzdem ist die Motivation eine andere, nämlich, dass man bei bei gnome gerne Einfluss auf die Fenster-Deko hätte, so wie das ja auch unter Windows inzwischen häufig genutzt wird (d.h. Menüs dorthin verlagern). Das ist mit dieser Implementation etwas leichter. Ich halte das also eher für eine zufällige Überschneidung, der wesentliche Anstoß zu dieser Änderung hat meiner Meinung nach unter Windows stattgefunden (evtl. auch OS X).Keine Frage, ich finde das auch furchtbar und bei mir führt es dazu, dass ich um GTK3 Anwendungen einen großen Bogen mache und sehr froh bin, dass die meisten GTK Anwendungen, die ich nutze weder Teil von gnome sind noch auf GTK3 portiert wurden, sondern noch Version 2 nutzen. Bei manchen (GIMP, Darktable) ist leider der Port schon in Arbeit. :-/