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