3 ms·

Was X11 any different in practice? Apart from ancient legacy stuff like XTerm. It would be like writing a Mac application in Quartz directly.

by simonh 7mo ago

deleted 7mo ago
[deleted]
sprash 7mo ago
It was/is mostly the same practice except for the cases where it really counts. Window managers in general, xdotool, all kinds of input mapping and automation or the fact that you can write a screenshot tool in less than 500 LOC are only possible if you talk to X directly. And there the possibilities are almost limitless. And thanks to the xcb library it's actually somewhat convenient to use. Also certain types of power tools for mac probably need use Quartz directly as well.
- hparadiz 7mo ago
  Having written a new gtk program recently I had to implement Wayland and X -isms in the code. Off the top of my head X prefers using W_Class and Wayland prefers app-id with each window having a role set. Both are fine. I honestly think Wayland is nicer but realistically you code for both. To get a global hot key you register it with the compositor and it works. But you can run a background daemon to catch all keys if you really want.
- kelnos 7mo ago
  > Window managers in general, xdotool, all kinds of input mapping and automation or the fact that you can write a screenshot tool in less than 500 LOC are only possible if you talk to X directly. Honestly I think this is a pretty fair approximation of "no one". How many people are writing tools like this vs. the number of people writing regular applications? A very small number, I'd say. And after working extensively with both libX11/libxcb and libwayland-client directly, I can say that none of them are particularly pleasant to work with. Actually, no, that's not true: libwayland-client wins, easily. Every single Wayland protocol has code generated for it that works exactly the same way. I suppose the same is (more or less) true of libxcb, but libX11 (and all the other libraries you might have to use, like libXrender, libXrandr, libXext...) are a complete mess. And even then, libwayland-client has a much lower number of concepts you have to understand than libxcb does, simply because the Wayland protocol has a small number of concepts you need to understand. libxcb is definitely an improvement over libX11, but it can't magically make all the underlying X11 protocol concepts become unified.
- gf000 7mo ago
  And why should we optimize for "how many locs can I write a screenshot tool in"? I would prefer to having 1-2 decent ones that have all the necessary features and call it a day. They can then have a simple API so you can script whatever you want. Why would I want to add more complexity to a display server?
flohofwoe 7mo ago
Creating a window and Vulkan context and receiving input events (e.g. what game-like applications need) is fairly trivial via Xlib but far worse in Wayland. The Xlib API also sucks compared to Win32 or Cocoa, but writing a Wayland client for something as trivial as creating and managing a window is much worse than on any other platform (see: https://www.p4m.dev/posts/29/index.html https://www.p4m.dev/posts/29/index.html)
- gf000 7mo ago
  That's what stuff like SDL meant to abstract away.
  - flohofwoe 7mo ago
    Sure, but SDL can also only do so much to plaster over missing or optional Wayland features: https://wiki.libsdl.org/SDL3/README-wayland https://wiki.libsdl.org/SDL3/README-wayland Basic window system functionality really needs to be provided by the OS, not by 3rd-party libraries. And there's no reason why simple things like creating a window should be drastically more code in an OS API than in a wrapper library like SDL.

Was X11 any different in practice? Apart from ancient legacy stuff like XTerm. It would be like writing a Mac application in Quartz directly.

by simonh 7mo ago

Was X11 any different in practice? Apart from ancient legacy stuff like XTerm. It would be like writing a Mac application in Quartz directly.

deleted 7mo ago

[deleted]

sprash 7mo ago

It was/is mostly the same practice except for the cases where it really counts. Window managers in general, xdotool, all kinds of input mapping and automation or the fact that you can write a screenshot tool in less than 500 LOC are only possible if you talk to X directly. And there the possibilities are almost limitless. And thanks to the xcb library it's actually somewhat convenient to use. Also certain types of power tools for mac probably need use Quartz directly as well.

hparadiz 7mo ago
Having written a new gtk program recently I had to implement Wayland and X -isms in the code. Off the top of my head X prefers using W_Class and Wayland prefers app-id with each window having a role set. Both are fine. I honestly think Wayland is nicer but realistically you code for both. To get a global hot key you register it with the compositor and it works. But you can run a background daemon to catch all keys if you really want.
kelnos 7mo ago
> Window managers in general, xdotool, all kinds of input mapping and automation or the fact that you can write a screenshot tool in less than 500 LOC are only possible if you talk to X directly. Honestly I think this is a pretty fair approximation of "no one". How many people are writing tools like this vs. the number of people writing regular applications? A very small number, I'd say. And after working extensively with both libX11/libxcb and libwayland-client directly, I can say that none of them are particularly pleasant to work with. Actually, no, that's not true: libwayland-client wins, easily. Every single Wayland protocol has code generated for it that works exactly the same way. I suppose the same is (more or less) true of libxcb, but libX11 (and all the other libraries you might have to use, like libXrender, libXrandr, libXext...) are a complete mess. And even then, libwayland-client has a much lower number of concepts you have to understand than libxcb does, simply because the Wayland protocol has a small number of concepts you need to understand. libxcb is definitely an improvement over libX11, but it can't magically make all the underlying X11 protocol concepts become unified.
gf000 7mo ago
And why should we optimize for "how many locs can I write a screenshot tool in"? I would prefer to having 1-2 decent ones that have all the necessary features and call it a day. They can then have a simple API so you can script whatever you want. Why would I want to add more complexity to a display server?

flohofwoe 7mo ago

Creating a window and Vulkan context and receiving input events (e.g. what game-like applications need) is fairly trivial via Xlib but far worse in Wayland. The Xlib API also sucks compared to Win32 or Cocoa, but writing a Wayland client for something as trivial as creating and managing a window is much worse than on any other platform (see: https://www.p4m.dev/posts/29/index.html https://www.p4m.dev/posts/29/index.html)

gf000 7mo ago
That's what stuff like SDL meant to abstract away.
- flohofwoe 7mo ago
  Sure, but SDL can also only do so much to plaster over missing or optional Wayland features: https://wiki.libsdl.org/SDL3/README-wayland https://wiki.libsdl.org/SDL3/README-wayland Basic window system functionality really needs to be provided by the OS, not by 3rd-party libraries. And there's no reason why simple things like creating a window should be drastically more code in an OS API than in a wrapper library like SDL.