7 ms·

Show HN: Xlibe – A serverless Xlib (X11) compatibility layer for Haiku

116 points by waddlesplash 4y ago

Hello HN, 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. 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. 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.) (A few more screenshots, including GTK and WINE running atop Xlibe: https://www.haiku-os.org/blog/waddlesplash/2022-01-10_haiku_contract_report_december_2021/ https://www.haiku-os.org/blog/waddlesplash/2022-01-10_haiku_...)

deleted 4y ago
[deleted]
waddlesplash 4y ago
A few more technical details, for the interested: * 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. * 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.) * 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.
- waddlesplash 4y ago
  And I forgot to mention, how silly of me: This work was largely done under sponsorship from Haiku, Inc. (https://www.haiku-inc.org/ https://www.haiku-inc.org/), the non-profit that manages the financial/legal aspects of Haiku development. If you find this and the other work I have been doing on Haiku in recent months good or interesting, please consider donating or setting up a recurring donation!
loxias 4y ago
Interesting! I love stuff like this (compatibility layers like wine, darwin). I think a better title might include mentioning what Haiku is, though 15 seconds of googling worked just as well. :)
sitkack 4y ago
Could this awesome work be used to getting X11 running in the browser?
- waddlesplash 4y ago
  No. As I noted to another commenter, this makes heavy and direct use of the Haiku APIs to do basically everything. Haiku actually does have a full draw-call-forwarding remote desktop system, with an HTML5 client to boot, and you could run this through that, but it's kind of "experimental". For straight X11, using something like Xpra with a HTML5 client is probably what you want.
- loxias 4y ago
  You want X11 in the browser? Mind if I ask why, what you would use it for, etc? (I ask because, as a side project I've been working on something that lets me have a more responsive laptop by offloading resource intensive graphical programs to another machine, and streaming the UI back to me. I guess it could be made to run in a browser.)
  - marwis 4y ago
    Might be useful for porting some classic X programs to Web.
  - sitkack 4y ago
    Yeah, I have been playing with RDP/remote desktop solutions in Docker for the same need. Another option is using something like the Phoenix framework in Elixir. https://www.phoenixframework.org/ https://www.phoenixframework.org/ What techniques are you using, is remote desktop or a new desktop application framework?
- toast0 4y ago
  I do believe this page has an X server in the browser, or at least it strongly appears to: https://magcius.github.io/xplain/article/x-basics.html https://magcius.github.io/xplain/article/x-basics.html
AshamedCaptain 4y ago
Very cool. I guess the drawing functions are mapped to Be drawing routines, which means probably using this on say Android would be a big effort.
- waddlesplash 4y ago
  They are. More than just the drawing routines, quite literally the entire thing directly invokes Be APIs. For instance XQueryPointer just calls directly into the Interface Kit to get the present mouse position, or XSetWMProperties directly modifies the Haiku-native window state, title, etc. However, that being said, if you wanted to do something similar or equivalent on some other platform, you could probably copy quite a lot of the structure, and then delete the actual implementation and replace it with your own. I restructured things a bunch in the early phases of working on this, and there's a lot of boilerplate code (e.g. macros.c, large parts of the event dispatcher) which you could reuse verbatim; though it's mixed in with the non-boilerplate code. There were some other projects I ran into that looked like they were more generic, e.g. https://github.com/Abestanis/SDL2X11Emulation https://github.com/Abestanis/SDL2X11Emulation (also check the forks of that -- though I'm one of them, I experimented with it a bit before starting on this thing; but it's very incomplete and SDL2 really isn't designed for this), but none anywhere near as advanced as this is now.
  - LeFantome 4y ago
    I glanced at the code earlier and my first thought was fact it could be adapted to provide Xlib for SerenityOS. I have nothing to do with Serenity and have never even used C++ but your code was easy to read and so the possibility just jumped out at me.
mappu 4y ago
X11 API without an X server is a super cool concept. I followed the forum thread after OSnews reported on it late last year https://www.osnews.com/story/134362/xlibe-an-xlib-x11-compatibility-layer-for-haiku/ https://www.osnews.com/story/134362/xlibe-an-xlib-x11-compat... 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. 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?
- waddlesplash 4y ago
  Thanks for following along! > GTK will always owner-draw its buttons, so you don't get a real native Be widget. Well, I think it might be potentially possible to write a theme that uses Haiku control-drawing APIs, just like for Qt (already there are some CSS files that make GTK look like Haiku, but Haiku itself has a control-theming engine, so it would be good to look into that. But not something that's on my radar.) > 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. Having used X11+WSL and X11+forwarding quite extensively (and XQuartz a bit), my complaints about that approach are ... far from minor. Everything both looks and feels like it has been awkwardly shoehorned in. Window modality, sizing, and positioning always runs into problems. Now, some of that is just MS Windows being Windows, and X11 not having a good way to deal with some of the differences between X11 models and Windows, etc. But I think a large part of it, having looked at X11 internals (and as you can see, knowing more than a bit about them in order to write this thing and make it work) is that distinctions which are more minor at the base levels of the API become significantly bigger the further up you go -- the window manager vs. display server is probably the most obvious one here. Xlibe can largely forget there even is a "display server / window manager" distinction and take calls that deal with one or the other and invoke the necessary Haiku APIs. > After all that, what would you say is the main benefit to this approach? Besides the ones outlined above, I would say it's much more possible to integrate with the rest of the system in broad ways. For instance, clipboard handling can pretend to do the strange set/get property dance in Xlibe for compatibility's sake, and then turn around and invoke the (much more sane) Haiku clipboard APIs internally. With a real X11 server, the clipboard handling is just the standard get/set property system, and you have to have something else (in the X11 server) that forwards clipboard updates in both directions. That can quickly get very complicated. Another thing is keyboard handling. I don't bother creating X11 keymap structures at all in Xlibe; applications either get XK_* values (for e.g. Return, etc.) or UTF-8 text (which can be locale-converted if needed.) That means you can swap keymaps in Haiku and Xlibe will follow right along. I have no idea how much code that would wind up being in an X11 server port to deal with, but I know for sure it would not be fun at all, having dealt with X11 keyboard APIs from more than one vantage point. Drag and drop would probably be another, but I didn't implement that in Xlibe (yet?)
bitwize 4y ago
This is neat. 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.
yjftsjthsd-h 4y ago
> serverless So this is a compatibility library? Not just a server that runs without a root window? > 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 That is absolutely fantastic:) > 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 I don't have a Haiku box handy to test - is Xephyr any easier/better? It seems to be the "modern" option.
- waddlesplash 4y ago
  > 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.)
rayiner 4y ago
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.
- waddlesplash 4y ago
  The graphical Emacs backend, unlike the rest of the things you mention, was not developed by one of the "regular Haiku developers" but by one of the Emacs developers, and fully upstream, too, which makes it doubly exciting. Indeed it's now available in Haiku's package repositories (or of course you can build Emacs from source yourself.) :)
throwaway82652 4y ago
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.
- waddlesplash 4y ago
  > If this is being done for practical reasons then don't waste your time with this. Too late, I did, and it's already being used "in production" to power GTK on Haiku! > It might work for some clients Well, GTK was the one client I really cared about, and it works for that, so... It should work for Tk, too, but there's one really annoying bug somewhere in Xlibe which is causing Tk problems; and I didn't figure out what it was in the Tk codebase (this is doubly strange because Tk itself has Xlib compatibility layers to run on other OSes, you would think they would have excised any such quirky behavior.) The "AndroWish" developer said he'd try to take a look and figure out what was going on, at some point. > you'll get stuck in the same place that every other re-implementation of X11 got stuck at So far as I've been able to tell, this is now the single most advanced Xlib compatibility layer ever written (well, that's publicly available and locateable, anyway. I wouldn't be surprised if there's more advanced ones behind closed doors.) At least, I don't see any others powerful enough to run GTK, do you? So I think I've not gotten stuck at that same place then!
  - throwaway82652 4y ago
    >Too late, I did This reply makes no sense, I would greatly advise against falling for the sunk cost fallacy. If all you care about is GTK, then you could have just done a native port of GTK. That would actually be a lot easier than trying to reimplement every X client library. With GTK4 it should be even easier because the backends were simplified and a lot of the weird X idiosyncrasies were removed, and you might actually have a chance to get hardware acceleration to work without having to go through the pain of dealing with GLX. The problem with Xlib is that's is not just the one library, it's actually about 30 libraries. So like I was saying earlier, it's cool that you have one, but the hard and annoying part that isn't worth it is doing the other 29. Nobody has gotten that far, and if you do get that far, the best way to do it would be to copy a huge amount of code. So the goal here can't really be reached in any practical terms, unless you just want to stop here.
