Login
Newsletter
Werbung

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

15 Kommentar(e) || Alle anzeigen ||  RSS
Kommentare von Lesern spiegeln nicht unbedingt die Meinung der Redaktion wider.
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 ]
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung