Wayland - wie geht es weiter?

[NAB]

Frage: wenn er nötige Protokollerweiterungen absehen konnte, warum hat er sie dann nicht vor 1.0 eingebaut?

Weil es die Veröffentlichung der Version 1.0 verzögert hätte. Bei jeder Gelegenheit und bei jedem Vortrag (BTW: Hast du dir den Vortrag von ihm angeschaut bzw. die ersten Minuten?) hat er erläutert, warum er die Version 1.0 will und was "Version 1.0" bedeutet, und das lange, bevor die Version 1.0 veröffentlicht wurde.

Ja, und was bringt es, eine stabile API auszurufen, nur um nachher festzustellen, dass diese API eben ungenügend ist? Die angebliche Sicherheit für Entwickler durch eine stabile API 1.0 ist hinfällig, wenn die nachher feststellen, dass das eigene Programm eh erst ab API 1.4 sinnvoll läuft.

Du, ich glaub's dir ja, dass man, wenn man seine Äußerungen gründlich genug studiert, darauf hätte kommen können, dass mit dem Protokoll eben nicht das Protokoll gemeint ist, sondern nur ein paar Definitionen in den Header-Dateien, und dass er mit "wir sind noch nicht fertig" soviel meinte wie "wir sind noch sehr weit von fertig entfernt". Genau weiß ich es aber nicht, und mir ist es lieber zu glauben, dass er Wayland für weitgehend fertig hielt, als dass er versucht hat, andere Entwickler arglistig zu täuschen, dass Wayland doch schon so weit fertig sei, dass man es sinnvoll benutzen könnte. Darauf läuft es nämlich hinaus, wenn man eine "stable client API" ausruft, obwohl man weiß, dass die so noch nicht sinnvoll nutzbar ist. Die darauffolgenden umfangreichen Diskussionen, ob und wie man welches neue Feature am besten implementiert, deuten meiner Meinung nach eher auf die erste Variante hin.

Das Video habe ich nach ein paar Minuten abgebrochen ... der stottert zuviel und wechselt dauernd die Folien. Aber auch da habe ich nichts davon gehört, dass er der Meinung sei, Wayland müsse unbedingt noch erweitert werden, bevor man es zur Darstellung eines heute üblichen Desktops verwenden kann. Im Gegenteil, beim Drin-Rumklicken hab ich noch Erläuterungen aufgeschnappt, was denn an Wayland so besonders ist, und recht oft "Weston" gehört, was einen vermuten lassen könnte, dass weitere Entwicklungsarbeit in Weston fließen soll. Ganz am Ende (ca. 1h10m) habe ich noch eine interessante Passage über ein experimentelles Fenster-Forwarding gefunden ... da würde man natürlich vermuten, dass er eben sowas meint, wenn er von "moving the protocol forward" spricht ... optionale Protokoll-Ergänzungen, die er vorher schon in Erwägung gezogen hat.

"but from now on we'll use the versioning mechanism when possible and only break API if absolutely necessary." auf 0.95 bis 1.0.

Von der absoluten Notwendigkeit des nächsten API-Bruches bei Ver.0.99 scheint er demnach da ja noch nichts geahnt zu haben ...

"This also doesn't mean that the protocol won't be extended in the future, just that we will not change what's there now." auf die Zukunft ab Version 1.0.

... und hat sich für Ver.1.0 dann endgültig eine ausreichende API erhofft. Da würden sich zwei Irrtümer stimmig aneinanderreihen.

Wenn die Fachpresse nicht einmal dazu in der Lage ist, die ersten fünf Sätze der Ankündigung zu lesen, ja dann... Kann dann wirklich Kristian Høgsberg was dafür?

Das lesen ist nicht das Problem, sondern die Frage, wie man es versteht. Den Berichten von damals kann man aber entnehmen, dass die Stimmung wohl generell etwas zu euphorisch war. Wie deutlich Hogsberg dem hätte entgegen wirken sollen, ist inzwischen eine Frage für Historiker.

und reicht als "Warnung" bei weitem nicht aus. Dass Hogsberg da noch deutliche Defizite sieht, auch wenn man Wayland nur als Protokoll-Spezifikation auffasst, und nicht als Implementation, das stellt er nirgends deutlich genug heraus.

Fünf Sätze! In dreien steht explizit "the protocol" bzw. "the protocol and client side API". Zu den Defiziten: Da steht explizit "we're confident that the protocol we have now covers the basic features". "basic features" (und nicht etwa "all features"). Was hätte er als Warnung dazuschreiben sollen? "A big fat warning for the ones who are not able to read and understand five sentences: ..."? Und es steht nicht umsonst "As I've said before" da. Er hat es wirklich bei jeder Gelegenheit gesagt bzw. geschrieben.

Tja, wo mag der Unterschied zwischen "stable protocol" und "stable header files" liegen, und der Unterschied zwischen "can't" und "won't"? Und was mögen "basic features" eines Protokolls sein? Und warum sollte man ein Protokoll als "stable" bezeichnen, wenn es noch nicht feature-complete ist? Und welches Feature wollte Wayland eigentlich erfüllen, weswegen es angetreten ist? Eh, ach ja, X als Display-Server abzulösen ...

Wenn es ihm wirklich nur darum ging, dass Clients fehlerfrei durchkompilieren, völlig unabhängig von der Funktionalität, dann war eine Ver.1.0 maßlos übertrieben. Glaub ich aber nicht. Haben etliche andere Leute auch nicht geglaubt.

[nudgegoonies]

Es klang für mich logisch, dass ein 80x20 Knopf mit OK drin als 24 Bit Pixmap länger zum übertragen braucht als ein vektorisiertes "zeichne Kasten von X,Y bis X,Y mit 2 Buchstaben von dem Font in der Größe drin".

Ja, schon ... aber den Font schickt man am besten gleich noch mit, außerdem will man heutzutage auch die Fensterdekoration selber bestimmen, und vielleicht noch nen nettes Hintergrundbild haben, und überhaupt, Schrift ist out, Symbole sind in, und überall müssen erklärende kleine Popup-Fenster über den Symbolen auftauchen. Und dann geht es wirklich genau so schnell, die Pixmap komprimiert über die Leitung zu schicken, zumal sich computergenerierte Grafiken meist sehr gut komprimieren lassen.

Und wenn du dann von deinem Primitiv-Beispiel abweichst, und dir mal überlegst, was z.B. ein Webbrowser alles machen müsste, um eine komplexe HTML-Seite in X zu transcodieren - das kostet ja auch alles Rechenzeit... und wehe, das Design sieht remote anders aus, dann ist der Browser schuld. Dann noch ein paar animierte Gifs und Menüs, und du bist mit einem Video-Codec besser dran. Zumal du bei einem Video-Codec die Wahl hast zwischen "flüssig und hässlich" und "stockend und hübsch", während du bei X auf "stockend und hübsch" festgenagelt bist.

Außerdem exerziert X das gesamte Netzwerkprotokoll auch durch, wenn dein lokales Programm was auf dem lokalen X-Server darstellen will, weil "Protokoll ist halt Protokoll", und das ist einfach überflüssig. Darum will Wayland ja auch kein Netzwerk zwingend zwischen Programm und Grafikkarte haben und sagt, das solle man optional implementieren, oder anderswo.

Sehr gute Erklärung und völlig schlüssig. Allerdings wäre zumindest eine rudimentäre API sinnvoll, über die z.B. ein VNC Server mitkriegt wo gerade was geändert wurde, damit nur der Bereich der Änderung übertragen werden muss, wo der Mauszeiger ist etc.

[NAB]

Allerdings wäre zumindest eine rudimentäre API sinnvoll, über die z.B. ein VNC Server mitkriegt wo gerade was geändert wurde, damit nur der Bereich der Änderung übertragen werden muss, wo der Mauszeiger ist etc.

Ich hätte ja gerne mehr als eine "rudimentäre API", das darf schon Hand und Fuß haben.

Schau dir mal das Video von owl102 an:
https://www.youtube.com/watch?v=L8zwnqKysfI
Ab ca. 1h10m, da führt er schon experimentelles Window-Forwarding unter Wayland vor. Nur davon, dass es das inzwischen als Extension in Wayland geschafft hat, darüber finde ich nichts.