marwis 4y ago
Similar thing but for Win32 - http://libw11.sourceforge.net/ http://libw11.sourceforge.net/
DeathArrow 4y ago
Ideally apps should be ported using Haiku's native GUI.
badsectoracula 4y ago
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. Does something like Gtk1.2[0] (which AFAIK does more heavy use of xlib than modern GTK) work? How about Motif? [0] http://runtimeterror.com/pages/badsector/gtk12/ http://runtimeterror.com/pages/badsector/gtk12/
- waddlesplash 4y ago
  > How hard would be to abstract the Hauku-specific bits into their own part? Hard, as I mentioned to other commenters, Xlibe makes heavy and direct use of Haiku APIs everywhere to do just about everything. However... > 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. Using Xlibe as a starting point to write an equivalent library for Win32, Cocoa, or even Wayland would probably save you a lot of time, effort, and hassle in that a lot of Xlib general architecture, some behavioral oddities, etc. are already worked out in Xlibe as a matter of course. I'd be happy to guide others through what that process might look like if there was interest. > Does something like Gtk1.2[0] (which AFAIK does more heavy use of xlib than modern GTK) work? I didn't try it, but modern GTK actually makes pretty heavy use of Xlib; and Xt/Xaw do as well, which also work, so I imagine it would; or if it didn't, improving Xlibe so that it did would not be too hard. > How about Motif? Motif relies heavily on strange and implicit behaviors of X11. I was advised by one of the Emacs developers that it was probably inadvisable to try and get it to run under this. However, I did build it and it at least starts and does display things, but there are drawing artifacts and events do not work quite right. So, it's probably theoretically possible, but I don't think it's really worth spending the time and effort in doing so. It is probably a better use of time to refactor/rewrite whatever software still uses Motif as its UI toolkit to use something else instead...
  - LeFantome 4y ago
    While the Haiku stuff is scattered around the code as you say, at first glance it looks fairly easy to identify. For example, any function call starting with a capital ‘B’ seemed likely to be calling into Haiku while most of the ‘X’ stuff is Xlibe itself. The ‘B’ stuff that I saw was stuff like handles, points, and strokes ( lines ) that called into Haiku to do whatever Xlibe was trying to accomplish. To my eye, it looked like it would be fairly straight-forward to port this over to any other graphical API that provided the same basic concepts ( windows, views, points, lines ). You would have to modify code all over the place but the code looks easy to identify and easy to map to alternatives. Am I looking at this too simplistically?
marcodiego 4y ago
Something that maybe interesting: running it under DOS. That would allow porting some apps to FreeDOS.

116 points by waddlesplash 4y ago

deleted 4y ago

[deleted]

waddlesplash 4y ago

A few more technical details, for the interested: * 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. * 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.) * 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.

waddlesplash 4y ago
And I forgot to mention, how silly of me: This work was largely done under sponsorship from Haiku, Inc. (https://www.haiku-inc.org/ https://www.haiku-inc.org/), the non-profit that manages the financial/legal aspects of Haiku development. If you find this and the other work I have been doing on Haiku in recent months good or interesting, please consider donating or setting up a recurring donation!

loxias 4y ago

Interesting! I love stuff like this (compatibility layers like wine, darwin). I think a better title might include mentioning what Haiku is, though 15 seconds of googling worked just as well. :)

sitkack 4y ago

Could this awesome work be used to getting X11 running in the browser?

