Login
Newsletter
Werbung

Thema: Gräßlin: Wayland-Unterstützung in KWin nach vier Jahren

35 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
1
Von göööb am Di, 30. Juni 2015 um 15:14 #

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.

[
| Versenden | Drucken ]
  • 1
    Von Le C am Di, 30. Juni 2015 um 21:32 #

    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)

    [
    | Versenden | Drucken ]
    1
    Von 1ras am Mi, 1. Juli 2015 um 13:42 #

    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.

    [
    | Versenden | Drucken ]
    • 0
      Von schmidicom am Mi, 1. Juli 2015 um 13:46 #

      Das an all diesen "Nachteilen" Walyland schuld sein soll bezweifle ich dann doch sehr...

      [
      | Versenden | Drucken ]
      • 1
        Von 1ras am Mi, 1. Juli 2015 um 14:01 #

        Das Konzept auf den Fenstermanager zu verzichten stammt nunmal aus der Wayland-Ecke.

        [
        | Versenden | Drucken ]
        • 1
          Von krake am Mi, 1. Juli 2015 um 18:21 #

          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.

          [
          | Versenden | Drucken ]
          • 1
            Von 1ras am Mi, 1. Juli 2015 um 19:30 #

            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.

            [
            | Versenden | Drucken ]
            • 1
              Von mgraesslin am Do, 2. Juli 2015 um 08:36 #

              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!

              [
              | Versenden | Drucken ]
              • 1
                Von 1ras am Do, 2. Juli 2015 um 12:08 #

                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.

                [
                | Versenden | Drucken ]
      1
      Von mgraesslin am Mi, 1. Juli 2015 um 14:46 #

      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.

      [
      | Versenden | Drucken ]
      • 1
        Von 1ras am Mi, 1. Juli 2015 um 15:17 #

        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.

        [
        | Versenden | Drucken ]
        • 1
          Von mgraesslin am Mi, 1. Juli 2015 um 17:05 #

          Nicht die Referenzimplementierung von Wayland, sondern die Referenzimplementierung für einen Wayland compositor. Ein kleiner aber in diesem Fall feiner Unterschied.

          [
          | Versenden | Drucken ]
          • 1
            Von 1ras am Mi, 1. Juli 2015 um 17:41 #

            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.
            [
            | Versenden | Drucken ]
            • 1
              Von krake am Mi, 1. Juli 2015 um 18:27 #

              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.

              [
              | Versenden | Drucken ]
              • 1
                Von 1ras am Mi, 1. Juli 2015 um 18:57 #

                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.

                [
                | Versenden | Drucken ]
                • 1
                  Von krake am Do, 2. Juli 2015 um 11:10 #

                  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.

                  [
                  | Versenden | Drucken ]
                  • 1
                    Von 1ras am Do, 2. Juli 2015 um 13:32 #

                    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.

                    [
                    | Versenden | Drucken ]
                    • 1
                      Von krake am Do, 2. Juli 2015 um 14:18 #

                      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.

                      [
                      | Versenden | Drucken ]
                      • 1
                        Von 1ras am Do, 2. Juli 2015 um 15:05 #

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

                        [
                        | Versenden | Drucken ]
                        • 1
                          Von krake am Do, 2. Juli 2015 um 15:44 #

                          Der klassische Fenstermanager ist unter X11 ein eigenständiges Programm

                          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.

                          [
                          | Versenden | Drucken ]
                      1
                      Von mgraesslin am Do, 2. Juli 2015 um 14:19 #

                      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!

                      [
                      | Versenden | Drucken ]
                      • 1
                        Von 1ras am Do, 2. Juli 2015 um 15:31 #

                        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.
                        [
                        | Versenden | Drucken ]
                        • 1
                          Von mgraesslin am Do, 2. Juli 2015 um 15:54 #

                          OK, das ist für mich beides die Fensterdeko.

                          [
                          | Versenden | Drucken ]
                          • 1
                            Von 1ras am Fr, 3. Juli 2015 um 12:05 #

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

                            [
                            | Versenden | Drucken ]
                            • 0
                              Von mgraesslin am Fr, 3. Juli 2015 um 14:20 #

                              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.

                              [
                              | Versenden | Drucken ]
                              • 0
                                Von 1ras am Fr, 3. Juli 2015 um 15:31 #

                                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.

                                [
                                | Versenden | Drucken ]
                                • 0
                                  Von mgraesslin am Fr, 3. Juli 2015 um 15:57 #

                                  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.

                                  [
                                  | Versenden | Drucken ]
                                  • 0
                                    Von 1ras am Fr, 3. Juli 2015 um 19:20 #

                                    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.

                                    [
                                    | Versenden | Drucken ]
                                    • 0
                                      Von mgraesslin am Fr, 3. Juli 2015 um 19:48 #

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

                                      [
                                      | Versenden | Drucken ]
              1
              Von göööb am Mi, 1. Juli 2015 um 21:50 #

              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.

              [
              | Versenden | Drucken ]
              • 1
                Von 1ras am Do, 2. Juli 2015 um 00:42 #

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

                [
                | Versenden | Drucken ]
                • 1
                  Von göööb am Do, 2. Juli 2015 um 07:08 #

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

                  [
                  | Versenden | Drucken ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung