4 ms·

Yeah, I'm a big fan of systemd but I can accept that when it first came out it was probably a lot worse than it is today. Similarly, Wayland has a bunch of good

Yeah, I'm a big fan of systemd but I can accept that when it first came out it was probably a lot worse than it is today. Similarly, Wayland has a bunch of good ideas, along with a bunch of functionality that isn't there yet. Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing. I think systemd and Wayland are actually opposites in this regard, where systemd was disliked at first and then turned liked, while Wayland was liked at first but is now turning to disliked

vetinari 4y ago
> Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing Screensharing has been supported for some time already. Some apps support it, some don't. It is up to the apps to use the respective APIs, the times of free reign over framebuffer is over.
- mort96 4y ago
  I mean, you can get screen sharing to work. But there are like 3 different incompatible "standards" for how to do it. There's no single simple answer to "how to record the screen in Wayland". This has been the state of screen sharing on Wayland for at least 7 years. I'm also very curious about what's envisioned for global hotkeys. Surely we don't expect people to manually go to their system settings and configure some command to run which talks to Discord over an IPC solution to start sharing my voice when I press my push to talk button and stop when I release the push to talk button? But "global hotkeys should be configured on a system basis, not an application basis" seems to be the reigning philosophy, despite being incredibly user and developer hostile.
  - vetinari 4y ago
    There is one standard and single simple answer: xdg-desktop-portal with pipewire. Some compositors might have implemented their own private APIs, but that is not a standard by definition. Global shortcuts are a bit more thorny, exactly for the reason you mentioned. You present one POV, the another is, that application-defined shortcuts are incredibly hostile, as they allow application to stomp on each other in the better case, or hijaack global state in the worse one. Some other operating systems do not allow it either, for the same reasons. The long-term solution could be defining api, that allows application to advertise global actions, and allow the user to configure shortcuts that might (or might not) call these, in some user-friendly way.
    - mort96 4y ago
      Isn't xdg-desktop-portal a flatpak thing? It claims to be so here: https://github.com/flatpak/xdg-desktop-portal https://github.com/flatpak/xdg-desktop-portal > A portal frontend service for Flatpak and possibly other desktop containment frameworks. When it comes to global shortcuts, I'm not saying it has a super easy solution, but it's something that it's essential to support. Wayland intentionally doesn't, and I can't see that changing in the short term (as you also agree)
      - vetinari 4y ago
        It is dbus api, and is able to work cross-namespaces (i.e. flatpak containers too). There no harm in using it in non-flatpak apps, at least you will be ready if your app ends up in flatpak. Wrt global shortcuts, I see that there is some work done. The intentional part isn't malice, as in not willing to implement it at all. It is about not implementing temporary solution, that will be quick and dirty, and then being stuck for supporting it for next 50 years.
        Bjartr 4y ago
        So kind of like Go and generics in that regard
        nine_k 4y ago
        It took Golang 12 years to attain generics. Wayland is already 14 years old. To tell the truth, X11 took roughly 10 years (1986 to 1996) to get to a pretty usable, while pretty imperfect, state, and largely dominate Unix desktops.
  - nine_k 4y ago
    I don't see why a there cannot exist a daemon that handles these IPCs in a standard way (e.g. a pipe), and which can be politely asked by apps to map particular hotkeys. An API / UI should be available for the user to review and customize the mapping, and to resolve possible conflicts. This is basically the approach that exists in macOS for many years; I haven't heard a ton of criticisms towards it.
    - vetinari 4y ago
      The issue is being thought about (see https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/56 https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...), and then there is a problem with changing the existing habits. As you can see with screen capture, even if the api is available, but it will take years to adopt, with some intentionally dragging their feet -- it is different after all, and the old way worked for me, etc, etc. MacOS ecosystem moves much faster in this regard; mac users expect rapid adoption of new apis, and do not have 20+ years old bash scripts that should continue to work untouched.
