4 ms·

> So this is a compatibility library? Not just a server that runs without a root window? Correct! > I don't have a Haiku box handy to test - is Xephyr any eas

> So this is a compatibility library? Not just a server that runs without a root window? Correct! > I don't have a Haiku box handy to test - is Xephyr any easier/better? It seems to be the "modern" option. Both Xnest and Xephyr are both "backends" for the main X.org server, though at two different "levels" and with two different goals. The main technical difference is that Xnest runs on Xlib, and Xephyr runs on XCB -- which is a much lower-level library that more or less deals with the X11 protocol directly, as opposed to having a slightly abstracted view of things as Xlib provides. (Modern Xlib is itself implemented on top of XCB.) So, since Xlibe implements Xlib, Xephyr isn't an option.

yjftsjthsd-h 4y ago
Thanks for clarifying. I assume the reason you implemented at this level is because it was a better match for Haiku's graphical APIs? And if you don't have xcb, does that limit what applications can run with this library? I think I remember seeing programs that depended on XCB directly.
- waddlesplash 4y ago
  > Thanks for clarifying. I assume the reason you implemented at this level is because it was a better match for Haiku's graphical APIs? It's possible to integrate with the rest of the system much more smoothly than a full server will allow. GTK apps, for instance, feel like second-class citizens on basically anything except maybe GNOME (but do they even feel "at home" there...?) so it just didn't seem worth the effort to write a full GTK port vs. writing this, instead. I discussed more of the "why" on the forum posts introducing this last winter: https://discuss.haiku-os.org/t/xlibe-an-xlib-x11-compatibility-layer-for-haiku/11692 https://discuss.haiku-os.org/t/xlibe-an-xlib-x11-compatibili... > And if you don't have xcb, does that limit what applications can run with this library? I think I remember seeing programs that depended on XCB directly. There are a few (I believe Qt on Linux now uses XCB instead of Xlib), but not enough that it really matters (we have a native Qt port on Haiku already, anyway, e.g.)

yjftsjthsd-h 4y ago

Thanks for clarifying. I assume the reason you implemented at this level is because it was a better match for Haiku's graphical APIs? And if you don't have xcb, does that limit what applications can run with this library? I think I remember seeing programs that depended on XCB directly.

waddlesplash 4y ago
> Thanks for clarifying. I assume the reason you implemented at this level is because it was a better match for Haiku's graphical APIs? It's possible to integrate with the rest of the system much more smoothly than a full server will allow. GTK apps, for instance, feel like second-class citizens on basically anything except maybe GNOME (but do they even feel "at home" there...?) so it just didn't seem worth the effort to write a full GTK port vs. writing this, instead. I discussed more of the "why" on the forum posts introducing this last winter: https://discuss.haiku-os.org/t/xlibe-an-xlib-x11-compatibility-layer-for-haiku/11692 https://discuss.haiku-os.org/t/xlibe-an-xlib-x11-compatibili... > And if you don't have xcb, does that limit what applications can run with this library? I think I remember seeing programs that depended on XCB directly. There are a few (I believe Qt on Linux now uses XCB instead of Xlib), but not enough that it really matters (we have a native Qt port on Haiku already, anyway, e.g.)