waddlesplash 4y ago
No. As I noted to another commenter, this makes heavy and direct use of the Haiku APIs to do basically everything. Haiku actually does have a full draw-call-forwarding remote desktop system, with an HTML5 client to boot, and you could run this through that, but it's kind of "experimental". For straight X11, using something like Xpra with a HTML5 client is probably what you want.
loxias 4y ago
You want X11 in the browser? Mind if I ask why, what you would use it for, etc? (I ask because, as a side project I've been working on something that lets me have a more responsive laptop by offloading resource intensive graphical programs to another machine, and streaming the UI back to me. I guess it could be made to run in a browser.)
- marwis 4y ago
  Might be useful for porting some classic X programs to Web.
- sitkack 4y ago
  Yeah, I have been playing with RDP/remote desktop solutions in Docker for the same need. Another option is using something like the Phoenix framework in Elixir. https://www.phoenixframework.org/ https://www.phoenixframework.org/ What techniques are you using, is remote desktop or a new desktop application framework?
toast0 4y ago
I do believe this page has an X server in the browser, or at least it strongly appears to: https://magcius.github.io/xplain/article/x-basics.html https://magcius.github.io/xplain/article/x-basics.html

AshamedCaptain 4y ago

Very cool. I guess the drawing functions are mapped to Be drawing routines, which means probably using this on say Android would be a big effort.

waddlesplash 4y ago
They are. More than just the drawing routines, quite literally the entire thing directly invokes Be APIs. For instance XQueryPointer just calls directly into the Interface Kit to get the present mouse position, or XSetWMProperties directly modifies the Haiku-native window state, title, etc. However, that being said, if you wanted to do something similar or equivalent on some other platform, you could probably copy quite a lot of the structure, and then delete the actual implementation and replace it with your own. I restructured things a bunch in the early phases of working on this, and there's a lot of boilerplate code (e.g. macros.c, large parts of the event dispatcher) which you could reuse verbatim; though it's mixed in with the non-boilerplate code. There were some other projects I ran into that looked like they were more generic, e.g. https://github.com/Abestanis/SDL2X11Emulation https://github.com/Abestanis/SDL2X11Emulation (also check the forks of that -- though I'm one of them, I experimented with it a bit before starting on this thing; but it's very incomplete and SDL2 really isn't designed for this), but none anywhere near as advanced as this is now.
- LeFantome 4y ago
  I glanced at the code earlier and my first thought was fact it could be adapted to provide Xlib for SerenityOS. I have nothing to do with Serenity and have never even used C++ but your code was easy to read and so the possibility just jumped out at me.

mappu 4y ago

X11 API without an X server is a super cool concept. I followed the forum thread after OSnews reported on it late last year https://www.osnews.com/story/134362/xlibe-an-xlib-x11-compatibility-layer-for-haiku/ https://www.osnews.com/story/134362/xlibe-an-xlib-x11-compat... 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. 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?

waddlesplash 4y ago
Thanks for following along! > GTK will always owner-draw its buttons, so you don't get a real native Be widget. Well, I think it might be potentially possible to write a theme that uses Haiku control-drawing APIs, just like for Qt (already there are some CSS files that make GTK look like Haiku, but Haiku itself has a control-theming engine, so it would be good to look into that. But not something that's on my radar.) > 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. Having used X11+WSL and X11+forwarding quite extensively (and XQuartz a bit), my complaints about that approach are ... far from minor. Everything both looks and feels like it has been awkwardly shoehorned in. Window modality, sizing, and positioning always runs into problems. Now, some of that is just MS Windows being Windows, and X11 not having a good way to deal with some of the differences between X11 models and Windows, etc. But I think a large part of it, having looked at X11 internals (and as you can see, knowing more than a bit about them in order to write this thing and make it work) is that distinctions which are more minor at the base levels of the API become significantly bigger the further up you go -- the window manager vs. display server is probably the most obvious one here. Xlibe can largely forget there even is a "display server / window manager" distinction and take calls that deal with one or the other and invoke the necessary Haiku APIs. > After all that, what would you say is the main benefit to this approach? Besides the ones outlined above, I would say it's much more possible to integrate with the rest of the system in broad ways. For instance, clipboard handling can pretend to do the strange set/get property dance in Xlibe for compatibility's sake, and then turn around and invoke the (much more sane) Haiku clipboard APIs internally. With a real X11 server, the clipboard handling is just the standard get/set property system, and you have to have something else (in the X11 server) that forwards clipboard updates in both directions. That can quickly get very complicated. Another thing is keyboard handling. I don't bother creating X11 keymap structures at all in Xlibe; applications either get XK_* values (for e.g. Return, etc.) or UTF-8 text (which can be locale-converted if needed.) That means you can swap keymaps in Haiku and Xlibe will follow right along. I have no idea how much code that would wind up being in an X11 server port to deal with, but I know for sure it would not be fun at all, having dealt with X11 keyboard APIs from more than one vantage point. Drag and drop would probably be another, but I didn't implement that in Xlibe (yet?)

bitwize 4y ago

This is neat. 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.

yjftsjthsd-h 4y ago

> serverless So this is a compatibility library? Not just a server that runs without a root window? > 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 That is absolutely fantastic:) > 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 I don't have a Haiku box handy to test - is Xephyr any easier/better? It seems to be the "modern" option.

waddlesplash 4y ago
> 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.)

rayiner 4y ago

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.

waddlesplash 4y ago
The graphical Emacs backend, unlike the rest of the things you mention, was not developed by one of the "regular Haiku developers" but by one of the Emacs developers, and fully upstream, too, which makes it doubly exciting. Indeed it's now available in Haiku's package repositories (or of course you can build Emacs from source yourself.) :)

