| >There is no easy way to open a Window and render a string. Period! Yes, there is. Use a client library. That's what they're for. >You either need to write it yourself completely (as OP stated) or you can use Gtk/Qt or other heavy weight "client libraries" This is exactly the same as in X11. Remember Xlib is one of those heavy weight client libraries. The X11 example you showed uses Xlib. >Look at the code again! If you really think that the code at [1] is in any way a great solution as compared to [2] we are going to disagree. I don't think either of them are great. I'm saying that's comparing apples to oranges. >ZERO screenshot apps on X11 use XDG screenshot portal, they all use XGetImage(). They shouldn't. Like most parts of X11, XGetImage is an obsolete API. You don't want to use that in modern clients. >Mainly because the assumption that a dbus-daemon is always running everywhere is mostly false. No, dbus is used by basically all modern desktop environments on Linux. If you don't have dbus available you're going to have a lot more problems running normal Linux apps than just dealing with the differences between X11 and Wayland. >Also XDG screenshot portal is simply not a good solution. It is cumbersome to use, contains tons of edge-cases and pulls a dbus dependency for something that could be solved much simpler with onboard OS-functionality without the need for extra daemons and weird binary protocols X11 is also one of those weird binary protocols that isn't onboard OS-functionality and has more edge-cases, so according to this XGetImage isn't a good solution either. >Xft does server-side rendering via XRender. No, you've got rendering mixed up with compositing. With Xft, the rendering of font data to pixels is still done in the client. XRender, despite the name, is frequently only used to composite surfaces together. That's doing the same thing that Wayland is doing. |
How is obsolete and what makes XDG portal a better option?