VNC und Co. sollten eh möglich sein ... Wayland verhindert das ja nicht, es will die Bilder nur nicht mehr zwangsweise über ein Netzwerkprotokoll an die Grafikkarte schicken, die auch schon längst mit Bitmaps und Textures hantiert, statt mit Linien und gefüllten Flächen. Gegen ein optionales Netzwerkprotokoll spricht nichts.

[owl102]

Ja, und was bringt es, eine stabile API auszurufen, nur um nachher festzustellen, dass diese API eben ungenügend ist?

Das Urteil "ungenügend" (= 6) finde ich etwas hart. "we're confident that the protocol we have now covers the basic features", ich denke, diese Einschätzung von ihm passt ganz gut, auch wenn man sich sicherlich darüber streiten kann, was nun genau die "basic features" beinhaltet und was nicht.

Die angebliche Sicherheit für Entwickler durch eine stabile API 1.0 ist hinfällig, wenn die nachher feststellen, dass das eigene Programm eh erst ab API 1.4 sinnvoll läuft.

Das sehe ich überhaupt nicht so. Programmcode, der für die API 1.0 geschrieben wurde, funktioniert auch unter der API 1.4, ist also nicht hinfällig. Es müssen "nur" ggf. Ergänzungen vorgenommen werden. Dies ist aber grundsätzlich bei allen APIs so, GTK+ 2.0 mag zum Beispiel stabil bzgl. Abwärtskompatibilität sein, wenn man aber Features benötigt, die es erst ab GTK+ 2.16 gibt, dann läuft das Programm erst ab GTK+ 2.16.

Das Video habe ich nach ein paar Minuten abgebrochen ... der stottert zuviel und wechselt dauernd die Folien.

Ja, er ist wahrlich nicht der perfekt vortragende, um das 'mal vorsichtig auszudrücken. Ich habe den Vortrag auch nicht in einem Rutsch geschafft. Dennoch fand ich ihn informativer als z.B. https://www.youtube.com/watch?v=GWQh_DmDLKQ -- nette Unterhaltung, aber recht wenig konkrete Informationen.

Und warum sollte man ein Protokoll als "stable" bezeichnen, wenn es noch nicht feature-complete ist?

Weil das üblich (und sinnvoll) ist, bei jeder Programmierschnittstelle. Man kann die API durcharbeiten, Code schreiben, in dem Wissen, daß nicht morgen alles wieder ganz anders ist und der eigene Code nicht mehr funktioniert.

[NAB]

Ja, und was bringt es, eine stabile API auszurufen, nur um nachher festzustellen, dass diese API eben ungenügend ist?

Das Urteil "ungenügend" (= 6) finde ich etwas hart. "we're confident that the protocol we have now covers the basic features", ich denke, diese Einschätzung von ihm passt ganz gut, auch wenn man sich sicherlich darüber streiten kann, was nun genau die "basic features" beinhaltet und was nicht.

Ich verteile keine Schulnoten. Ich muss mich in einer API ausdrücken können, also damit das formulieren können, was ich erreichen will (von Fehlern in der Implementierung mal ganz abgesehen). Entweder die API genügt diesem Anspruch, oder sie ist eben ungenügend. Danach könnte man Noten verteilen, je nachdem wie einfach oder umständlich die API zu bedienen ist, aber das ist Geschmackssache. Dabei könnte Wayland sogar schlechter abscheiden als X, weil X einigen Service bietet, der Wayland fehlt, und den ich somit selber implementieren muss. Aber das ist beabsichtigt, darum ist es sinnlos, darüber zu meckern.

Die API von Wayland genügt immer noch nicht dem Anspruch, einen X-Desktop ohne Funktionseinbußen damit ausdrücken zu können.

Das sehe ich überhaupt nicht so. Programmcode, der für die API 1.0 geschrieben wurde, funktioniert auch unter der API 1.4, ist also nicht hinfällig. Es müssen "nur" ggf. Ergänzungen vorgenommen werden. Dies ist aber grundsätzlich bei allen APIs so, GTK+ 2.0 mag zum Beispiel stabil bzgl. Abwärtskompatibilität sein, wenn man aber Features benötigt, die es erst ab GTK+ 2.16 gibt, dann läuft das Programm erst ab GTK+ 2.16.

(neeeee, GTK2 ist eben nicht abwärtskompatibel)
Du denkst hier rückwärts, das ist die falsche Richtung. Wenn ich Funktionen aus GTK2.16 zwingend benötige, dann existiert das Programm vor Ver.2.16 schlicht nicht, weil es unmöglich ist, es zu schreiben. Ich weiß ja nicht, ob und wann und in welcher Form die fehlenden Funktionen nachgeliefert werden.

Wenn ich gutgläubig von GTK1 (X) auf GTK2 (Wayland1.0) portieren möchte, und dann feststelle, dass das vorne und hinten nicht klappt, dann fühle ich mich erst mal verarscht. Zum Glück sind die Wayland-Entwickler da sehr kooperativ und deutlich willig, notwendige Funktionen nachzurüsten. Daran, dass das trotzdem ewig dauert, erkennt man, dass es eben keine kleinen Schönheitsfehlerchen waren, sondern komplexe Mängel.

Als Programmierer muss ich dann auf Ver.2.16 warten, bevor ich ein funktionsfähiges Programm abliefern kann. Davor kann ich höchstens ne unvollständige Demo zeigen, bei der es ziemlich egal wäre, ob ich bei API-Änderungen noch was nachkorrigieren muss, denn das muss ich eh, bevor es fertig ist. Und ich habe keine Ahnung, wie groß die anstehenden Änderungen sein werden, weil ich keine Ahnung habe, was mir Ver.2.16 bringen wird, sofern Ver.2.16 überhaupt hilft. Da kann der Anbieter seine API für so "stable" und vollständig halten, wie er will, für mich ist sie unvollständig, und somit "unstable" (hoffentlich) oder "unusable" (wär blöd).

Eine stabile API, die ungenügend ist, hilft mir also überhaupt nicht. Da hätte ich lieber eine instabile API, die genügt. Noch lieber natürlich eine stabile API, die genügt.

[owl102]

(neeeee, GTK2 ist eben nicht abwärtskompatibel)

Eine Anwendung, entwickelt unter GTK+ 2.0, läuft auch unter GTK+ 2.32.

Wenn ich Funktionen aus GTK2.16 zwingend benötige, dann existiert das Programm vor Ver.2.16 schlicht nicht, weil es unmöglich ist, es zu schreiben. Ich weiß ja nicht, ob und wann und in welcher Form die fehlenden Funktionen nachgeliefert werden.

Im Falle von Wayland kann man aber IMHO davon ausgehen, daß fehlende API-Funktionalitäten nachgereicht werden.

Daran, dass das trotzdem ewig dauert, erkennt man, dass es eben keine kleinen Schönheitsfehlerchen waren, sondern komplexe Mängel.

Es ist auch eine Sache von Prioritäten, daher kann man alleine von der Dauer nicht auf die Komplexität der Mängel schließen.

Als Programmierer muss ich dann auf Ver.2.16 warten, bevor ich ein funktionsfähiges Programm abliefern kann. Davor kann ich höchstens ne unvollständige Demo zeigen

Ja, im Prinzip ist es ja auch das, was Gnome zur Zeit macht, nur daß sie es eben nicht "Demo" nennen, sondern "Technology Preview". Für Entwickler ist das ein großer Schritt. Für Anwender taugt es hingegen lediglich zum Zeitvertreib oder dem Füllen von Blogs/Foren, wie "ganz toll" oder "ganz schrecklich" der akt. Stand ist, je nachdem ob der Anwender ein "Glas halb voll"- oder "Glas halb leer"-Typ ist

Eine stabile API, die ungenügend ist, hilft mir also überhaupt nicht.

Doch, man kann anfangen, mit dem Studium der API und der Implementation. Man hat die Gewissheit, daß man in absehbarer Zukunft keine Zeit mit der Anpassung an inkompatiblen Änderungen verschwenden muß. Man hat als System/Distribution einen Grundstock, wo auch innere Komponenten aktualisiert werden können (z.B. der Wayland-Compositor), ohne daß äußere Komponenten wie z.B. Gnome inkompatibel werden und zwangsweise angepasst werden müssen.