- ilyt 4y ago
  > Screensharing has been supported for some time already. Some apps support it, some don't. It is up to the apps to use the respective APIs, the times of free reign over framebuffer is over. See, that's the problem, it's putting unnecessary load on everything else using it. It should have that API and it should have API that just allows dedicated app to allow/deny permissions to use that API. Not put everything on WM to duplicated more and more code for no good reason and making WM developer harder
chimeracoder 4y ago
> Yeah, I'm a big fan of systemd but I can accept that when it first came out it was probably a lot worse than it is today. The first "large" distro to switch from sysvinit to systemd was Arch, and that switch happened over ten years ago. The switch itself was quite rocky (the upgrade path was not particularly seamless, and while Arch users tend to be more tolerant of that sort of thing, it's worth mentioning). That said, even in 2012-2013, the end result once you completed the upgrade was significantly better than collectively expected. The original plan was to support both systemd and sysvinit (at least for a period of time), but that was quickly abandoned because not enough people wanted to actually maintain sysvinit packages, so support[0] ended up getting dropped very quickly. [0] Arch is a community project, so "support" is different from what you'd expect in (e.g.) RHEL, but it still has separations of what's considered supported and what's not.
- Conan_Kudo 4y ago
  > The first "large" distro to switch from sysvinit to systemd was Arch No. In terms of released to users, the first was Fedora; the second was Arch; then Mageia; then openSUSE. In terms of integrated into the distribution, the first was Fedora; the second was Mageia; then openSUSE; then Arch. Cf. https://en.wikipedia.org/wiki/Systemd#Adoption https://en.wikipedia.org/wiki/Systemd#Adoption
duskwuff 4y ago
> Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing... Screen sharing was always a weak point in X11, actually. VNC servers like x11vnc use absurd, inefficient hacks like periodically capturing fragments of the screen and checking for changes [1] -- while an extension to provide change notifications exists, it's been unreliable for ages [2] and the standard advice is to disable it. [1]: https://github.com/LibVNC/x11vnc#algorithm https://github.com/LibVNC/x11vnc#algorithm [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815909 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815909

vetinari 4y ago

> Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing Screensharing has been supported for some time already. Some apps support it, some don't. It is up to the apps to use the respective APIs, the times of free reign over framebuffer is over.

mort96 4y ago
I mean, you can get screen sharing to work. But there are like 3 different incompatible "standards" for how to do it. There's no single simple answer to "how to record the screen in Wayland". This has been the state of screen sharing on Wayland for at least 7 years. I'm also very curious about what's envisioned for global hotkeys. Surely we don't expect people to manually go to their system settings and configure some command to run which talks to Discord over an IPC solution to start sharing my voice when I press my push to talk button and stop when I release the push to talk button? But "global hotkeys should be configured on a system basis, not an application basis" seems to be the reigning philosophy, despite being incredibly user and developer hostile.
- vetinari 4y ago
  There is one standard and single simple answer: xdg-desktop-portal with pipewire. Some compositors might have implemented their own private APIs, but that is not a standard by definition. Global shortcuts are a bit more thorny, exactly for the reason you mentioned. You present one POV, the another is, that application-defined shortcuts are incredibly hostile, as they allow application to stomp on each other in the better case, or hijaack global state in the worse one. Some other operating systems do not allow it either, for the same reasons. The long-term solution could be defining api, that allows application to advertise global actions, and allow the user to configure shortcuts that might (or might not) call these, in some user-friendly way.
  - mort96 4y ago
    Isn't xdg-desktop-portal a flatpak thing? It claims to be so here: https://github.com/flatpak/xdg-desktop-portal https://github.com/flatpak/xdg-desktop-portal > A portal frontend service for Flatpak and possibly other desktop containment frameworks. When it comes to global shortcuts, I'm not saying it has a super easy solution, but it's something that it's essential to support. Wayland intentionally doesn't, and I can't see that changing in the short term (as you also agree)
    - vetinari 4y ago
      It is dbus api, and is able to work cross-namespaces (i.e. flatpak containers too). There no harm in using it in non-flatpak apps, at least you will be ready if your app ends up in flatpak. Wrt global shortcuts, I see that there is some work done. The intentional part isn't malice, as in not willing to implement it at all. It is about not implementing temporary solution, that will be quick and dirty, and then being stuck for supporting it for next 50 years.
      - Bjartr 4y ago
        So kind of like Go and generics in that regard
        nine_k 4y ago
        It took Golang 12 years to attain generics. Wayland is already 14 years old. To tell the truth, X11 took roughly 10 years (1986 to 1996) to get to a pretty usable, while pretty imperfect, state, and largely dominate Unix desktops.
