Wayland 1.15 & Weston 4.0 Planning For Release Next Month

[phoronix]

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?page=news_item&px=Wayland-1.15-Release-Plans

[Anvil]

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

[boxie]

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

[Anvil]

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 .

[johanb]

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.

[Serafean]

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

[Frogging101]

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.

[johanb]

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.

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.

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.

[Serafean]

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.

[nomadewolf]

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.