Announcement

Collapse
No announcement yet.

Wayland 1.15 & Weston 4.0 Planning For Release Next Month

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

  • Wayland 1.15 & Weston 4.0 Planning For Release Next Month

    Phoronix: Wayland 1.15 & Weston 4.0 Planning For Release Next Month

    Ongoing Wayland/Weston release manager Bryce Harrington of Samsung's Open-Source Group has laid out plans for the next releases of Wayland and the reference Weston compositor...

    http://www.phoronix.com/scan.php?pag...-Release-Plans

  • #2
    this will be interesating to see if there's anything really Majorly New worth getting Excited for in 1.15

    Comment


    • #3
      Originally posted by Anvil View Post
      this will be interesating to see if there's anything really Majorly New worth getting Excited for in 1.15
      I hope it is a boring release, boring because there isn't any more need for exciting new features

      The exciting things should not be like plasma being ready for wayland by default (now that the gnome camp have theirs in prod for a year now), nvida pulling their finger out and getting the new GBM replacement implemented everywhere

      Comment


      • #4
        Originally posted by boxie View Post

        I hope it is a boring release, boring because there isn't any more need for exciting new features

        The exciting things should not be like plasma being ready for wayland by default (now that the gnome camp have theirs in prod for a year now), nvida pulling their finger out and getting the new GBM replacement implemented everywhere
        Wayland is nowhere of being up to scratch to really throw away x-server, i'd like to see Wayland releases being released once a Year, not this twice a year BS .

        Comment


        • #5
          Still no proposals for a unified way to get permission to access the compositors screen buffer for video recording, detect keypresses, redshift support etc?
          Wayland runs fine on my laptop, but I would never consider switching on my desktop until this is supported.

          Comment


          • #6
            Originally posted by johanb View Post
            Still no proposals for a unified way to get permission to access the compositors screen buffer for video recording, detect keypresses, redshift support etc?
            Wayland runs fine on my laptop, but I would never consider switching on my desktop until this is supported.
            redshift is supported. It's only that the compositor needs to support it. Kwin does: https://bugs.kde.org/show_bug.cgi?id=371494 (https://phabricator.kde.org/T4465)
            What does "detect keypresses" mean? if you mean "any application can listen to all input events" then that is inherently against what Wayland tries to accomplish. You might get *some* support from a compositor.
            I'll concede screen recording

            Comment


            • #7
              Originally posted by Serafean View Post

              redshift is supported. It's only that the compositor needs to support it. Kwin does: https://bugs.kde.org/show_bug.cgi?id=371494 (https://phabricator.kde.org/T4465)
              What does "detect keypresses" mean? if you mean "any application can listen to all input events" then that is inherently against what Wayland tries to accomplish. You might get *some* support from a compositor.
              I'll concede screen recording
              Redshift is not supported. KDE/Kwin has just implemented similar functionality. And re-implementing the features of other programs like that is expensive, so don't expect to see stuff like this done by smaller compositor projects.

              Detecting keypresses means, for example, that Mumble can respond to my push-to-talk key, or my media player can respond to media hotkeys, or my [custom app that does anything with hotkeys or other global input] can work. And I do want all of these things to work.

              Comment


              • #8
                Originally posted by Serafean View Post
                What does "detect keypresses" mean? if you mean "any application can listen to all input events" then that is inherently against what Wayland tries to accomplish. You might get *some* support from a compositor.
                I never mentioned it should be implemented in Wayland, I meant that we need some standardized way to talk to the compositor and request accesss for functionality so we don't have to reinvent all those features I mentioned for each compositor.

                Originally posted by Frogging101 View Post

                Redshift is not supported. KDE/Kwin has just implemented similar functionality. And re-implementing the features of other programs like that is expensive, so don't expect to see stuff like this done by smaller compositor projects.
                Exactly, gnome has the same feature implemented aswell and it's simply stupid that they all have to re-implement this for each compositor.

                Originally posted by Frogging101 View Post
                Detecting keypresses means, for example, that Mumble can respond to my push-to-talk key, or my media player can respond to media hotkeys, or my [custom app that does anything with hotkeys or other global input] can work. And I do want all of these things to work.
                That's a couple reasons I didn't think about, personally I thought about one of my sparetime projects activitywatch which looks at the currently focused window as well as mouse movement and keyboard presses to detect if the user is AFK or not and then displays a summary of which applications you use the most. It would also make the design of modular window managers similar to bspwm+sxhkd possible to work in wayland.

                Comment


                • #9
                  Originally posted by Frogging101 View Post
                  Detecting keypresses means, for example, that Mumble can respond to my push-to-talk key, or my media player can respond to media hotkeys, or my [custom app that does anything with hotkeys or other global input] can work. And I do want all of these things to work.
                  Ok, so you're talking about registering shortcuts in a standardized way.
                  However what happens when:
                  you register F5 for mumble, and firefox uses it to refresh its content. Does it go to both? Does only one get it? In KDE if you register a conflicting shortcut you get informed about it.
                  Reimplementing Redshift in the compositor makes a lot of sense. Why? Because the compositor has knowledge about windows, and could (theoretically) draw video players/ drawing applications without redshift enabled, while it is enabled for the rest. It also allows for easier interaction between different color changing features.

                  Comment


                  • #10
                    Originally posted by Anvil View Post
                    Wayland is nowhere of being up to scratch to really throw away x-server, i'd like to see Wayland releases being released once a Year, not this twice a year BS .
                    Wyaland still has ways to go in regards to X feature parity, but i guess it's come to a point where it's passable...
                    Personally, i prefer more frequent releases, even if it were like every three months, because it pushes things out earlier and testing can start earlier.

                    Comment

                    Working...
                    X