- nine_k 4y ago
  I don't see why a there cannot exist a daemon that handles these IPCs in a standard way (e.g. a pipe), and which can be politely asked by apps to map particular hotkeys. An API / UI should be available for the user to review and customize the mapping, and to resolve possible conflicts. This is basically the approach that exists in macOS for many years; I haven't heard a ton of criticisms towards it.
  - vetinari 4y ago
    The issue is being thought about (see https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_requests/56 https://gitlab.freedesktop.org/xdg/xdg-specs/-/merge_request...), and then there is a problem with changing the existing habits. As you can see with screen capture, even if the api is available, but it will take years to adopt, with some intentionally dragging their feet -- it is different after all, and the old way worked for me, etc, etc. MacOS ecosystem moves much faster in this regard; mac users expect rapid adoption of new apis, and do not have 20+ years old bash scripts that should continue to work untouched.
ilyt 4y ago
> Screensharing has been supported for some time already. Some apps support it, some don't. It is up to the apps to use the respective APIs, the times of free reign over framebuffer is over. See, that's the problem, it's putting unnecessary load on everything else using it. It should have that API and it should have API that just allows dedicated app to allow/deny permissions to use that API. Not put everything on WM to duplicated more and more code for no good reason and making WM developer harder

chimeracoder 4y ago

> Yeah, I'm a big fan of systemd but I can accept that when it first came out it was probably a lot worse than it is today. The first "large" distro to switch from sysvinit to systemd was Arch, and that switch happened over ten years ago. The switch itself was quite rocky (the upgrade path was not particularly seamless, and while Arch users tend to be more tolerant of that sort of thing, it's worth mentioning). That said, even in 2012-2013, the end result once you completed the upgrade was significantly better than collectively expected. The original plan was to support both systemd and sysvinit (at least for a period of time), but that was quickly abandoned because not enough people wanted to actually maintain sysvinit packages, so support[0] ended up getting dropped very quickly. [0] Arch is a community project, so "support" is different from what you'd expect in (e.g.) RHEL, but it still has separations of what's considered supported and what's not.

Conan_Kudo 4y ago
> The first "large" distro to switch from sysvinit to systemd was Arch No. In terms of released to users, the first was Fedora; the second was Arch; then Mageia; then openSUSE. In terms of integrated into the distribution, the first was Fedora; the second was Mageia; then openSUSE; then Arch. Cf. https://en.wikipedia.org/wiki/Systemd#Adoption https://en.wikipedia.org/wiki/Systemd#Adoption

duskwuff 4y ago

> Of course, Wayland also has the problem that it's intentionally excluding some useful features that X had, like global hotkeys and screensharing... Screen sharing was always a weak point in X11, actually. VNC servers like x11vnc use absurd, inefficient hacks like periodically capturing fragments of the screen and checking for changes [1] -- while an extension to provide change notifications exists, it's been unreliable for ages [2] and the standard advice is to disable it. [1]: https://github.com/LibVNC/x11vnc#algorithm https://github.com/LibVNC/x11vnc#algorithm [2]: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815909 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=815909