Da hätte ich lieber eine instabile API, die genügt.

Man stelle sich vor, dies wäre der aktuelle Stand der Client API von Wayland. Alle GUI-Toolkit-Entwickler müssten ständig Extrazeit mit den Anpassungen an (inkompatible) Änderungen verbraten, was einem eine brauchbare Zeitabschätzung unmöglich macht und damit u.U. die komplette Releaseplanung verhagelt. Nach dem Update vom Wayland-Compositor würde nicht einmal die Oberfläche hochfahren. Als Entwickler muß ich erst einmal warten, bis Kollegen mit ihren Anpassungen fertig sind, erst dann kann man anfangen, die Oberfläche wieder lauffähig kompilieren zu wollen. Wenn sie dann immer noch nicht wieder funktioniert, muß erst einmal gemeinsam herausgefunden werden, an was das liegt, einer fehlerhaften Anpassung (wenn ja, wo und von wem?) oder einer vergessenen Anpassung oder einem neuen Fehler, der bei einer Anpassung hinzugekommen ist (wenn ja, wo und von wem?) oder oder oder... Nett ist auch der Zustand, wenn eine inkompatible Änderung zwar schon angekündigt ist, aber noch keine Komponenten auf diesem Stand vorliegen (also noch kein passender Wayland Compositor). Dieser Zustand motiviert einem nicht gerade zum weiterarbeiten, stattdessen geht man (genervt) im Kopf schon einmal die ganzen Dinge durch, die geändert werden müssen, um abzuschätzen, um wieviel Zeit sich dadurch das Projekt erneut verzögert.

Von den Anwendungsentwicklern, die auf eine neue und funktionierende Toolkit-Variante samt passender Desktopumgebung angewiesen sind, mag ich gar nicht erst schreiben, die hängen ja ganz hinten an der Chaos-Kette.

Daher glaube ich nicht, daß irgendein Software-Entwickler lieber eine instabile API möchte, die genügt.

[NAB]

(neeeee, GTK2 ist eben nicht abwärtskompatibel)

Eine Anwendung, entwickelt unter GTK+ 2.0, läuft auch unter GTK+ 2.32.

http://en.wikipedia.org/wiki/Backward_compatibility

Im Falle von Wayland kann man aber IMHO davon ausgehen, daß fehlende API-Funktionalitäten nachgereicht werden.

Jupp ... irgendwann ...

Es ist auch eine Sache von Prioritäten, daher kann man alleine von der Dauer nicht auf die Komplexität der Mängel schließen.

Nein, aber vom Umfang der Diskussionen auf den Mailinglisten über fehlende Features und eingereichte Patches.

Als Programmierer muss ich dann auf Ver.2.16 warten, bevor ich ein funktionsfähiges Programm abliefern kann. Davor kann ich höchstens ne unvollständige Demo zeigen

Ja, im Prinzip ist es ja auch das, was Gnome zur Zeit macht,

Nein. Was Gnome zu der Zeit machte, als Wayland 1.0 ausgerufen wurde, war, sich mit den Wayland-Entwicklern zusammenzusetzen, und gemeinsam fehlende Funktionalität durchzudiskutieren und Wayland in ihrem Interesse weiterzuentwickeln. Das ist natürlich mächtig praktisch, wenn man von Red Hat dafür bezahlt wird, dass man die benötigte API gleich mitentwickelt. Dieses Privileg hatten aber nicht alle Entwickler.

Der Rest der Entwickler scheint eher abzuwarten, bis Red Hat und Intel fertig sind, und Wayland einen Zustand erreicht hat, den man guten Gewissens als 1.0 bezeichnen könnte. Das ist auch das, was ich tun würde, wenn man mir eine ungenügende API vorsetzt.

Eine stabile API, die ungenügend ist, hilft mir also überhaupt nicht.

Doch, man kann anfangen, mit dem Studium der API und der Implementation.

Nein, eben nicht. Man kann die API studieren und feststellen, dass eine Implementation unmöglich ist, weil die API unvollständig ist. Nebenbei ... guck dir mal an, was das für Header-Dateien sind, die Wayland da als "stable" ausgerufen hat ... da brauchst du nicht lange zum Studium. Mehr "stable" ist da nicht dran.

Man hat als System/Distribution einen Grundstock, wo auch innere Komponenten aktualisiert werden können (z.B. der Wayland-Compositor), ohne daß äußere Komponenten wie z.B. Gnome inkompatibel werden und zwangsweise angepasst werden müssen.

Siehste ... eben nicht. Die API zum Compositor wurde erst nen Dreivierteljahr später "stable", weil Gnome gerne Mutter umbauen wollte.

Da hätte ich lieber eine instabile API, die genügt.

Man stelle sich vor, dies wäre der aktuelle Stand der Client API von Wayland. Alle GUI-Toolkit-Entwickler müssten ständig Extrazeit mit den Anpassungen an (inkompatible) Änderungen verbraten, was einem eine brauchbare Zeitabschätzung unmöglich macht und damit u.U. die komplette Releaseplanung verhagelt.

Der Wayland-Stand von Gnome 3.14 war ursprünglich für 3.10 angepeilt, dann für 3.12. Quellen:
http://blogs.gnome.org/uraeus/2013/09/0 ... nd-update/
https://mail.gnome.org/archives/desktop ... 00199.html

Ja, man stelle sich mal vor, die Release-Planung sei verhagelt ... ^^

[owl102]

http://en.wikipedia.org/wiki/Backward_compatibility

Bitte quote den Satz bzw. Absatz daraus, der meiner Aussage widerspricht, daß GTK+ 2.x abwärtskompatibel zu GTK+ 2.0 ist.

Was Gnome zu der Zeit machte, als Wayland 1.0 ausgerufen wurde, war, sich mit den Wayland-Entwicklern zusammenzusetzen, und gemeinsam fehlende Funktionalität durchzudiskutieren

Was ja auch völlig ok ist. Es ist eine ernsthafte Auseinandersetzung mit der API. Das sind ganz normale Entwicklungsprozesse. Wobei sich mir schon die Frage stellt, warum den Gnome-Leuten das (angeblich) nicht vor Version 1.0 aufgefallen ist?

Der Rest der Entwickler scheint eher abzuwarten, bis Red Hat und Intel fertig sind, und Wayland einen Zustand erreicht hat, den man guten Gewissens als 1.0 bezeichnen könnte.

Wen definierst du als "der Rest der Entwickler"? Die Qt-Entwickler haben offensichtlich nicht abgewartet und diejenigen von Enlightenment auch nicht. Mate wagt zur Zeit den (optionalen) Sprung auf GTK+ 3. Xfce hat sowieso keine Leute für sowas.

Und Formulierungen wie "guten Gewissens als 1.0 bezeichnen könnte" finde ich einfach nur anmaßend, lächerlich und kleinkariert. Es ist nur eine Versionsnummer. Hätte Gnome 3.0 schon die Versionsnummer 3.0 haben dürfen? Ist KDE Plasma 5.0 schon eine 5.0? Oder im Falle von APIs: War ODBC 1.0 schon eine 1.0? Wo ist da die moralische Instanz, wo kann ich nachlesen, wann ich einer API bzw. einer Komponente die Version 1.0 geben darf? Und wieso müssen die Wayland-Entwickler ein schlechtes Gewissen haben?

Die Wayland-Entwickler haben schon in der Roadmap zu Version 1.0 klar gemacht, was sie unter "1.0" verstehen und damit definiert, was es für die Entwicklung von Wayland bedeutet. Sie haben es als Meilenstein gesehen, und auch dazugeschrieben, warum. (Vielleicht sollte man wirklich eine Versionierung a la Canonical wählen, nur damit keine Korinthenkacker auf der Versionsnummer herumreiten können.)

Eine stabile API, die ungenügend ist, hilft mir also überhaupt nicht.

Doch, man kann anfangen, mit dem Studium der API und der Implementation, man kann erste Sachen austesten, erste Erfahrungen sammeln usw.

