4 ms·

> Not really Yes really. It makes no sense that every application has different non unified font rendering or rendering in general. Also things like kinetic sc

by sprash 5y ago

> Not really Yes really. It makes no sense that every application has different non unified font rendering or rendering in general. Also things like kinetic scrolling and all kinds of application behavior is now potentially completely different for different applications. It's a mess, we need standardized solutions and such a solution already exists: X11. > The fact that everyone is writing their own compositor is just another symptom of the ridiculous project-fragmentation that has always afflicted desktop linux. They could have cooperated and made a common compositor, but everyone had to build their own. The Linux community already has huge problems to agree on any standard at all and X11 is such a standard with a huge amount of support functionality. This is rare and should not be squandered. X11 is not pretty but the insistence on backwards compatibility led to a growth of a huge ecosystem (just count the numbers of Window managers). If anything I consider Wayland (and GNOME) a deliberate act of sabotage.

sho_hn 5y ago
> Yes really. It makes no sense that every application has different non unified font rendering or rendering in general. Also things like kinetic scrolling and all kinds of application behavior is now potentially completely different for different applications. It's a mess, we need standardized solutions and such a solution already exists: X11. A lot of this commentary just doesn't quite reflect reality, even if it's meant well. There's a lot of misunderstanding on what really is different now, or how things are different from other systems. - Font rasterization and text shaping in all major applications has normed on freetype and harfbuzz. - Kinetic scrolling/input event handling has (or is in the process of) normed on libinput. - This is true for X11-based systems as well! The X protocol historically does contain commands for server-side text rendering, but those haven't been used in decades - applications started moving to client-side rasterization ages ago, and the X server moved to using libinput (where its code originated, before then being intentionally moved out). - In competing systems such as Windows/MacOS, the situation is often the same or reflects the same tech trends. Often there are legacy server-side APIs to do things, but apps have long-sinced moved to newer library APIs. Often there's more than one way to do things (say, text rendering on Windows: Pick GDI or Direct2D) and the perceptual same-ness has just been achieved through effort of alignment. In fact it can actually be worse on other systems nowadays - native app development on Windows has really deteriorated and you can find many apps that just ship freetype/hardbuzz there (bundled with the cross-platform UI lib they picked) and don't match Windows font rendering. - The separation of duties between the windowing/compositing system and orthogonal library APIs is often the same. For example, in both iOS and Android the display server is not responsible for text rendering in any way. On Android the latter is done through freetype/harzbuzz as well. - Wayland compositors already share a lot of code in much the same way that X-based desktops did, e.g. by graphics drivers having moved out of the X server into the kernel and Mesa, and input having been moved to libinput.
md8z 5y ago
X11 is not really a viable solution anymore. The API has some pretty major flaws that there are no plans to fix. Or rather, the plan to fix them has been to ship Wayland as the new API. It should continue to be backwards compatible because of XWayland. Also I don't believe X11 has any API for kinetic scrolling, that typically is implemented by the desktop environment so I'm confused as to what you mean. "I consider Wayland (and GNOME) a deliberate act of sabotage." KDE is actually fully behind Wayland as well. It's not something that GNOME is doing just to inconvenience you. https://community.kde.org/KWin/Wayland#Why_Plasma_needs_Wayland.3F https://community.kde.org/KWin/Wayland#Why_Plasma_needs_Wayl...
- sprash 5y ago
  > X11 is not really a viable solution anymore. These are very unsubstantiated claims. X11 works perfectly. Wayland on the other hand is not a viable solution at all at this point. You can't even take screenshots. > The API has some pretty major flaws that there are no plans to fix. Except for the 15bit coordinate limitation it has no major flaws and can be extended if needed. If anything has major flaws it is Wayland. As an exercise I recommend implementing a native screenshot application on Wayland and compare that experience with the X11 equivalent. The Wayland API is pure garbage. > KDE is actually fully behind Wayland as well. Maybe in words only. The Actual Wayland version of KDE has major bugs and people doing serious work always switch back to the X11 session where it works flawlessly. Besides that I don't think KDE is any good either.
  - md8z 5y ago
    I'm using GNOME on Wayland and pressing the "Print Screen" key takes a screenshot so I'm not really sure what you're talking about, it would help if you could clarify. My experience developing screenshot/screencast/webcam applications on Wayland has been significantly better than it has been on X11. Using X11 APIs for those things is somewhat of a misuse and breaks in corner cases, as those APIs are only really safe to use by the window manager. Extending X11 is also a bad idea because that's just more things that have to get plumbed through Wayland/the X server/toolkits/libraries. Pipewire really makes it easy to use and convenient, you just use that and then you don't have to worry about messing with the lower levels of the stack. If you don't think KDE or GNOME are good then we have not much to talk about, there are no other viable open source desktop platforms on Linux. I certainly don't think they're free of flaws, but they are the best we've got.

