Wayland 1.14 & Weston 3.0 Planned For Release Next Month

[phoronix]

Phoronix: Wayland 1.14 & Weston 3.0 Planned For Release Next Month

Bryce Harrington at Samsung OSG has laid out plans for releasing Wayland 1.14 and Weston 3.0 next month...

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

[Azpegath]

But what are the news?

[oleid]

> > >I'd like to discuss this. As it stands, we're around a week away from
> > >shipping an alpha, and feature freezing. At this point, we have
> > >already committed libweston breakage such that the SOVERSION has hit
> > >3. So far, we have nothing to offer for this breakage, just a bunch of
> > >bugfixes and a pile of cleanups and groundwork that will only become
> > >useful with future features.
> >
> > libwayland doesn't seem to have seen any interesting change either...

[ThanosApostolou]

I was once excited about Wayland, but seeing it in action I'm kinda disappointed.

The problems, in my opinion, are these:
1) There's no way to capture screen, so screen sharing in apps like hangouts,wire,skype can never happen.
2) No screen color temperature control so apps like redshift will never work.
3) Applications to control windows in a compositor-agnostic way like wmctrl,xdotool can never happen too.
4) Applications like gcolor3 cannot work either under Wayland.
Most of these maybe can be achieved using a specific Wayland Compositor (like Gnome's night light), but I'm talking about 3rd party applications, created by independent developers which need to work on all DE and compositors. The problem ofcourse isn't that these applications have not implemented YET, but they can NEVER be implemented the way Wayland and its compositors work.

Maybe someone should create an abstraction library (or something) which will provide functionality for all the above X11-style things. I'm thinking something which would provide APIs for those things and then detect the running Wayland Compositor on runtime and use it's specific APIs to implement those things. Or maybe since Wayland it's just a Protocol, then it should have API/Extensions/Standards for those things and then provide some conformance tests like opengl,vulkan do, which a Compositor would have to PASS in order to be called "Full Wayland Compositor". I don't know... but without something like this, I see more and more 3rd party developers loosing interest in linux applications.

I just wanted to share that. I don't have any professional knowledge over the subject, it's what I've understood so far by reading various articles about Wayland. If anyone can answer me and reassure me that these things can be somehow implemented I would be very glad, because I really hope that Wayland can be the future, I've just lost faith for now...

[Anvil]

IMO Wayland is sort of at a Dead End, personally i think 1 release a Year is better than 2, the developers arent getting enough done by releasing 2 a year

[dkasak]

I was once excited about Wayland, but seeing it in action I'm kinda disappointed.

The problems, in my opinion, are these:
1) There's no way to capture screen, so screen sharing in apps like hangouts,wire,skype can never happen.
2) No screen color temperature control so apps like redshift will never work.
3) Applications to control windows in a compositor-agnostic way like wmctrl,xdotool can never happen too.
4) Applications like gcolor3 cannot work either under Wayland.
Most of these maybe can be achieved using a specific Wayland Compositor (like Gnome's night light), but I'm talking about 3rd party applications, created by independent developers which need to work on all DE and compositors. The problem ofcourse isn't that these applications have not implemented YET, but they can NEVER be implemented the way Wayland and its compositors work.

Maybe someone should create an abstraction library (or something) which will provide functionality for all the above X11-style things. I'm thinking something which would provide APIs for those things and then detect the running Wayland Compositor on runtime and use it's specific APIs to implement those things. Or maybe since Wayland it's just a Protocol, then it should have API/Extensions/Standards for those things and then provide some conformance tests like opengl,vulkan do, which a Compositor would have to PASS in order to be called "Full Wayland Compositor". I don't know... but without something like this, I see more and more 3rd party developers loosing interest in linux applications.

I just wanted to share that. I don't have any professional knowledge over the subject, it's what I've understood so far by reading various articles about Wayland. If anyone can answer me and reassure me that these things can be somehow implemented I would be very glad, because I really hope that Wayland can be the future, I've just lost faith for now...

Those are some strange and esoteric requirements, with the exception of the 1st one ( I see you started out with your best ). There is no *current* way to do screen sharing, but implementing it is just a matter of coming up with a protocol. The way X allows anything to grab fullscreen pixmaps ( not to mention capture key strokes ) is pretty insecure, and one of the things that is obviously going to have to work differently under Wayland. As for the rest - meh - I've never wanted to do any of these, nor have I met anyone who's wanted to do any of these, nor do I expect to meet anyone who's wanted to do any of these. You already note that some wayland compositors have implemented the feature. Yet you want it done in a compositor-agnostic way? I don't see that happening, unless you want to run a nested compositor. Why don't you do that?

I'm guessing your post is actually a subtly crafted troll ...

[franglais125]

I'm guessing your post is actually a subtly crafted troll ...

It sounds pretty genuine to me. Someone criticizing a project for whatever reason (be it valid or not) is not automatically a troll.

From your point of view, perhaps some of the points are invalid or misguided, or you disagree entirely, but his post didn't go with "utter garbage". And he did hope for a nicer future for Wayland.

Also, at only 2 posts, he didn't exactly get a nice welcoming to the forums.

[Kemosabe]

I was once excited about Wayland, but seeing it in action I'm kinda disappointed.

The problems, in my opinion, are these:
1) There's no way to capture screen, so screen sharing in apps like hangouts,wire,skype can never happen.
2) No screen color temperature control so apps like redshift will never work.
3) Applications to control windows in a compositor-agnostic way like wmctrl,xdotool can never happen too.
4) Applications like gcolor3 cannot work either under Wayland.
Most of these maybe can be achieved using a specific Wayland Compositor (like Gnome's night light), but I'm talking about 3rd party applications, created by independent developers which need to work on all DE and compositors. The problem ofcourse isn't that these applications have not implemented YET, but they can NEVER be implemented the way Wayland and its compositors work.

Maybe someone should create an abstraction library (or something) which will provide functionality for all the above X11-style things. I'm thinking something which would provide APIs for those things and then detect the running Wayland Compositor on runtime and use it's specific APIs to implement those things. Or maybe since Wayland it's just a Protocol, then it should have API/Extensions/Standards for those things and then provide some conformance tests like opengl,vulkan do, which a Compositor would have to PASS in order to be called "Full Wayland Compositor". I don't know... but without something like this, I see more and more 3rd party developers loosing interest in linux applications.

I just wanted to share that. I don't have any professional knowledge over the subject, it's what I've understood so far by reading various articles about Wayland. If anyone can answer me and reassure me that these things can be somehow implemented I would be very glad, because I really hope that Wayland can be the future, I've just lost faith for now...

This does not really match my experience with wayland, which is just a protocol to communicate between client and server.
There are several additions, facilitated by "wl_interface" which allows to add more protocols. One very prominent one is xdg_shell, which lets you handle the wayland surfaces (clients) as windows with all its operations like minimze/resize ... Major GUI frameworks do even refuse to run on a "plain" wayland compositor which do not implement xdg_shell.
There is absolutely no reason to add more extensions to invalidate all your points assuming they don't exist yet. This can even include something like X11 forwarding replacement.

And btw, point 2 can work right now if the compositor itself simply implements this functionality. For hangouts, there might be another wl_interface necessary assuming your information is correct.

Welcome to the forum :-)

[Kemosabe]

Beginners, low educated and personal disorder people do name-calling. Too bad that is so typical in the Internet. I wonder do these people use the same language when not using computers.

Wayland was for reducing the maintenance work. Now they need to maintain two systems and hire more people. Very clever. X does run in raspberry pi and similar low end devices so there no any technical reasons to use wayland. Security problems are solved with 4G networks and firewalls.

So there is no reason that wayland and mir exist? Are all the developers "low educated and personal disorder people" too?

[Kemosabe]

Low educated people they are, in the university they teach to use existing software and not reinventing the wheel.

Well, software is like poetry. Most of it should have never been written. (This especially applies for academic stuff)
Nevertheless, Wayland is a big step forward.