Nein, eben nicht. Man kann die API studieren und feststellen, dass eine Implementation unmöglich ist, weil die API unvollständig ist.

Natürlich kann man schon anfangen, erste Sachen zu implementieren oder sich zumindest Gedanken über die interne Architektur zu machen oder... Wie weit man damit kommt, ist eine andere Frage. Auch hier haben wir wieder "halb voll" und "halb leer"-Typen, also ist es sinnfrei darüber zu diskutieren, man wird keinen Konsenz finden.

Die API zum Compositor wurde erst nen Dreivierteljahr später "stable", weil Gnome gerne Mutter umbauen wollte.

Die Client API wurde mit Version 1.0 stable, die Wayland Server API mit Version 1.2. Mir ist nichts von Kompatiblitätsbrüchen bekannt, allerdings habe ich auch nicht die Release Notes zu jeder Version studiert. Mit dem Compositor hast du recht, das Beispiel war von mir schlecht gewählt.

P.S.: Wie bin ich überhaupt hierher gekommen? Ach ja, ich besaß die Frechheit, zu behaupten, ich würde einen Fortschritt beim Thema Wayland sehen und würde den X-Kritikern ihre Meinung abkaufen, X müsse langfristig ersetzt werden, weil mir selbst das Know-How fehlt, um das beurteilen zu können.

[NAB]

Bitte quote den Satz bzw. Absatz daraus, der meiner Aussage widerspricht, daß GTK+ 2.x abwärtskompatibel zu GTK+ 2.0 ist.

Würd ich ja gerne ... leider schriebst du:

GTK+ 2.0 mag zum Beispiel stabil bzgl. Abwärtskompatibilität sein,

Aber gut, dann meinen wir wohl dasselbe

Was Gnome zu der Zeit machte, als Wayland 1.0 ausgerufen wurde, war, sich mit den Wayland-Entwicklern zusammenzusetzen, und gemeinsam fehlende Funktionalität durchzudiskutieren

Was ja auch völlig ok ist. Es ist eine ernsthafte Auseinandersetzung mit der API. Das sind ganz normale Entwicklungsprozesse. Wobei sich mir schon die Frage stellt, warum den Gnome-Leuten das (angeblich) nicht vor Version 1.0 aufgefallen ist?

Ja, natürlich ist das "okay", aber es ist halt nicht "normal", dass außenstehende Entwickler dann auch bei der Weiterentwicklung der API mit anpacken. Normal ist, dass man sie halt benutzt, und ggf. Fehler meldet. Und dazu muss sie benutzbar sein. Sonst sagt man "so'n Scheiß, ich nehm was anderes".

Wann den Gnome-Leuten da was aufgefallen ist, wäre in der Tat interessant, aber ich hab keine Lust, das zu recherchieren, zumal das wieder auf Spekulationen und Interpretationen hinauslaufen würde. Und gerade um die mysteriöse "Ver.1.0" geht's ja ...

Der Rest der Entwickler scheint eher abzuwarten, bis Red Hat und Intel fertig sind, und Wayland einen Zustand erreicht hat, den man guten Gewissens als 1.0 bezeichnen könnte.

Wen definierst du als "der Rest der Entwickler"? Die Qt-Entwickler haben offensichtlich nicht abgewartet und diejenigen von Enlightenment auch nicht. Mate wagt zur Zeit den (optionalen) Sprung auf GTK+ 3. Xfce hat sowieso keine Leute für sowas.

Qt ist kein Desktop, und die KDE-Entwickler scheinen sich nach kurzen Experimenten für "Abwarten" entschieden zu haben. Und das Engagement von Qt hast du selber schon bemängelt.
Bei Enlightenment bin ich mir unsicher, wieviel Arbeit die da überhaupt reingesteckt haben. Die scheinen vorallem auf EGL umzustellen, was erst mal unabhängig von Wayland funktioniert. Ansonsten läuft's auf XWayland und scheint Weston zu nutzen, da der eigenen Compositor noch ein Abenteuerspielplatz ist. Die haben also auch eher abgewartet, und basteln jetzt das nach, was Gnome schon hingekriegt hat.
Mate hat also die letzten zwei Jahre abgewartet, während die Gnome-Leute GTK3 portiert haben? ... gut, gut.
Xfce hat nicht "keine" Leute, sondern grob geschätzt zwei oder so *hüstel*. Die bereiten sich, genau wie Mate, langsam auf den Umzug auf GTK3 vor:
https://wiki.xfce.org/releng/4.12/roadmap/gtk3
Und ich weiß zwar nicht, wer dieser "Magnus" ist aber er trifft's ganz gut:
https://forum.xfce.org/viewtopic.php?id=8138
Und was machen eigentlich Firefox, OpenOffice, VLC, Gimp, Audacity, Debian, Suse? (immerhin Google gibt da Gas, aber die haben ja auch hohe Eigeninteressen und ne pralle Portokasse)
Und wen gibt's sonst noch? Ich hab keine Ahnung, ob Mesa sich mehr Mühe geben könnte, OpenGL in Wayland reinzukriegen, und wie engagiert der Support sonst auf der "hinteren" Seite von Wayland so ist. Ach, doch ... Nvidia hat lange abgewartet, AMD vertröstet auf später, und Canonical hat Mir ja bekanntlich seit Jahren fast fertig, wartet also im Zweifelsfall auch ab.

Oder im Falle von APIs: War ODBC 1.0 schon eine 1.0?

Der Vergleich ist unfair ... ODBC 1.0 war ja eigentlich CLI 2.0, und hatte damit einen abgenickten Industriestandard im Rücken. Und Wayland hat ja die schwierige Aufgabe, ein etabliertes Protokoll zumindest zu ersetzen. Aber mal gucken ... wurde denn ODBC1 dem Anspruch gerecht, eine generelle API zum Austausch von Dynamic SQL zu sein? Eigentlich schon, oder? Mir sind keine Showstopper bekannt (von der implementationsbedingten Performance mal abgesehen).

Und wieso müssen die Wayland-Entwickler ein schlechtes Gewissen haben?

Vielleicht, ganz vielleicht, haben sie inzwischen eins, weil ihnen aufgefallen ist, dass die Veröffentlichung von 1.0 etwas hoch gegriffen war. Höchstwahrscheinlich, und hoffentlich, haben sie aber was besseres zu tun, z.B. an Wayland zu arbeiten.

(Vielleicht sollte man wirklich eine Versionierung a la Canonical wählen, nur damit keine Korinthenkacker auf der Versionsnummer herumreiten können.)

Ja, das wär klasse! Bei Canonical haben auch nur fertige Versionen volle Versionsnummern, der Rest heißt "Preview" oder "Testing". Und bei Canonical war schon die erste Version gut benutzbar:
viewtopic.php?t=31657

Natürlich kann man schon anfangen, erste Sachen zu implementieren oder sich zumindest Gedanken über die interne Architektur zu machen oder... Wie weit man damit kommt, ist eine andere Frage. Auch hier haben wir wieder "halb voll" und "halb leer"-Typen, also ist es sinnfrei darüber zu diskutieren, man wird keinen Konsenz finden.

Stimmt, du hast recht, ich habe schwarz-weiß gezeichnet, damit du meinen Standpunkt verstehst.

Aber, ehm, nein. Wenn mir eine API ungenügend vorkommt, dann fange ich nicht an, erste Sachen zu implementieren. Denn dazu müsste ich sicher sein, dass diese API irgendwann brauchbar wird, in meinem Sinne. Und das geht nur, wenn ich einen Chef mit viel Geld im Rücken habe, der sagt "mach das, wir ziehen das jetzt durch". Sonst suche ich mir einfach eine brauchbare API, und die gibt's ja.

P.S.: Wie bin ich überhaupt hierher gekommen? Ach ja, ich besaß die Frechheit, zu behaupten, ich würde einen Fortschritt beim Thema Wayland sehen und würde den X-Kritikern ihre Meinung abkaufen, X müsse langfristig ersetzt werden, weil mir selbst das Know-How fehlt, um das beurteilen zu können.