by sprash 5y ago

sho_hn 5y ago

> Yes really. It makes no sense that every application has different non unified font rendering or rendering in general. Also things like kinetic scrolling and all kinds of application behavior is now potentially completely different for different applications. It's a mess, we need standardized solutions and such a solution already exists: X11. A lot of this commentary just doesn't quite reflect reality, even if it's meant well. There's a lot of misunderstanding on what really is different now, or how things are different from other systems. - Font rasterization and text shaping in all major applications has normed on freetype and harfbuzz. - Kinetic scrolling/input event handling has (or is in the process of) normed on libinput. - This is true for X11-based systems as well! The X protocol historically does contain commands for server-side text rendering, but those haven't been used in decades - applications started moving to client-side rasterization ages ago, and the X server moved to using libinput (where its code originated, before then being intentionally moved out). - In competing systems such as Windows/MacOS, the situation is often the same or reflects the same tech trends. Often there are legacy server-side APIs to do things, but apps have long-sinced moved to newer library APIs. Often there's more than one way to do things (say, text rendering on Windows: Pick GDI or Direct2D) and the perceptual same-ness has just been achieved through effort of alignment. In fact it can actually be worse on other systems nowadays - native app development on Windows has really deteriorated and you can find many apps that just ship freetype/hardbuzz there (bundled with the cross-platform UI lib they picked) and don't match Windows font rendering. - The separation of duties between the windowing/compositing system and orthogonal library APIs is often the same. For example, in both iOS and Android the display server is not responsible for text rendering in any way. On Android the latter is done through freetype/harzbuzz as well. - Wayland compositors already share a lot of code in much the same way that X-based desktops did, e.g. by graphics drivers having moved out of the X server into the kernel and Mesa, and input having been moved to libinput.

md8z 5y ago

X11 is not really a viable solution anymore. The API has some pretty major flaws that there are no plans to fix. Or rather, the plan to fix them has been to ship Wayland as the new API. It should continue to be backwards compatible because of XWayland. Also I don't believe X11 has any API for kinetic scrolling, that typically is implemented by the desktop environment so I'm confused as to what you mean. "I consider Wayland (and GNOME) a deliberate act of sabotage." KDE is actually fully behind Wayland as well. It's not something that GNOME is doing just to inconvenience you. https://community.kde.org/KWin/Wayland#Why_Plasma_needs_Wayland.3F https://community.kde.org/KWin/Wayland#Why_Plasma_needs_Wayl...

sprash 5y ago
> X11 is not really a viable solution anymore. These are very unsubstantiated claims. X11 works perfectly. Wayland on the other hand is not a viable solution at all at this point. You can't even take screenshots. > The API has some pretty major flaws that there are no plans to fix. Except for the 15bit coordinate limitation it has no major flaws and can be extended if needed. If anything has major flaws it is Wayland. As an exercise I recommend implementing a native screenshot application on Wayland and compare that experience with the X11 equivalent. The Wayland API is pure garbage. > KDE is actually fully behind Wayland as well. Maybe in words only. The Actual Wayland version of KDE has major bugs and people doing serious work always switch back to the X11 session where it works flawlessly. Besides that I don't think KDE is any good either.
- md8z 5y ago
  I'm using GNOME on Wayland and pressing the "Print Screen" key takes a screenshot so I'm not really sure what you're talking about, it would help if you could clarify. My experience developing screenshot/screencast/webcam applications on Wayland has been significantly better than it has been on X11. Using X11 APIs for those things is somewhat of a misuse and breaks in corner cases, as those APIs are only really safe to use by the window manager. Extending X11 is also a bad idea because that's just more things that have to get plumbed through Wayland/the X server/toolkits/libraries. Pipewire really makes it easy to use and convenient, you just use that and then you don't have to worry about messing with the lower levels of the stack. If you don't think KDE or GNOME are good then we have not much to talk about, there are no other viable open source desktop platforms on Linux. I certainly don't think they're free of flaws, but they are the best we've got.