Announcement

Collapse
No announcement yet.

GNOME Rolls Out The GTK Text Input Protocol For Wayland

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • GNOME Rolls Out The GTK Text Input Protocol For Wayland

    Phoronix: GNOME Rolls Out The GTK Text Input Protocol For Wayland

    GNOME developers have been working on a new Wayland protocol, the "gtk_text_input" protocol, which now is implemented in their Mutter compositor...

    http://www.phoronix.com/scan.php?pag...TK-Input-Proto

  • #2
    Wouldn't this be considered fragmentation? You're going to have a Wayland desktop in which some apps may or may not work with some display servers.

    Comment


    • #3
      Originally posted by bregma View Post
      Wouldn't this be considered fragmentation? You're going to have a Wayland desktop in which some apps may or may not work with some display servers.
      Don't let the RedHat/Gnome apologists hear you.

      Comment


      • #4
        The commit message says it is internal only. It should have no impact on any software other than a compositor using Mutter (such as gnome-shell) which will by my understanding have the ability to redirect some keyboard events away from applications.

        The applications though will continue to work and work in all environments as those keyboard events will not be targetted at them.

        Comment


        • #5
          Originally posted by You- View Post
          The commit message says it is internal only. It should have no impact on any software other than a compositor using Mutter (such as gnome-shell) which will by my understanding have the ability to redirect some keyboard events away from applications.

          The applications though will continue to work and work in all environments as those keyboard events will not be targetted at them.
          Any protocol that's non-standard is inherently a form of fragmentation. The decision not to invent a whole new DSL to paper over Qt/GTK differences to standardize panel widgets between KDE 3.x and GNOME 2.x was a form of fragmentation.

          It's just a question of whether the parts being reinvented are worth unifying. (eg. In Firefox, NPAPI is already a standard, so it didn't make sense to standardize the protocol connecting plugin processes to the rest of the browser.)

          In this case, it has to do with communication between clients and input methods, so I'm assuming that, by "internal", they mean "experimental unstable API we're implementing in Mutter and GTK+ to try to discover any design warts".

          Comment


          • #6
            Originally posted by You- View Post
            The commit message says it is internal only. It should have no impact on any software other than a compositor using Mutter (such as gnome-shell) which will by my understanding have the ability to redirect some keyboard events away from applications.

            The applications though will continue to work and work in all environments as those keyboard events will not be targetted at them.
            So, I open an input method, type in my characters, and only Gnome apps will receive them because the IM protocol is internal to Mutter and Gnome apps, so other de jure standard Wayland apps will not receive the input because it's not targeted at them? Or does it mean I can't use IMs or OSKs on a Mutter-based desktop, tablet, or phone if I don't maintain purity of Gnomish essence in my selection of applications?

            The Gnome project has a long, long history of agreeing to de jure standards and then not following them because they were not invented here. Why should they change their habits now? Embrace and extend, brothers and sisters.

            Comment


            • #7
              Originally posted by bregma View Post
              Wouldn't this be considered fragmentation? You're going to have a Wayland desktop in which some apps may or may not work with some display servers.
              This is why the whole "Mir causes fragmentation" was nonsense

              Comment


              • #8
                Originally posted by Up123 View Post

                This is why the whole "Mir causes fragmentation" was nonsense
                That was no nonsense. Mir fragmented the graphics stack at the most fundamental level because it required both its own patched drivers and patched Mesa. DDX drivers and X even had to be patched so that XMir could be possible. And upstream would never carry these patches, so it was Ubuntu vs the rest of Linux. Which means that users are at the mercy of Canonical if they wanted drivers, xserver and Mesa versions greater than what Ubuntu was carrying in its repositories because they would not work on Mir without extensive patching.

                None of the whole Mir vs Wayland would ever had happened if Mir was designed as a Wayland compositor right from the beginning, instead of doing its own thing. Even with this new GTK and Gnome-exclusive protocol, the graphics stack remains untouched; the same upstream drivers and Mesa still work and will continue to work across all Wayland compositors, from Mutter to KWin and Weston and the new Mir-Wayland compositor.

                Comment


                • #9
                  What is the process for generation of new Wayland protocols? Isn't it something that people just start, and then various groups refine and refactor them as they want; if they become popular enough then they are standardized.

                  OSS in it's newest form is my about a sngle global council, but rather it is a fast paced startup process, where the fittest elements go on to be adopted in new stakeholder groups.

                  Comment


                  • #10
                    Originally posted by bregma View Post
                    Wouldn't this be considered fragmentation? You're going to have a Wayland desktop in which some apps may or may not work with some display servers.
                    What are you complaining? Fragmentation is what Linux is all about..

                    Comment

                    Working...
                    X