Öhm ... nö, nö ... _hier_ sind wir, weil ich behauptet habe, die Wayland-Entwickler seien davon ausgegangen, dass Wayland ziemlich fertig ist, als sie Version 1.0 ausgerufen haben. Daraufhin hast du mir heftig widersprochen

[owl102]

Ja, natürlich ist das "okay", aber es ist halt nicht "normal", dass außenstehende Entwickler dann auch bei der Weiterentwicklung der API mit anpacken.

Über "normal" mag ich mich nicht streiten, aber grundsätzlich ist eine Zusammenarbeit zwischen Anbieter der API und Nutzer der API doch zu begrüßen. Fälle, wo API-Anbieter sich nicht reinreden lassen wollen, die finde ich problematisch.

Und dazu muss sie benutzbar sein. Sonst sagt man "so'n Scheiß, ich nehm was anderes".

Das kommt auf den Scheißfaktor an. Wenn nur ein bischen Scheiße da ist und einem der Kram ansonsten zusagt, was spricht dagegen, mitzuhelfen, die Scheiße zu beseitigen anstatt die Segel zu streichen? Hinzu kommt: Was wäre denn "was anderes", Mir?

Mate hat also die letzten zwei Jahre abgewartet, während die Gnome-Leute GTK3 portiert haben? ... gut, gut.

Ich denke Mate ist gedanklich sowieso noch nicht bei Wayland angekommen, die sind ja froh, überhaupt ihren ollen Krempel halbwegs im Griff zu haben, dort erste Bugfixes vornehmen zu können usw. Die letzte große Aufräumaktion ist bei denen auch noch nicht so lange her. Den Schritt auf GTK+ 3 finde ich zum jetzigen Zeitpunkt gewagt, Hut ab vor so viel Engagement und Arbeitseifer! (Und überhaupt Hut ab für die bisher geleistete Arbeit, hätte ich nicht mit gerechnet, daß sich Mate so gut entwickelt.)

Und ich weiß zwar nicht, wer dieser "Magnus" ist aber er trifft's ganz gut:

Ja, finde ich auch. Zumal Xfce ganz andere, IHMO viel wichtigere Baustellen hat, wie z.B. die Harmonisierung von Thunar und xfdesktop. Es ist außstenstehenden IMHO nicht zu vermitteln, wieso sich Dateien auf dem Desktop anders verhalten als Dateien in einem Ordner auf dem Desktop.

Und was machen eigentlich Firefox

Von Firefox gibt es einen GTK3-Port, der aber nur sehr mäßig funktioniert. Das Projekt scheint Anfang letzten Jahres etwas eingeschlafen zu sein, leider. Und unter Wayland funktioniert der GTK3-Port schon gar nicht.

OpenOffice, VLC, Gimp, Audacity

Keine Ahnung.

Debian

Debian ist gerade mit der Spaltung wegen systemd beschäftigt, die haben also noch keine Zeit gefunden, sich wegen Wayland zu spalten

Suse?

Die verdauen immer noch Mai 2011? (...und schauen erstmal auf die Zahlen?)

wurde denn ODBC1 dem Anspruch gerecht, eine generelle API zum Austausch von Dynamic SQL zu sein? Eigentlich schon, oder? Mir sind keine Showstopper bekannt (von der implementationsbedingten Performance mal abgesehen).

AFAIR waren viele der Meinung, ODBC sei erst ab 2.0 zu gebrauchen. Ich weiß aber nicht mehr warum, es ist einfach zu lange her und ich habe jetzt keine Lust/Zeit zum suchen... (Ich selber kenne ODBC erst ab 2.0.) Aber vielleicht schreibe ich hier auch gerade Käse, wäre ja nicht das erste Mal

Und bei Canonical war schon die erste Version gut benutzbar:

und seitdem geht es bergab Aber das ist ein anderes Thema... Aber wo wir gerade bei Canonical sind: Ich denke sehr viel (zu frühen) Wirbel um Wayland verdanken wir Herrn Shuttleworth.

Aber, ehm, nein. Wenn mir eine API ungenügend vorkommt, dann fange ich nicht an, erste Sachen zu implementieren. Denn dazu müsste ich sicher sein, dass diese API irgendwann brauchbar wird, in meinem Sinne. Und das geht nur, wenn ich einen Chef mit viel Geld im Rücken habe, der sagt "mach das, wir ziehen das jetzt durch". Sonst suche ich mir einfach eine brauchbare API, und die gibt's ja.

Naja, bei einer Neuentwicklung würde ich mir das zehnmal überlegen, bevor ich auf X setze. Nein, eigentlich würde ich nur einmal ganz kurz überlegen

Öhm ... nö, nö ... _hier_ sind wir, weil ich behauptet habe, die Wayland-Entwickler seien davon ausgegangen, dass Wayland ziemlich fertig ist, als sie Version 1.0 ausgerufen haben. Daraufhin hast du mir heftig widersprochen

Naja, ich habe halt so ziemlich jeden Ball aufgefangen, den du geworfen hast. Was kurios ist, denn im RL gelingt mir das nie, im Gegenteil.

[NAB]

Fälle, wo API-Anbieter sich nicht reinreden lassen wollen, die finde ich problematisch..

Du meinst Fälle wie den hier?
http://lists.freedesktop.org/archives/w ... 08131.html
Joa, find ich auch ^^

Und dazu muss sie benutzbar sein. Sonst sagt man "so'n Scheiß, ich nehm was anderes".

Das kommt auf den Scheißfaktor an. Wenn nur ein bischen Scheiße da ist und einem der Kram ansonsten zusagt, was spricht dagegen, mitzuhelfen, die Scheiße zu beseitigen anstatt die Segel zu streichen?

Du, wir reden von einer API, nicht von kleineren "scheiß" Bugs in der Implementation. Sicherlich kann und sollte man helfen, Fehler zu beseitigen. Aber wenn ich mir eine API angucke, und sehe, die taugt nicht für meine Zwecke, dann denke ich mir, ich bin einfach an der falschen Adresse. Wenn ich auf die Idee komme, einen MP3-Player in OpenGL schreiben zu wollen, und dann den Leuten in den Ohren liege, dass da unbedingt noch Aufrufe für Sound mit reinmüssen, dann ergeht es mir wohl so wie im Beispiel oben.

Und was KDE, Mate, Xfce, Firefox, OpenOffice, VLC, Gimp, Audacity, Debian, Suse, Nvidia, AMD u.s.w. angeht ... du hast Wayland deutliche Fortschritte attestiert und dich auf eine X-Freie Zukunft gefreut. Mir ging's darum, dass diese Fortschritte im Moment vorallem auf der Arbeit von Intel und Red Hat basieren (wo die natürlich auch Geld und Arbeit reinstecken), während etliche andere Projekte erst mal lange lange abgewartet haben, und die Sache misstrauisch beäugt haben. Eine breite Front von Wayland-Unterstützung sehe ich da nicht ... Ablehnung natürlich auch nicht ... aber die Sache scheint in den Augen der meisten Entwickler sehr viel Zeit zu haben. Genau das täte ich auch, wenn ich sehe, die basteln noch eifrig dran rum und noch nicht mal die API ist so ganz tauglich ... zurücklehnen und derweil für X weiterentwickeln.

(X hat nebenbei auch eine ganze Menge Fortschritte gemacht in der Zwischenzeit. Das Szenario, dass X die überlegene Implementation bleibt, ist nicht völlig unmöglich)

AFAIR waren viele der Meinung, ODBC sei erst ab 2.0 zu gebrauchen.

Stimmt ... davor war es stinkend langsam und hatte zuwenige Anbindungen an andere Datenbanksysteme. Das betrifft aber die Implementation, und wir waren bei der API. Und die hat getaugt, als Anbindung an SQL. Dadurch hat es ja überhaupt erst Interesse, Aufsehen, und dann natürlich auch Meckerei bekommen.

Aber wo wir gerade bei Canonical sind: Ich denke sehr viel (zu frühen) Wirbel um Wayland verdanken wir Herrn Shuttleworth.

hmmm ... weiß ich nicht ... ich erinnere mich an viele Artikel mit X11-Abgesang in den Medien, rund um das erste Wayland-Release, und eine Zusage von Shuttleworth zu Wayland ... dann kam Wayland 1.0 ... und dann erst kam die Ankündigung von Mir. Danach wurde es eher ruhiger ... von diesem hässlichen Gezicke zwischen Intel und Canonical mal abgesehen.

Naja, bei einer Neuentwicklung würde ich mir das zehnmal überlegen, bevor ich auf X setze. Nein, eigentlich würde ich nur einmal ganz kurz überlegen

Kommt drauf an, was es werden soll, oder? Bei einer GUI vermeidet man natürlich eh den direkten Kontakt zu X und setzt auf ein Toolkit - da nimmt man natürlich nicht aus Trotz eines, das ganz bestimmt nie auf Wayland portiert wird. Aber ... öhm ... lieber GTK oder lieber Qt? Ich würd lieber auf Qt setzen ... nachdem Red Hat schon die Portabilität von Gnome kaputt gemacht hat, hätte ich Sorge, dass sie das mit GTK auch noch machen.
Und wie sieht es mit einem Spiel aus? Ob OpenGL jemals auf Wayland laufen wird, steht in den Sternen, sonst hat man ne X-Abhängigkeit. Da setzte ich doch trotzdem lieber auf OpenGL und auf X.
Wenn man jetzt einen neuen Desktop schreiben wollen würde, säße man in der Zwickmühle. Wenn ich davon ausgehe, dass in wenigen Jahren ein brauchbares Ergebnis vorliegen soll, dann würd ich trotzdem primär auf X setzen, denn sonst läuft er eventuell gar nicht. Einen Wayland- und Mir-Port muss man natürlich trotzdem im Auge haben, vielleicht sind sie ja irgendwann fertig.
Und wie sieht's mit Grafiktreibern aus? Tja ... da setzt Intel auch bei brandneuen Chips primär auf X. Die anderen Hersteller auch. Logisch ... die wollen ihren Kram ja verkaufen, bevor er völlig veraltet ist.

Worauf ich hinaus will ... dass X unbedingt von Wayland abgelöst werden muss, das scheint nur einer kleinen Front aus Intel, Red Hat, und ein wenig Samsung und Google so sonnenklar zu sein, wie es hier dargestellt wird. Der Rest übt sich in höflicher Zurückhaltung, um es mal vorsichtig auszudrücken. So brennend eilig wichtig ist die Sache also nicht ... und vielleicht auch gar nicht so erwünscht. Denn sie verursacht vorallem extra Arbeit, und damit auch extra Kosten ... und davon haben nur die was, die sich davon Gewinn versprechen.

Naja, ich habe halt so ziemlich jeden Ball aufgefangen, den du geworfen hast. Was kurios ist, denn im RL gelingt mir das nie, im Gegenteil.

Ja, so kam's mir auch vor ... als ob du zu jedem unbedingt ein Gegenbeispiel finden musst, so sinnig oder unsinnig es auch sein mochte. Das hat zu so lustigen Effekten geführt wie, dass du erst nach Beispielen für die weite und reife Entwicklung von Waland gesucht hast, und nachher dafür, das die Entwicklung ja ganz schön langsam sei (nein, das widerspricht sich nicht unbedingt). So richtig schlimm ist das aber auch nicht, was ich hier behaupte ... nur dass Wayland eventuell nicht die Krone der Schöpfung auf dem Grafik-Protokoll-Markt sein könnte, und dass X erstaunlich langlebig ist, so oft, wie es schon ersetzt werden sollte.

[owl102]

Fälle, wo API-Anbieter sich nicht reinreden lassen wollen, die finde ich problematisch..

Du meinst Fälle wie den hier?
http://lists.freedesktop.org/archives/w ... 08131.html
Joa, find ich auch ^^

Nur weil man sich generell reinreden läßt, heißt das noch lange nicht, daß man sich mit jedem Mist reinreden läßt. "My goals have been to introduce compiz-like effects into weston" sagt doch eigentlich schon alles, oder?

Eine breite Front von Wayland-Unterstützung sehe ich da nicht ... Ablehnung natürlich auch nicht ...

Ich auch nicht. Ich denke wir differieren in vielen Punkten gar nicht so sehr, außer, daß du recht schwarz siehst wo ich grau sehe. Davon ab überinterpretierst du manche meiner Aussagen, denke ich. Freue ich mich auf eine X-freie Zukunft? Ich sehe das so, daß sich einige Entwickler, von deren Meinung ich etwas halte, darauf freuen. Mit "Wayland kommt in die Hufe" meine ich in erster Linie erst einmal Wayland (und Gnome, denn anhand irgendeiner Wayland-Anpassung muß ich ja den aktuellen Status von Wayland in der Praxis beurteilen können), und nicht KDE, Xfce, Mate, ... Was juckt mich zum Beispiel die Wayland-Anpassung von Xfce? Die bekommen einen GTK3-Port sowieso nicht in diesem Jahrzehnt hin, egal ob X oder Wayland oder Mir oder Northfield. (Und sie haben wichtigere Baustellen, die sie schon seit Jahren nicht hinbekommen.)

aber die Sache scheint in den Augen der meisten Entwickler sehr viel Zeit zu haben. Genau das täte ich auch, wenn ich sehe, die basteln noch eifrig dran rum und noch nicht mal die API ist so ganz tauglich ... zurücklehnen und derweil für X weiterentwickeln.

Ich auch.

Aber ... öhm ... lieber GTK oder lieber Qt? Ich würd lieber auf Qt setzen ...

Bis vor kurzem dachte ich das auch. Wenn ich mir aber anschaue, in welche Richtung Digia marschiert ... Naja, die wollen halt Geld verdienen, das kann man ihnen nicht verübeln. Wenn ich jetzt ein neues Projekt starten würde, wüßte ich ehrlich gesagt nicht so recht, ob nun gtkmm oder Qt...

Wenn ich davon ausgehe, dass in wenigen Jahren ein brauchbares Ergebnis vorliegen soll, dann würd ich trotzdem primär auf X setzen, denn sonst läuft er eventuell gar nicht.

Wenn irgendwelche Bugs in GTK+ oder Qt das Laufen verhindern würde, spräche ja nichts dagegen, diese Bugs selber zu beheben.

Das hat zu so lustigen Effekten geführt wie, dass du erst nach Beispielen für die weite und reife Entwicklung von Waland gesucht hast, und nachher dafür, das die Entwicklung ja ganz schön langsam sei (nein, das widerspricht sich nicht unbedingt).

Ich kann als Anwender von X bzw. Wayland den Fortschritt nur anhand dessen beurteilen, was ich sehe bzw. ausprobieren kann. Da brauche ich nicht zu suchen, Gnome 3.14 läuft unter Wayland und immer mehr Gnome-Anwendungen auch. Und beim Thema Langsamheit brauche ich auch nicht zu suchen, diese Möglichkeit war schon für 3.10 angekündigt und war dann nicht da, dann für 3.12 und war immer noch nicht funktionierend, das merke ich ebenfalls als Anwender.

Und spätestens jetzt sind wir bei der zweiten Kreisumrundung angekommen. Magst du das Schlußwort schreiben?

[guennid]

Ich kann und will eure "Kreise" nicht stören, habe aber die ganze Zeit mitgelesen.

Und spätestens jetzt sind wir bei der zweiten Kreisumrundung angekommen. Magst du das Schlußwort schreiben?

Herrlich!

Möchte euch beide ein wenig mit Brecht beglücken:

ich glaube an die sanfte Gewalt der Vernunft über die Menschen. Sie können ihr auf die Dauer nicht widerstehen.

Grüße, Günther

[NAB]

Nur weil man sich generell reinreden läßt, heißt das noch lange nicht, daß man sich mit jedem Mist reinreden läßt. "My goals have been to introduce compiz-like effects into weston" sagt doch eigentlich schon alles, oder?

So pauschal blöd finde ich die Idee gar nicht. Und wenn du dir sein endloses Geschreibsel mal antust, inklusive seiner Folge-Postings, dann findet er durchaus gute Argumente, warum er das gerne direkt in Weston machen will, und warum er dazu die Möglichkeiten haben möchte, experimentelle Erweiterungen in Wayland einzubauen.

Die Wayland-Entwickler sind auf der anderen Seite relativ wortkarg.

Ganz so einfach ist das nämlich nicht mit dem "Fehler beseitigen" und mit einem "hey, ich mach euch mal kurz die API heil" ... das kann schnell endloses Gestreite geben und nachher sitzt du auf einem Fork, den du eigentlich weder haben noch betreuen willst.

Ich auch nicht. Ich denke wir differieren in vielen Punkten gar nicht so sehr, außer, daß du recht schwarz siehst wo ich grau sehe.

*schmunzel* ... und mir kommt es so vor, als sähest du weiß, wo ich grau sehe

Ich sehe nur einen Unterschied zwischen berechtigter Kritik an X und einem Hochloben von Wayland. Wayland beseitigt keineswegs alle Probleme mit X, es will nicht mal X ersetzen, es wird nur "an die Seite geschoben". Andere Probleme von X versucht man gleichzeitig anderswo zu lösen, zum Beispiel in den Toolkits, und mir fehlt die Übersicht um beurteilen zu können, ob dadurch überhaupt etwas besser wird.

Und die Kräfte hinter Wayland sehe ich misstrauisch. Die scheinen vorrangig auf den "Mobile"-Markt abzuzielen, und ich bin mir nicht sicher, ob dabei etwas Gutes für den Linux-Desktop rauskommt.

Wenn irgendwelche Bugs in GTK+ oder Qt das Laufen verhindern würde, spräche ja nichts dagegen, diese Bugs selber zu beheben.

Das ist wieder zu einfach gedacht. Wenn die Entwickler nicht deiner Meinung sind, landest du bei einem Fork von GTK/Qt, wie im Beispiel oben.

Und gerade das Beispiel Wayland zeigt, dass es nicht reicht, kurz ein "hey, da funktioniert was nicht" zu melden, und auch nur innerhalb von Jahren mit einer Lösung rechnen zu dürfen.

Und spätestens jetzt sind wir bei der zweiten Kreisumrundung angekommen. Magst du das Schlußwort schreiben?

Ein Schlusswort unter "Wie geht es weiter mit Wayland?"? Na, das wäre anmaßend ... die Geschichte ist noch lange nicht zuende

Möchte euch beide ein wenig mit Brecht beglücken:

ich glaube an die sanfte Gewalt der Vernunft über die Menschen. Sie können ihr auf die Dauer nicht widerstehen.

"Vernunft" ist Ansichtssache, oder?

[guennid]

"Vernunft" ist Ansichtssache, oder?

Nö.

Aber das nö ist ziemlich kompliziert.

[owl102]

So pauschal blöd finde ich die Idee gar nicht.

Weston ist eine Referenzimplementation. Da halte ich es für völlig legitim, wenn das Wayland-Team sagt, das kannste gerne machen, aber bitte in deinem eigenen Compositor.

Natürlich muß Wayland dann die Implementation von Norwood ermöglichen, so daß kein Northfield notwendig sein sollte, aber das sieht er auch so: "These changes are actually being discussed on the mailing list for possible review and inclusion. Once these basic events/requests go upstream, there will not be a need for northfield as a patched version of wayland."

Und wenn du dir sein endloses Geschreibsel mal antust, inklusive seiner Folge-Postings, dann findet er durchaus gute Argumente, warum er das gerne direkt in Weston machen will

Ich habe zwar einige Beiträge weitergelesen, aber nicht alle. Letztendlich ist es auch eine philosophische Frage, ob das nun direkt in Weston reinkommen darf/soll/kann oder nicht, da, wie schon geschrieben, Weston lediglich eine Referenzimplementation ist. Ich selber habe da durchaus Verständnis für beide Sichtweisen.

und warum er dazu die Möglichkeiten haben möchte, experimentelle Erweiterungen in Wayland einzubauen.

Auch hier sehe ich wieder beide Seiten. Und letztendlich ist es auch recht unwichtig, ob experimentelle Erweiterungen in einen experimentellen Branch von Wayland reinkommen oder in Northfield. (Vom Codehandling ist es leider nicht recht unwichtig, daher finde ich es hier schade, daß es Northfield überhaupt geben muß.) Hauptsache, das, was letztendlich übrig bleibt, landet früher oder später in Wayland.

Ich auch nicht. Ich denke wir differieren in vielen Punkten gar nicht so sehr, außer, daß du recht schwarz siehst wo ich grau sehe.

*schmunzel* ... und mir kommt es so vor, als sähest du weiß, wo ich grau sehe

Ok, einigen wir uns auf: Ich sehe hellgrau, wo du dunkelgrau siehst

Ein Schlusswort unter "Wie geht es weiter mit Wayland?"? Na, das wäre anmaßend ... die Geschichte ist noch lange nicht zuende

Nein, nur ein Schlußwort unter unseren Disput. Der Thread gehört ja nicht nur uns.

P.S.: http://blogs.gnome.org/mclasen/2015/01/ ... e-endgame/

[NAB]

Weston ist eine Referenzimplementation. Da halte ich es für völlig legitim, wenn das Wayland-Team sagt, das kannste gerne machen, aber bitte in deinem eigenen Compositor.

Ja, natürlich ist das legitim. Zumal dieser Entwickler wohl noch ein paar andere Eigenheiten zu haben scheint, die die Zusammenarbeit mit ihm nicht gerade angenehm machen. Du hast "Desktopeffekte" nur als "Mist" bezeichnet, und das sehe ich anders. Nicht, dass ich sie nutze oder mag, aber etlichen Leuten scheinen solche Spielereien doch viel Freude zu bereiten. Und wenn die Mehrzahl der Entwickler gegen einen Entwickler beschließt, dass man keine Desktopeffekte in Weston haben möchte, dann ist das eine Designentscheidung. Basta.

Ich habe den Fall nur als Beispiel genutzt, um aufzuzeigen, dass es eben nicht so leicht ist, einfach daher zu kommen und zu sagen "ich erweitere euch mal die Implementierung/die API".

(Vom Codehandling ist es leider nicht recht unwichtig, daher finde ich es hier schade, daß es Northfield überhaupt geben muß.) Hauptsache, das, was letztendlich übrig bleibt, landet früher oder später in Wayland.

Ach, jetzt auf einmal doch? Dafür gibt es aber keine Garantien, und es klingt nicht so, als seien die Entwickler überhaupt empfänglich dafür:

"These changes are actually being discussed on the mailing list for possible review and inclusion. Once these basic events/requests go upstream, there will not be a need for northfield as a patched version of wayland."

Ja, das ist sein frommer Wunsch. Dem wird im nächsten Posting gleich eine Absage erteilt.

Es geht mir nicht darum, ob diese blöden Desktopeffekte jetzt in Wayland/Weston landen, das ist mir ziemlich egal. Es ging mir darum, dass Entwickler sich keineswegs immer freuen, wenn man daherkommt und ihr Projekt "verbessern" oder "fixen" möchte.

Ok, einigen wir uns auf: Ich sehe hellgrau, wo du dunkelgrau siehst

*lach* ... Okay

P.S.: http://blogs.gnome.org/mclasen/2015/01/ ... e-endgame/

Ja ... dass die Gnome-Entwickler fleißig sind, das ist unbestritten. Aber da geht es lediglich um Gnome ... was mit den weiteren Unzulänglichkeiten in Wayland ist, das steht da auch nicht. Und je nach Entwicklungsgeschwindigkeit könnte das einen Zeitrahmen von zwei Jahren abdecken, bis Fedora 23. Mal abgesehen davon, dass die Gnome-Zukunftspläne bisher auch nicht gerade zuverlässig waren.

Nein, nur ein Schlußwort unter unseren Disput. Der Thread gehört ja nicht nur uns.

"Disput"? Ich sehe das eher als Austausch von Sichtweisen und Argumenten. Und bei dem hab ich mittlerweile mehr über Wayland gelernt, als ich jemals wissen wollte

Insofern ... vielen Dank für deinen eifrigen Widerspruch ... der hat mich viel zum Lesen und Recherchieren gebracht

P.S.: Nachdem ich mir bei Wikipedia mal die eigentliche Bedeutung des Wortes "Disput" durchgelesen habe, muss ich anfügen, dass das Wort doch sehr treffend ist