throwaway82652 4y ago

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.

waddlesplash 4y ago
> If this is being done for practical reasons then don't waste your time with this. Too late, I did, and it's already being used "in production" to power GTK on Haiku! > It might work for some clients Well, GTK was the one client I really cared about, and it works for that, so... It should work for Tk, too, but there's one really annoying bug somewhere in Xlibe which is causing Tk problems; and I didn't figure out what it was in the Tk codebase (this is doubly strange because Tk itself has Xlib compatibility layers to run on other OSes, you would think they would have excised any such quirky behavior.) The "AndroWish" developer said he'd try to take a look and figure out what was going on, at some point. > you'll get stuck in the same place that every other re-implementation of X11 got stuck at So far as I've been able to tell, this is now the single most advanced Xlib compatibility layer ever written (well, that's publicly available and locateable, anyway. I wouldn't be surprised if there's more advanced ones behind closed doors.) At least, I don't see any others powerful enough to run GTK, do you? So I think I've not gotten stuck at that same place then!
- throwaway82652 4y ago
  >Too late, I did This reply makes no sense, I would greatly advise against falling for the sunk cost fallacy. If all you care about is GTK, then you could have just done a native port of GTK. That would actually be a lot easier than trying to reimplement every X client library. With GTK4 it should be even easier because the backends were simplified and a lot of the weird X idiosyncrasies were removed, and you might actually have a chance to get hardware acceleration to work without having to go through the pain of dealing with GLX. The problem with Xlib is that's is not just the one library, it's actually about 30 libraries. So like I was saying earlier, it's cool that you have one, but the hard and annoying part that isn't worth it is doing the other 29. Nobody has gotten that far, and if you do get that far, the best way to do it would be to copy a huge amount of code. So the goal here can't really be reached in any practical terms, unless you just want to stop here.

marwis 4y ago

Similar thing but for Win32 - http://libw11.sourceforge.net/ http://libw11.sourceforge.net/

DeathArrow 4y ago

Ideally apps should be ported using Haiku's native GUI.

badsectoracula 4y ago

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. Does something like Gtk1.2[0] (which AFAIK does more heavy use of xlib than modern GTK) work? How about Motif? [0] http://runtimeterror.com/pages/badsector/gtk12/ http://runtimeterror.com/pages/badsector/gtk12/

waddlesplash 4y ago
> How hard would be to abstract the Hauku-specific bits into their own part? Hard, as I mentioned to other commenters, Xlibe makes heavy and direct use of Haiku APIs everywhere to do just about everything. However... > 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. Using Xlibe as a starting point to write an equivalent library for Win32, Cocoa, or even Wayland would probably save you a lot of time, effort, and hassle in that a lot of Xlib general architecture, some behavioral oddities, etc. are already worked out in Xlibe as a matter of course. I'd be happy to guide others through what that process might look like if there was interest. > Does something like Gtk1.2[0] (which AFAIK does more heavy use of xlib than modern GTK) work? I didn't try it, but modern GTK actually makes pretty heavy use of Xlib; and Xt/Xaw do as well, which also work, so I imagine it would; or if it didn't, improving Xlibe so that it did would not be too hard. > How about Motif? Motif relies heavily on strange and implicit behaviors of X11. I was advised by one of the Emacs developers that it was probably inadvisable to try and get it to run under this. However, I did build it and it at least starts and does display things, but there are drawing artifacts and events do not work quite right. So, it's probably theoretically possible, but I don't think it's really worth spending the time and effort in doing so. It is probably a better use of time to refactor/rewrite whatever software still uses Motif as its UI toolkit to use something else instead...
- LeFantome 4y ago
  While the Haiku stuff is scattered around the code as you say, at first glance it looks fairly easy to identify. For example, any function call starting with a capital ‘B’ seemed likely to be calling into Haiku while most of the ‘X’ stuff is Xlibe itself. The ‘B’ stuff that I saw was stuff like handles, points, and strokes ( lines ) that called into Haiku to do whatever Xlibe was trying to accomplish. To my eye, it looked like it would be fairly straight-forward to port this over to any other graphical API that provided the same basic concepts ( windows, views, points, lines ). You would have to modify code all over the place but the code looks easy to identify and easy to map to alternatives. Am I looking at this too simplistically?

marcodiego 4y ago

Something that maybe interesting: running it under DOS. That would allow porting some apps to FreeDOS.