Tk starts and renders some things, but for some reason it places a “BackgroundElement” in front of everything else most of the time, so controls only show up if you get them to redraw partially instead of fully. I don’t really understand why this is happening; the exact same version of Tk works on SDL2Tk though, so I’m guessing this must somehow be a bug in Xlibe.
AzPainter on the other hand has much lighter usage of X11, and is almost fully working. It doesn’t support pen-pressure input yet (that needs XInput2 which I haven’t implemented compatibility for), but otherwise I think window modality is about the feature I know of that I still have yet to implement for it. (There are 3 ways of making windows modal in X11; I implemented two of them, but of course AzPainter uses the third.)
xclock starts, but it has some drawing glitches because it presumes drawing is not antialiased, whereas all drawing on Haiku actually is.
wxX11 compiles and starts but does not seem to draw correctly. It also rapidly runs into strange assertions and crashes. However, I’m not sure how well maintained wxX11 is; I didn’t compile it on Linux for comparison, so this may be not entirely unexpected behavior. (It does however seem to try to use some obscure X11 features I didn’t implement and didn’t plan on implementing. We already have wxQt in the repositories for porting wxWidgets applications and it works pretty well, so this was just for testing.)
Motif compiles and with two hacks (one to Motif, one two Xlibe) does start, but it has redraw glitches still, and most controls do not seem to respond to input.
Xterm compiles but does not start due to being unable to allocate PTYs (probably some incompatibility with our PTY layer. It seems to have a lot of ifdefs for various platforms, likely it would need some for Haiku.)
An old X11-only Fontforge build at least starts, but rapidly gets “stuck” and quits accepting input:
The main aim in this whole endeavor was mainly GTK, though. Indeed as previously mentioned, its internals are not very pretty; I would probably go so far as to call them downright ugly; in many ways it is the total antithesis of Haiku’s philosophies and designs for code. And the sheer amount of code it has is its own kind of ridiculous; when I was tracing through it last night to work around a crash caused by failing to load an image file, I wound up about 8-10 functions deep in a call stack just for loading an icon! (There were dozens of functions above that before the icon-loading code was invoked.)
But, well, plenty of major software relies heavily on GTK, including GIMP and Inkscape and Firefox, so this is an important thing to work on.
I would definitely go so far to say, though, that Xlib/X11, for all their problems (and for all I’ve made fun of them or loudly complained about them over the years, or even just in the past few weeks while working on this new compatibility layer), they are in at least some ways kind of fun to work with. (I’ve definitely had more than a bit of fun working on Xlibe so far, although some of that is due to the Haiku APIs being fun to work with.) The same cannot at all be said of GTK. I already dread opening a Debugger to delve into a GTK problem, and I’ve only just started working with GTK just in the past few days.
To put it more succinctly: GTK is just an absolute disaster of a library. Xlib is, by comparison, downright sane and reasonable. That isn’t even an exaggeration.
I made a few passes at Motif in order to get the “grunt work” out of the way (adding stubs, fixing minor bugs), but I don’t really have a lot of interest in it overall. But if @3dEyes wants to fix it and submit some PRs to me, I’ll take them. So you should watch out for him to post screenshots I suppose.
I feel for you. First small tool I made was using GTK. I ended up with more swearing comments all across the code than I could think of. Switched then to FOX library and never looked back . That said… if Xlib would be working then chances are FOX gets working too… O_O
Congratulations! Porting Motif through this compatibility layer is not recommended: if there is a way to crash or to behave mysteriously, Motif will find it. It has been well known as a torture test for X for decades, and going through a great deal of trouble to support Motif will not bring Haiku support for many significant applications.
As for Cairo (and by extension GTK), I recommend implementing the X Render Extension. The relevant documentation can be found at https://www.x.org/releases/X11R7.6/doc/renderproto/renderproto.txt, and Cairo is designed to take advantage of it whenever present. Its ubiquitousness throughout X servers has caused the non-XRender code paths in Cairo to rot, so there are certain to be many bugs there.
For GTK to work correctly, you will also need to implement the Extended Window Manager Hints, some non-standard Motif hints (they are not actually related to Motif anymore), and the ICCCM. I recommend starting with the ICCCM: It will introduce you to many concepts used in the other features mentioned here. You can find the documentation at Inter-Client Communication Conventions Manual. The X Session Management Library (www dot x dot org slash releases/X11R7.6/doc/libSM/SMlib.html) is also recommended.
GTK 4 also assumes the presence of the XInput 2 extension, which completely replaces the Core Input API. It is extremely convoluted and ugly, but it is required for GTK 4 to function, and is also recommended for running GTK 3.
Some extensions, especially the shaped window extension, can just be stubbed out, but I see you’ve already done that.
I socialized on AIX and Linux – I could happy with X forwarding.
I would really happy as Irix would be ported to a payable platform to use as server for alternative PC OSes.
I know maybe Haiku will be running earlier on Solaris machines than this dream above.
May some Irix enthusiasts discover some old/new platform to port Irix there.
Oh, I’m no stranger to X, I’ve worked with it in a variety of ways before, so I know about the ICCCM and that sort of thing.
Like I said above, I don’t intend to do much more with Motif. It actually got surprisingly far already, though, but I did have to add some hacks to make it use ZPixmaps instead of XYBitmaps.
I was hoping to stave off implementing XRender and XInput2 for now, but indeed I’ll probably have to implement them eventually. I already implemented the write half of the Motif hints, and some of the EWM hints.
Yeah, we don’t really support shaped windows on Haiku anyway, so indeed I just stubbed that out.
I wonder how clients will talk to eachother though: for example, how will one one client query a property, or select for events, off a window of another client? Does Xlibe use some interprocess communication mechanism to make that work? Or is there an existing App Server API for that which I missed?
There are some properties you can query and some events you can watch for from windows from other applications, but largely I am probably just not going to support a lot of those features. If I really had to I could do some rather clever things with BMessage passing and scripting, but I suspect it will simply not be necessary.
(If you’re unfamiliar with the scripting API’s introspection capabilities, you can play around with the hey command line tool or take a look at @X512’s rather neat TraverseApps tool. There also used to be “Clue” but I think it was never fully fixed to run on Haiku.)
Hi!
Interesting project, however one thing you have not mentionned and that would be possibly very useful is X forwarding, which would allow running apps on a Linux machine and showing their windows on Haiku. But I guess this needs an actual X server, and not just Xlib?
Yes. Some years ago I ran an X11 server on Windows, both for running some UI tool via cygwin, but also for X11 forwarding.
This is definitely an interesting project. And I agree, X11 support in toolkits is likely not going away soon. So X11 compatibility layers for different OS stay interesting. In the end also Waland is going a similar approach as well, XWayland will stay a while.
And while on any system it is always nicer to use native the UI backend, having the ability to use some legacy tools is beneficial. Not every small utility needs to be rewritten.
I’m personally looking forward to see git gui and gitk work with this
This is very exciting, but I can’t help to wish that this project won’t steal too much valuable development time of the Haiku core. I will prefer a more stable system instead of some 3rd party addition at any time. To be more fair, it will be much better if 3rd party additions will be handled via the community instead of paid development time.
I also expected X forwarding in my post above. From X11 it is the key feature – especially via ssh tunnel. I used it often as on AIX as admin CDE was not used, but for a DB server or SAP install a GUI is must have stuff . I may use a putty like program and take out the my old, faded away knowledge about it.
An additional GUI possibility would become some programs to use it user friendly as some user do not want to learn commandline and command switches or put together a POSIX command line with pipeline(s) or use awk for example.
I assume not so many users use hey scripting to file together native Haiku apps or call some bash scripts.
I would defend this effort as browsers can be tested as launched on a workstation or server grade machine but see it on Haiku.
Developers could use the server grade machine partitioned or added containers to have such different versions of Haiku environment and browser versions as well in virtual machines or containers.
Please consider this way X forwarding how to be useful can be for test environment.
For example anyone can download a prebuilt developer environment to use in quemu or a container.
Google student or some other ones who offered test something.
Not much earlier there were a post where someone asked : are ther Q&A and testers in the community : at least 3-4 people answered the calling. From my point of view if I would be dev team I would asked them to create an advisory group for testing and Q&A for Haiku and Haiku apps ported or not and create doks about Haiku environment and apps testing now even on different platforms. I assume ARM stuff and Risc-V can be prebuilt in quemu and provide for testin as-is. Testers/ developers can write what should run within and what is expected and what not. Ticket opening would be done by executioners or if tester app automatically collecting what require for developers.
Developers can have even teams to test stuff, and even automatic tools can gather or create reports for them without the tester would know much about coding.
Imagine a developer prepare new code to convert using haiku/clang format tool to convert it in a container for example first just for expected layout and the tester or developer can upload that version to review …
I assume that would accelerate the work.
I know such environment must put together, but some people offered server grade hardware yet. Its just matter of organisation to meet somewhere to install configure that server machine with containers or other virtual machines and make available with high broadband internet. May someone can offer as support or substitute money donation with such internet access.
Devs an Be Inc. members can discuss it on mailing list / IRC - I don’t wanna give more precise howto about it - they know more this better anyway.
We already have a remote app_server, and even a html5 client for that. So we really don’t need X forwarding for our applications at all. (VNC is available too iirc)
. That said… if Xlib would be working then chances are FOX gets working too… O_O
