Recently I have seen many comments by users in the style of “I’m looking forward to the first release of KDE5 because of Wayland”. With every time there is such a comment the chances are that it spreads that the first release of “KDE5” will support Wayland and will result in disappointment when the first release of something ends up on the users’ systems. Thus I decided to write a blog post with clarifications.
As my readers probably know there won’t be a combined release as the software compilation used to be. There are independent ongoing projects around the libraries (frameworks or KF5) the workspaces (Plasma Next) and the applications. These projects have independent release cycles and are not one product. I know, I know, many people will disagree and say that it’s still one. But if we go for this strong simplification both “will support Wayland” and “will not support Wayland” are true.
And thus we enter the area where it is important to make the distinction between the various products and use the correct name. Otherwise people don’t know what you are talking about and it results in confusion.
So let’s look into the different areas. As I have already explained our libraries are getting prepared for Wayland and the first release of KF5 will have Wayland support not on par with X11 support but certainly on par with Microsoft Windows or OS X support.
This means for applications using our frameworks that they will support Wayland as long as they don’t speak X11 directly.
For the workspaces it’s more complex. Our aim for the first release of Plasma Next has never been to fully support Wayland or do the migration to Wayland. We obviously don’t want to create too many construction sides and decided to concentrate on getting everything ported to Qt 5 first before going to Wayland. As we are entering the alpha release state shortly we can be quite certain that the Plasma desktop shell will not support Wayland. Other parts of Plasma Next have a little bit more integration, some systemsettings modules get hidden when running on Wayland, some modules got fixed to not crash, KInfoCenter got some improvements to support the OpenGL module on Wayland and got a new Wayland module. KWin is still in the experimental support stage not yet being a Wayland compositor. Here we might still have some improvements till the final release as Wayland specific code is excluded from the feature freeze. But overall we can quite certainly say that the first release of Plasma Next will not support Wayland.
While you and the KDE team keep your thumbs up your butt’s being reserved about being a wayland compositor, I’ll contine supporting and advocating Gnome3 & Cinnamon.
Nonetheless, thank you for he progress so far, please continue it AND bump it up to being a higher more direct priority soon.
@Eric:
So you came all the way down here to troll on KDE? Everywhere I go there are some gtk/gnome fanboys who have no idea what they are talking about. Go play with your crap toys (gnome or whatever you call it), you moron.
@Martin:
You are doing a great job. Keep up the good work. KF5 is one of the most exciting releases of KDE project
I think it’s OK to call out trolls. Insulting them (e.g. calling moron) is not OK. Even less OK is to say that GNOME is “crap toys”. Please show the same respect as you demand from others.
I didn’t mean to sound like a gtk fanboy… oh well lol. Martin, your content and progress is awesome and the more pregress I hear the better, I was just expressing being upset at the status update of such a clear cut “will not support Wayland”.
“KDE 5.1 will support Wayland” cit.
haha I’m sooo looking forward to KDE 5.1
KDE 5? Since when do you version us? ;P
That’s why it is in “”
Just kidding. Thank you all for the great work on KF5 and Plasma Next! 🙂
It’s hard for us users. We were sweet talked into Walyand years back and it’s like we are chasing that fantasy ever since.
Problematic part is there are still years ahead because none of the common DE support Walyand ATM to say it is fit as X11 replacement and because of that there is no real interest for app/driver (blob) developers to push the support hard.
I do not know but i think it is fair to say Wayland as a project is not managed all that well. Eventually we might get there but as it look like that is still distant future and i guess that could count as fail.
I would compare it to Tizen ATM it is here but in reality it is light years away.
Wayland as a project is doing fine and great. It’s not Wayland’s fault that users believed it’s easy to migrate away from X11.
“It’s not Wayland’s fault that users believed it’s easy to migrate away from X11.”
Migrating away from X11 did take few years yes this is true. But i do not believe the time spend on this task was only spend on technical level tasks. Probably not all share the same enthusiasm to move away from X11 in foreseeable future in the first place?
This is quite common effect i guess when something new wants to replace something old and not everybody see it like that and taking all this into account i guess it is normal Wayland did not replace X11 in any meaningful way in this past few years and i guess it is fair to say it will not do that for some years ahead.
It is not all bad i guess. If it would fail all together i still do believe X11 would be better or the next attempt to replace X11 would be more successful.
Well my enthusiasms toward Wayland is fading that much is true because years went by and not much (user vise) has happened but on the other hand at least there where a lot of effort to “rethink X11” and i guess this will make display server situation on Linux better in the future regardless of the name of the protocol used.
I still cross fingers for Wayland but as user not been able to use it for years in any meaningful form my enthusiasm did fade a bit.
Why do you as a user even care about whether you can use it or not? It’s nothing which will scream at you “now you are using Wayland!”. If the transition works as I intend, no user will ever notice that there was a switch underneath.
i am not agree with this part of your statement martin , animation ,… etc is so smoother in wayland ,for now you can test gnome shell in low-end pc , you should see , wayland is unlivable smooth , even in low-end device,(search a video about this in youtube).
maybe in high-end device user will not notice , but in low end device , user will see how much DE will run smoother and nicer.
*unbelievable
and as a user you notice that something works better? Congratulations you are the one in a million. Seriosuly a user shouldn’t notice and cannot notice unless one points them to it like having such a video.
maybe i am wrong
OpenGL renderer string: Mesa DRI Intel(R) 965GM
OpenGL version string: 2.1 Mesa 10.1.0
OpenGL shading language version string: 1.20
gnome-shell 3.10 works horribly slow, it’s useless
I switched to XFCE, I guess I will need to replace my laptop soon, these desktops nowdays with all that eye candy features are getting more and more demanding.
Just to make it clear: nobody forces you to run the latest software on old hardware. Feel free to stick with long term supported software.
I could write long answer but will instead try to write short one. I use Linux based OS for past few years for everything and i followed Xorg evolution and it improved greatly over the years BUT then Wayland came along and “promised” it will do few things better as i understood them:
Developers (apps) will be able to achieve more with less effort. They will be able to achieve things currently not possible with Xorg. GPU driver situation will improve and GPU vendors will be more motivated to provide quality GPU drivers because this will be easier for them. Supporting multi-gpu systems would not be a problem anymore. It would work in this way for desktop PC, smart phone or smart watch… and generally speaking more performance/security should be possible with Wayland.
Basically taking the knowledge gain working on Xorg and understanding modern needs would result in making modern protocol/display server that would satisfy modern needs.
Why do i care about that as a user? Well if it would go like that then i could buy multi-gpu hardware and it would work good under Linux and probably apps itself would improve in this regard and would provide better experience and developer would use less time to achieve that. This would be true for desktop and mobile devices. And yes performance benefit like that “no tearing” well how can user argue against that?
But the way i see it X11/Xorg after all this years is just as strong as it was and nothing is close to replacing it. It is like general consensus was X11/Xorg is not fit for modern needs we should do something about it but as it is not going anywhere anytime soon we should take all the time in the world to achieve this goal. Xorg is being developed/used just like it was in the past and Wayland is in a way “everywhere” but in the same time “nowhere”.
All that said i do not agree i am not affected by this as user and it makes no difference because if it would make no difference then why would Wayland be in development for all this years in the first place if X11/Xorg could satisfy modern needs. But in a way it is true X11/Xorg still has to do that today and it is still the definition of what is or is not modern on Linux ATM in this area. I have a filing quite a few interested parties like it like that (status quo).
Wayland is being developed largely by Xorg folks, so don’t worry about competition between Wayland and Xorg.
I do not see where does your answer fit in and what does it try to explain.
Thanks for the clarification and for creating realistic goals / release strategies!
Millions of people use wayland everyday on their setop box in france
http://qt-project.org/videos/watch/qt-and-qt-quick-on-the-freebox-player-set-top-box
ok to be fair it’s simplier than a desktop setup, but they launched it years ago.
Does KDE still use kpanel? If so, how do you plan to make this work as a native Wayland client, given that clients currently can’t access any information about other clients in the basic Wayland protocol?
What’s a “kpanel”?
I’m believing it is a reference to the now defunct kicker?
The idea is/was to have the compositor (in this case kwin) “bless” the desktop shell process and allow it access to such information.
For those confused about “kpanel”, that was the launcher (panel) in KDE1. It was replaced by kicker in KDE2 and remained until 3.5.10. Plasma eventually replaced that, but it uses the same library to access the window information, libtaskmanager, that kicker did (albeit with quite a few improvements in the years since).