[owl102]

Du hast "Desktopeffekte" nur als "Mist" bezeichnet

Und du als "blöd".

Nein, ich sehe das wie du, ich sehe den Wunsch als sehr legitim an. Ich fand nur den Einstieg als unglücklich gewählt, zuerst ein Lobgesang auf Compiz (welches zumindest ich noch nie stabil erlebt habe), und dann den Wunsch, das in Weston haben zu wollen. Und Weston wird eben nicht als Spielwiese für sowas angesehen.

Ach, jetzt auf einmal doch? Dafür gibt es aber keine Garantien, und es klingt nicht so, als seien die Entwickler überhaupt empfänglich dafür:

Das war lediglich ein Wunschgedanke von mir, es kommt IMHO lediglich darauf an, daß das, was benötigt wird um ein Compiz für Wayland programmieren zu wollen, in Wayland landet und eben nicht nur in Northwood.

Ja, das ist sein frommer Wunsch. Dem wird im nächsten Posting gleich eine Absage erteilt.

Tja, da hätte ich wohl doch noch ein paar Beiträge weiter lesen sollen. Schade, diese Weiterentwicklung. Und bedauernswert.

Mal abgesehen davon, dass die Gnome-Zukunftspläne bisher auch nicht gerade zuverlässig waren.

Wem sagst du das... Aber immerhin war von Gnome-Version zu Version ein Fortschritt zu erkennen, wenn auch immer nicht so weit wie ursprünglich angepeilt.

Insofern ... vielen Dank für deinen eifrigen Widerspruch ... der hat mich viel zum Lesen und Recherchieren gebracht

Dito. Ich hatte gemerkt, daß ich bei so mancher Aussage doch auf dünnem Eis stand, als ich dann nach deinen Einwänden nachgelesen hatte. Vorher hatte ich nur Halbwissen über Wayland, jetzt immerhin 51/100-Wissen

[NAB]

Nein, ich sehe das wie du, ich sehe den Wunsch als sehr legitim an. Ich fand nur den Einstieg als unglücklich gewählt, zuerst ein Lobgesang auf Compiz (welches zumindest ich noch nie stabil erlebt habe), und dann den Wunsch, das in Weston haben zu wollen. Und Weston wird eben nicht als Spielwiese für sowas angesehen.

Ich finde es nun müßig, über den Sinn und Unsinn von Desktopeffekten in Weston zu diskutieren, zumal ich über die Interna keine Ahnung habe. Soweit ich das verstanden habe, ist der Entwickler auch dadurch aufgefallen, dass er "unfreundlich" war, und eventuell könnte man Zweifel an seiner Kompetenz haben.

Der interessantere Schluss daraus ist, dass man auch "freundlich" wirken muss, wenn man sich in ein fremdes Projekt einmischen will, und die dortigen Entwickler davon überzeugen muss, dass man kompetent ist.

Ich bin hier immer noch bei dem, was du auf der letzten Seite als "Das sind ganz normale Entwicklungsprozesse." bezeichnet hast (ja, ich weiß, das "normal" hast du inzwischen relativiert). Eigentlich ist es eher völlig ungewöhnlich, dass sich das eine Projekt (Gnome) in das andere Projekt (Wayland) einmischt, um es nach seinen Wünschen zu formen.

Das bedeutet zum einen, dass die Wayland-Entwickler eben nicht diese brilliante Weitsicht hatten, gleich ein vollwertig taugliches Protokoll hinzulegen (macht nix, scheint sich aber ganz schön zu ziehen), und zum anderen, dass Gnome mit seiner Finanzkraft im Rücken im Moment Wayland nach seinen Wünschen formen kann ... ob das so gut ist, das weiß ich nicht.

Wem sagst du das... Aber immerhin war von Gnome-Version zu Version ein Fortschritt zu erkennen, wenn auch immer nicht so weit wie ursprünglich angepeilt.

Du siehst hier nur Gnome (logisch, davon kann man wenigstens was sehen auf dem Desktop). Ich sehe die perverse Möglichkeit, dass Gnome irgendwann sagt "Okay, wir sind fertig", und es trotzdem nicht rund läuft, weil noch Teile in Wayland oder in Hardware-Treibern fehlen. Gut, auch darum dürften sich dann die RedHat-Entwickler kümmern ... aber das könnte sich noch mal ziehen ... (von Beispielen wie Firefox mal ganz zu schweigen)

Dann erst würde Wayland einen Zustand erreicht haben, den man subjektiv als "Version 1.0" bezeichnen könnte, und dann erst werden sich vermutlich andere Projekte (KDE & Qt, OpenGL) ernsthaft darum bemühen, die Portierung voranzutreiben. Das könnte sich noch ein paar Jährchen ziehen ...

[owl102]

https://www.youtube.com/watch?v=WZOnMfmoR-w#t=888

[Blackbox]

Um mal wieder etwas Schwung in diese Diskussion zu bringen, möchte ich meine Erkenntnisse hier loswerden.

Seit Debian Stable/Jessie ist es möglich das Paket xwayland [1] [2] zu installieren, der Wermutstropfen ist allerdings, dass noch keines der von mir getesteten Desktop Environment (DE) so richtig unterstützt wird.
Da ich persönlich LXDE und Xfce präferiere, habe ich natürlich auch, nur diese beiden DEs getestet.
Mir ist es zumindest nicht gelungen, in einer Minimalinstallation beide DEs zur Zusammenarbeit mit xWayland zu bewegen.
Als nächstes möchte ich es mal per debootstrap, bzw. grml-debootstrap versuchen.
Dieser Artikel soll andere Nutzer des Debianforums dazu anspornen, ebenfalls Tests mit dem von ihnen genutzten DE durchzuführen.
Ergebnisse, - so es welche geben wird - könnten dann in einem eigenen xWayland Thread, oder Wikiartikel niedergeschrieben werden.

Nachdem Fedora 22 Wayland für den Login benutzt und plant, mit Fedora 23 den Xserver gänzlich zu ersetzen, ist meine stille Hoffnung, dass Debian 9, einen wie auch immer aussehenden Wayland Support bietet.

[1] 38594

[2] 38595

[owl102]

Nachdem Fedora 22 Wayland für den Login benutzt

...was ich als Ergebnis nach 6 Monaten Entwicklung seit Fedora 21 etwas enttäuschend finde. Ich hatte mir da mehr erhofft.

Hinzu kommt, daß es bei vielen Anwendern auch nicht gebrauchsfähig funktioniert. (Bei mir auch nicht.)

Und nun zu etwas anderem, nämlich KDE: https://plus.google.com/+SebastianK%C3% ... U2mjJW9LJP

Edith: überarbeitet

[Blackbox]

Liebe Eule,

manchmal ist dein Visionsradius etwas eingeschränkt.
Dabei hast du den wichtigsten Teil meiner Nachricht unter den Tisch fallen lassen.
Fedora 22 hat xWayland deswegen erst einmal nur für den Login benutzt, um diese Schnittstelle zu testen und stabil zu machen.
Im zweiten Schritt mit Fedora 23 - welches in absehbarer Zeit released wird - soll das gesamte System unter xWayland laufen.
Wie wir sicherlich alle wissen, ist Fedora die Spielkiste - oder anders ausgedrückt, das Testlabor - von Red Hat.

Aber was soll ich soviel erklären, das hättest du auch bequem nachlesen können.

[1] http://www.pro-linux.de/-0h215758

[2] http://heise.de/-2664377

[3] http://www.golem.de/news/fedora-22-im-t ... 14660.html

Also beim nächsten Mal bitte, mehr auf die Fortschritte achten !
Denn im Gegensatz zu anderen Systemen, ändert sich bei Linux sehr viel unter der Haube - wir brauchen eben keine Kacheln, um aufzufallen

[GregorS]

... Video gesehen, ...

Gibt es den Film online? Wo?

TIA

Gregor

[scientific]

Irgendwo schon. Aber ich weiß echt nicht mehr wie der geheißen hat.
Entweder wars auf youtube oder im ccc-Videoarchiv (was ich eher glaube!)