Why KDE's KWin Doesn't Integrate Weston/QtCompositor For Wayland Support

[phoronix]

Phoronix: Why KDE's KWin Doesn't Integrate Weston/QtCompositor For Wayland Support

KDE developers have been porting their Plasma 5 + KDE Frameworks 5 stack over to Wayland, but at this point it's not nearly as mature as the GNOME Wayland support. As such, KDE developers have to fend off questions from time-to-time why they don't "just integrate QtCompositor" or the Weston library for speeding up their efforts...

http://www.phoronix.com/scan.php?pag...positor-Weston

[smitty3268]

And this in relity this is utter nosens, since it has not been a non issue for about the last 10 years or so.

It may vell be that C++ is harder to access for varius other languaeges, but the fact is that historically the Qt and KDE language bindings has had higer coverage and been more up to date than for example similar bindings for C like toolkits like Gtk and GNOME. Given that Qt is a far larger toolkit than Gtk too, it's a rather good indication C++ gives minimal problems.

It's actually not nonsense, because a number of the guys in Gnome (who would be the ones to use cross-desktop libs created by KDE) are fanatically anti-C++ and refuse to use anything which even touches it. So that really is something that causes a lot of stuff to be rewritten, for no good reason.

[Morty]

main problem is and always was their use of C++ and not many languages play well with it out of the box. this makes reusability much harder since in most cases you'd end up more time working things around than simply writing new one

And this in relity this is utter nosens, since it has not been a non issue for about the last 10 years or so.

It may vell be that C++ is harder to access for varius other languaeges, but the fact is that historically the Qt and KDE language bindings has had higer coverage and been more up to date than for example similar bindings for C like toolkits like Gtk and GNOME. Given that Qt is a far larger toolkit than Gtk too, it's a rather good indication C++ gives minimal problems.

[Pesho]

What a PITA it is with firewalls, to have to open a range of ports for it. Maybe Albert would consider a network change?

He didn't seem interested in improving this when I reported it here. And I'm not really motivated to fix it myself.

[Passso]

independant? The frameworks they are making is usable by any DE you want. They are building sofware that can be used by other project and DE, and these project might even contribute back.

It's contribution between multiple projects. independant? I say a leader!

I just feel that the gnome community is going in their bubble, not thinking about other projects.
Just look at what happened at KdeConnect, they rebuilt everything (the protocol) and they used the excuse "we didn't know other projects existed" and then they continued with their things...

I really hope thing will change and promote contribution and communication between project, even with GNOME and KDE.
It would be cool if we still have diversity without doing the same work 2 time.

How good you are! You start arguing while having the same view than me
I wrote "independant" because they prefer create their how stuff than using a generic/not fitted tool/library. OFC they make it open-source and easily re-usable so they bring massive code to all communities.

[justmy2cents]

independant? The frameworks they are making is usable by any DE you want. They are building sofware that can be used by other project and DE, and these project might even contribute back.

It's contribution between multiple projects. independant? I say a leader!

I just feel that the gnome community is going in their bubble, not thinking about other projects.
Just look at what happened at KdeConnect, they rebuilt everything (the protocol) and they used the excuse "we didn't know other projects existed" and then they continued with their things...

I really hope thing will change and promote contribution and communication between project, even with GNOME and KDE.
It would be cool if we still have diversity without doing the same work 2 time.

main problem is and always was their use of C++ and not many languages play well with it out of the box. this makes reusability much harder since in most cases you'd end up more time working things around than simply writing new one

[gilboa]

Beause it's better to reinvent the wheel.

At least bother to read the damn blog before trolling. How low can you get?

- Gilboa

[nanonyme]

The Martin's blog post explains the situation pretty well, there is nothing to add at the end.

About the Wayland WIP on SDDM, the project have seen an acceleration to make it shippable in F21( it was in 0.2 version at the time or such like that), but now the development seems be reduced maybe because that target has been reached...

Well, as is SDDM is an X11 DM. According to the Wayland port design it will never work like GDM that can serve both x11 and Wayland DE's but instead it will be Wayland only. So if you want to test some DE that did not go through Wayland port on the same machine as Plasma, you will have to use GDM.

[nanonyme]

What a PITA it is with firewalls, to have to open a range of ports for it. Maybe Albert would consider a network change?

Is it even meant to be used with other than localhost?

[jaxxed]

To be honest, KDEConnect's protocol is indeed very poorly designed (I say that as a KDE user and fanboy). It requires you to open a range of TCP ports on the desktop for the KDEConnect daemon, because each connected device talks to a different port. Which is of course a very lame architecture. Web servers are able to serve tens of thousands of clients on a single port (80 or 443), KDEConnect could have done the same.

What a PITA it is with firewalls, to have to open a range of ports for it. Maybe Albert would consider a network change?