3 ms·

It just means "noone" uses the wayland APIs directly, but instead they leave the wayland complexity to GTK,Qt or FLTK, and they call their app a Qt app, not a W

It just means "noone" uses the wayland APIs directly, but instead they leave the wayland complexity to GTK,Qt or FLTK, and they call their app a Qt app, not a Wayland app.

simonh 6mo 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 6mo ago
  [deleted]
- sprash 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo ago
    That's what stuff like SDL meant to abstract away.
    - flohofwoe 6mo 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.
kelnos 6mo ago
Then in that case, the point is moot, as a similar version of "no one" uses the X11 APIs directly anymore, either.
rezonant 6mo ago
No one who loved themselves wrote Xlib apps directly either.
- whizzter 6mo ago
  I actually wrote some stuff directly because I was young, poor and stupid. First year in uni my windows laptop broke, had to lug around a heavy second hand underpowered ppc powerbook and wrote some application I needed that I didn't want "bloated". Font handling, shared memory backbuffers, network api, etc.. as I wrote in another comment. It is an API to solve over the wire graphics in the late 80s/early 90s era using idioms of that time, and already by year 2000 the problems (rasterization power) didn't exist nor is it even a suitable API surface (even less so 25 years later).
- pjmlp 6mo ago
  Athena widgets were great! /s

It just means "noone" uses the wayland APIs directly, but instead they leave the wayland complexity to GTK,Qt or FLTK, and they call their app a Qt app, not a Wayland app.

simonh 6mo 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 6mo ago
[deleted]
sprash 6mo 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 6mo 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 6mo 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 6mo 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 6mo 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 6mo ago
  That's what stuff like SDL meant to abstract away.
  - flohofwoe 6mo 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.

kelnos 6mo ago

Then in that case, the point is moot, as a similar version of "no one" uses the X11 APIs directly anymore, either.

rezonant 6mo ago

No one who loved themselves wrote Xlib apps directly either.

whizzter 6mo ago
I actually wrote some stuff directly because I was young, poor and stupid. First year in uni my windows laptop broke, had to lug around a heavy second hand underpowered ppc powerbook and wrote some application I needed that I didn't want "bloated". Font handling, shared memory backbuffers, network api, etc.. as I wrote in another comment. It is an API to solve over the wire graphics in the late 80s/early 90s era using idioms of that time, and already by year 2000 the problems (rasterization power) didn't exist nor is it even a suitable API surface (even less so 25 years later).
pjmlp 6mo ago
Athena widgets were great! /s