4 ms·

> 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 Haik

> 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?
- waddlesplash 4y ago
  Yes, it's probably easy to identify the Haiku-specific bits and start replacing them, but some of the organization of e.g. the Drawables classes is kind of implicitly built around Haiku APIs, so it might be a little less trivial than it appears at first glance. Still, it's indeed possible, if someone wanted to try it.

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?

waddlesplash 4y ago
Yes, it's probably easy to identify the Haiku-specific bits and start replacing them, but some of the organization of e.g. the Drawables classes is kind of implicitly built around Haiku APIs, so it might be a little less trivial than it appears at first glance. Still, it's indeed possible, if someone wanted to try it.