Hello HN,<p>While there are some projects that implement partial versions of Xlib APIs on non-X11 platforms for compatibility (most notably, Tk), I don't know of any others sophisticated enough to run Cairo and GTK applications (albeit with a few hacks). So I figured this might be technically interesting.<p>As of now it just implements the base Xlib APIs, it doesn't implement XRender, GLX, XInput2, etc. (though it's more than possible, I just didn't see a need yet.) Cross-program interaction is also very limited, and there are plenty of X11 features that likely can't be implemented; but this works sufficiently well that GTK3 is now in Haiku's default package repositories, with GIMP and Inkscape atop it to boot, using this.<p>And for the fun of it, I did try to compile Xnest (the X.org server variant running on top of Xlib) on top of this; it crashed on startup in the keyboard handlers. However, that could potentially be because I didn't have the necessary data files and not because of anything missing in Xlibe; I didn't investigate too far (or it could be an actual incompatibility; Xlibe's keyboard subsystem is rather primitive and is most of the reason I had to patch GTK for full functionality.)<p>(A few more screenshots, including GTK and WINE running atop Xlibe: <a href="https://www.haiku-os.org/blog/waddlesplash/2022-01-10_haiku_contract_report_december_2021/" rel="nofollow">https://www.haiku-os.org/blog/waddlesplash/2022-01-10_haiku_...</a>)
A few more technical details, for the interested:<p>* Every X11 "Window" gets its own BView (which is itself vaguely analogous to a QWidget in Qt, etc.) and of course top-level "Window"s attached to the root get their own "BWindow" as well.<p>* All drawing goes through the Haiku drawing APIs. (This does create some artifacts in applications that expect X11 drawing isn't antialiased, like most Xt/Xaw applications, but it works tolerably well.)<p>* Since Haiku has no "display server" / "windowing system" divide, all operations related to both are directly handled in Xlibe. This creates some trickiness when applications request "window manager bypasses" in tandem with modality management, and also in decorations/borders handling, but it works well enough.
X11 API without an X server is a super cool concept. I followed the forum thread after OSnews reported on it late last year <a href="https://www.osnews.com/story/134362/xlibe-an-xlib-x11-compatibility-layer-for-haiku/" rel="nofollow">https://www.osnews.com/story/134362/xlibe-an-xlib-x11-compat...</a> and your progress has been really exciting to watch. It's a great project. When Haiku got a Qt port it made a massive difference in software availability and this will too.<p>GTK will always owner-draw its buttons, so you don't get a real native Be widget. And it's clearly possible to do a good-enough X server integration as demonstrated by WSL, Quartz etc with minor complaints about clipboard syncing, decorations, having to run another daemon etc. After all that, what would you say is the main benefit to this approach?
I haven’t followed BeOS stuff since the early oughts, but I’m floored at how mature Haiku has gotten. A modern GCC? Xlib mature enough to run GTK? A native QT backend? I also noticed what appears to be a well along Emacs backend as well. Amazing progress for an independent OS project.
I hate to be the one who has to say this, but this is a bad idea. If this is being done for practical reasons then don't waste your time with this. It might work for some clients but you'll get stuck in the same place that every other re-implementation of X11 over the last 30 years got stuck at, which is supporting any kind of weird quirky behavior in Xlib and its large collection of client libraries, and the rest of the quirky behavior in the X server. Eventually you'll end up copying large sections of code out until it slowly transforms back into Xlib and Xorg and effectively it becomes another approximation of an X server. If that's fine with you then by all means keep going, but please don't continue along with the idea that you can avoid this. It has been tried many, many times before.
> serverless<p>So this is a compatibility library? Not just a server that runs without a root window?<p>> but this works sufficiently well that GTK3 is now in Haiku's default package repositories, with GIMP and Inkscape atop it to boot, using this<p>That is absolutely fantastic:)<p>> And for the fun of it, I did try to compile Xnest (the X.org server variant running on top of Xlib) on top of this; it crashed on startup in the keyboard handlers<p>I don't have a Haiku box handy to test - is Xephyr any easier/better? It seems to be the "modern" option.
How hard would be to abstract the Hauku-specific bits into their own part? It'd be neat if it was possible to use this not only to target Haiku but also other window systems like Win32 and Cocoa.<p>Does something like Gtk1.2[0] (which AFAIK does more heavy use of xlib than modern GTK) work? How about Motif?<p>[0] <a href="http://runtimeterror.com/pages/badsector/gtk12/" rel="nofollow">http://runtimeterror.com/pages/badsector/gtk12/</a>
This is neat.<p>I thought one time of bringing X apps to Windows in a source-compatible way by embedding an X server similar to Kdrive in a library that communicated with the application via a ring buffer or similar. It's cool to see similar work actually being done.
Interesting! I love stuff like this (compatibility layers like wine, darwin).<p>I think a better title might include mentioning what Haiku <i>is</i>, though 15 seconds of googling worked just as well. :)