X.Org Server 21.1 Will Aim To Release In The Coming Weeks

[arQon]

I wonder if asking which wayland compositor should replace X is a better way to stir things up.

heh.
I know you're kidding, but the answer to that SHOULD have been "the one developed by the Wayland team as part of the job of replacing X". But instead, they abandoned the responsibility (which I suppose you could argue is a good thing, since they haven't even delivered the pieces they DID try to write) and pushed that off onto other people instead.

I expect we'll end up with "gtk-weston", "kde-weston", etc (regardless of what the real names are), if we aren't there already, and those will become less and less compatible as time goes by and each group decides to create their own extensions. (If history is any guide, GNOME will implement their take on something, publish it on FDO, pretend it's a standard, and then break compatibillity with it themselves a year later and just ignore any complaints from KDE etc). Instead of programs written for DE1 just looking a bit crappy on DE2, they simply won't run at all. Good times...

> And I don't know too much about linux software dev, but for the sake of convenience, could a compositor be written into systemd as some kind of "composed?"

I'm sure they'll get to it someday.

[arQon]

I've never seen a program segfault because X crashes

Don't worry: you'll never see it when Wayland crashes either. Because it'll take your entire session with it.

[mppix]

heh.
I know you're kidding, but the answer to that SHOULD have been "the one developed by the Wayland team as part of the job of replacing X". But instead, they abandoned the responsibility (which I suppose you could argue is a good thing, since they haven't even delivered the pieces they DID try to write) and pushed that off onto other people instead.

I expect we'll end up with "gtk-weston", "kde-weston", etc (regardless of what the real names are), if we aren't there already, and those will become less and less compatible as time goes by and each group decides to create their own extensions. (If history is any guide, GNOME will implement their take on something, publish it on FDO, pretend it's a standard, and then break compatibillity with it themselves a year later and just ignore any complaints from KDE etc). Instead of programs written for DE1 just looking a bit crappy on DE2, they simply won't run at all. Good times...

> And I don't know too much about linux software dev, but for the sake of convenience, could a compositor be written into systemd as some kind of "composed?"

I'm sure they'll get to it someday.

Just a few notes
(i) the Wayland team = the Xorg team
(ii) X11 (the protocol) had many implementations with Xfree and Xorg being the later ones
(iii) Weston is a fully functional reference implementation of the Wayland protocol, you can use it for your DE. wlroots has seen wider adoption and as a consequence more optimizations than Weston. Hence, it is likely a more promising candidate for wider adoption. There is already a KDE/KWin spin using it called KWinFT
(iv) Compatibility between DEs is handled by the GUI frameworks in Wayland AND X11 (the times when X11 was the gui framework are long gone). There are no significant compatibility issues between Gnome Wayland or sway. KDE may still have issues but this is mostly because they are late.
I hope KDE can eventually pull it off. Otherwise, they should just adopt the wlroots. This is ok and KDE has precedent with depending on 3rd party software for core functionality, e.g. Qt.

[binarybanana]

This discussion was in the context of distributions. At least deb and rpm will not allow you to ship your java version with your application..
I know this is a long thread so this is probably buried pages ago..

Of course it does, if you really want to. What do you think is stopping you from bundling your own Java in a deb? All you have to do is make sure you're not creating conflicts wrt the dependency graph, or confusing the packageanager some other way. You do this by not declaring anything about Java in the deb (because it's an internal implentatioe detail and not for general use) and making sure you don't create file conflicts (store in /opt with unique suffix or wherever you prefer).

What you can't do is say you depend on this or provide that, other than your own packages. You certainly could have a (even optional) foo-javadep, foo-bardep, etc., but anything distro provided is a moving target.

[mppix]

Of course it does, if you really want to. What do you think is stopping you from bundling your own Java in a deb? All you have to do is make sure you're not creating conflicts wrt the dependency graph, or confusing the packageanager some other way. You do this by not declaring anything about Java in the deb (because it's an internal implentatioe detail and not for general use) and making sure you don't create file conflicts (store in /opt with unique suffix or wherever you prefer).

What you can't do is say you depend on this or provide that, other than your own packages. You certainly could have a (even optional) foo-javadep, foo-bardep, etc., but anything distro provided is a moving target.

I think we are saying the same/similar thing. While it may be possible in theory, you cannot easily ship your desired openjdk/openjre (or compiler, or GUI toolkit) version simply because it is not in the tree and still comply with the package requirements.
This is what flatpak solves.. (plus additional things).

[tildearrow]

Of course it does, if you really want to. What do you think is stopping you from bundling your own Java in a deb? All you have to do is make sure you're not creating conflicts wrt the dependency graph, or confusing the packageanager some other way. You do this by not declaring anything about Java in the deb (because it's an internal implentatioe detail and not for general use) and making sure you don't create file conflicts (store in /opt with unique suffix or wherever you prefer).

What you can't do is say you depend on this or provide that, other than your own packages. You certainly could have a (even optional) foo-javadep, foo-bardep, etc., but anything distro provided is a moving target.

I personally set /opt to access permissions 777 and use it to install user software.

[ssokolow]

(i) the Wayland team = the Xorg team

This. They're on record saying that it's called Wayland because they didn't want even more complaints about how "X12" shouldn't be so different from "X11".

[SciK]

Hi mdedetrich,
I think you stated similar things in the past.
Can you explain what the missing/to be ironed out 'use cases for Wayland' are?
Thanks!

The lack of support for any kind of color management instantly rules it out for any half-serious visual work.

See the discussion here: https://discuss.pixls.us/t/wayland-c...nagement/10804

[oiaohm]

The lack of support for any kind of color management instantly rules it out for any half-serious visual work.

See the discussion here: https://discuss.pixls.us/t/wayland-c...nagement/10804

That old.

https://www.collabora.com/news-and-blog/blog/2020/11/19/developing-wayland-color-management-and-high-dynamic-range/

https://gitlab.freedesktop.org/wayland/wayland-protocols/-/merge_requests/14

Yes it gone though revisions since then some of it has been low level driver work.

Color management is turn into a total horrible problem. 2017 proposal is missing how to deal with HDR. Yes HDR support has brought quite a few levels of complexity.