3 ms·

IMHO for applications it should be completely irrelevant whether they talk to Xlib, XCB, Wayland, or any other future window-system-glue API which sits below wi

IMHO for applications it should be completely irrelevant whether they talk to Xlib, XCB, Wayland, or any other future window-system-glue API which sits below widget frameworks like GTK or Qt (just don't require me to use GTK or Qt in an application which just needs a GL or Vulkan canvas instead of a full-blown UI framework). All those choices should just be differently flavoured client-side APIs to do the same thing (opening a window for 3D rendering, and getting input events). Frankly, I don't care what's going on under the hood, just give me an easy ui-framework-agnostic way to open a window to draw into (and most importantly where I don't need to draw the frigging title bar myself).

qwerty456127 3y ago
Is this not really this way? Do you mean a person building a GTK or a Qt app actually has to check whether the app is running under Wayland and do something special to support it nowadays?
- flohofwoe 3y ago
  No that situation is fine. The problems start if you don't want to use GTK or Qt, because in that situation Wayland provides only a subset of features compared to X11 (like not universally supporting window chrome rendering, so a native Wayland application needs to render its own window chrome which won't look consistent with other applications). I actually wonder what happens if you run a Gnome app on KDE, or a KDE app on Gnome on top of Wayland, does the title bar look consistent in that case? I guess I also don't understand why there are even multiple Wayland display server implementations with different feature sets. As if desktop Linux wasn't already fragmented enough.
  - qwerty456127 3y ago
    > application which needs to render its own window chrome I understand this is absolutely subjective but I just hate this phenomenon so much...
    - flohofwoe 3y ago
      As far as I'm aware it's mostly thanks to the GNOME project which fundamentally rejects the idea of adding 'server side window decorations' to their Wayland implementation, which is a weird hill to die on (and GNOME systems are unfortunately too popular to just ignore). This means native Wayland applications can't do much else than render their own window chrome, which then of course looks amateurish and inconsistent. It feels like a regression back to the early 1970's for no good reasons. Compare that to Xlib/XCB where you just create a window and that automatically looks consistent (this is also why XWayland is actually a really useful piece of software for applications that just need a GL or Vulkan context but no full-blown UI framework like GTK or Qt).
    - deleted 3y ago
      [deleted]
  - ndiddy 3y ago
    > I actually wonder what happens if you run a Gnome app on KDE, or a KDE app on Gnome on top of Wayland, does the title bar look consistent in that case? If you run a "real" Gnome app (that uses libadawaita) on KDE, it will look exactly like what it looks like in Gnome (giant titlebar with stuff on it, no minimize button, etc).
rini17 3y ago
If human-computer interface is merely a matter of drawing stuff into somewhere, then you're right.

qwerty456127 3y ago

Is this not really this way? Do you mean a person building a GTK or a Qt app actually has to check whether the app is running under Wayland and do something special to support it nowadays?

flohofwoe 3y ago
No that situation is fine. The problems start if you don't want to use GTK or Qt, because in that situation Wayland provides only a subset of features compared to X11 (like not universally supporting window chrome rendering, so a native Wayland application needs to render its own window chrome which won't look consistent with other applications). I actually wonder what happens if you run a Gnome app on KDE, or a KDE app on Gnome on top of Wayland, does the title bar look consistent in that case? I guess I also don't understand why there are even multiple Wayland display server implementations with different feature sets. As if desktop Linux wasn't already fragmented enough.
- qwerty456127 3y ago
  > application which needs to render its own window chrome I understand this is absolutely subjective but I just hate this phenomenon so much...
  - flohofwoe 3y ago
    As far as I'm aware it's mostly thanks to the GNOME project which fundamentally rejects the idea of adding 'server side window decorations' to their Wayland implementation, which is a weird hill to die on (and GNOME systems are unfortunately too popular to just ignore). This means native Wayland applications can't do much else than render their own window chrome, which then of course looks amateurish and inconsistent. It feels like a regression back to the early 1970's for no good reasons. Compare that to Xlib/XCB where you just create a window and that automatically looks consistent (this is also why XWayland is actually a really useful piece of software for applications that just need a GL or Vulkan context but no full-blown UI framework like GTK or Qt).
  - deleted 3y ago
    [deleted]
- ndiddy 3y ago
  > I actually wonder what happens if you run a Gnome app on KDE, or a KDE app on Gnome on top of Wayland, does the title bar look consistent in that case? If you run a "real" Gnome app (that uses libadawaita) on KDE, it will look exactly like what it looks like in Gnome (giant titlebar with stuff on it, no minimize button, etc).

rini17 3y ago

If human-computer interface is merely a matter of drawing stuff into somewhere, then you're right.