For the first time, most of the work I did as part of this contract was not in the month’s activity report aside from a passing reference, as nearly all of it took place outside the main Haiku source tree. So, here I detail it; and thanks once again to the generous donations of readers like you (thank you!).
XLibe is pretty dang cool. I’m not sure which “frontend” currently in progress is the more useful for Haiku, however. In terms of “open” applications, there’s certainly a good few I use regularly that are GTK native - but ones I would want on a Haiku desktop are fewer. Evolution, GIMP and Inkscape are probably the most notable. Wine is probably the more appealing to me, given how much upstream effort is currently going into it by companies such as Valve. So, a native Wine is also interesting - but Xlibe has clearly made that happen quicker than it might have otherwise.
Though this talk of X and Windows now makes me think about X Forwarding and RDP, and wanting a remote-desktop-to-Haiku system, since it’s something I use heavily, and the main reason I use Windows at home and work.
R3, maybe for that one. 
Actually Haiku has a very good remote desktop system in the app_server and there was even an HTML5 client though maybe right now it is quite stale. I don’t think much of this is well documented, it is something I wanted to dive into the next chance I have for serious Haiku development, which might be soon…
Edit: Here is an article on it, though it is pretty old I think and doesn’t have a ton of detail: Using the remote app server | Haiku Project
Also some of the limitations sound a bit annoying, like not being able to have the same app on each “screen”.
I couldn’t find an emoji for “shocked to death”, so you’ll just have to picture it. Colour me stunned.
It’s not wrong… Though, this isn’t quite the feature I make heavy use of. I’m very much a “thin client” kind of worker, and I often connect to my PC’s from elsewhere to access “what I’m working on” from another location. At work it’s commonly used to tweak network or permissions settings for a user, while I’m sat at their workstation.
Or in other words, I’d want persistence of session like Windows RDP, rather than remote execution like X11. This is nonetheless very cool, and encouraging that it could be extended in future. I’ll have to play with this!
I completely agree with you, I think the former is much more useful. I assume there isn’t a huge reason it couldn’t be done that way, or at least have the option to do both, sort of like how you can (on most systems at least, not Haiku yet) mirror dual screens or have each be their own screen. As noted I’ve wanted to look at this for a while so I’ll play with it. Someone else here (like @waddlesplash) might know more of the details though.
Either way, thanks for the heads up on this!
You didn’t say “Haiku Terminal Server”.
But I heard “Haiku Terminal Server”.
mo-g, a Haiku Terminal using RDP to connect to is quite possible with Virtualbox. I have a desktop computer running Linux and on top of that lots headless virtual machines with RDP enabled.
It’s indeed more than possible given how app_server is architected, in my understanding, but it will of course require a bunch of work to get there. As it’s quite a niche use case, I certainly don’t have any kind of plans to work on it. VNCServer is “good enough” for some of those use-cases anyway.
As always, kudos for all your work and report.
Please, don’t focus on report length. We appreciate you primarily for writing the code and not for lengthy reports. Of course, I wait every month a new report, but I understand that even very large work, very difficult and time consuming issue can be described in just few words. And this in no way minimizes your contribution as Developer, maybe only as Writer, but this is less important 
Thanks for the report and your hard work! While I don’t regret a single dollar of my monthly donations that I restarted to support your full-time contract, I do hope you find your way out of that X11 work soon.
I can imagine that it could take months to work out all the kinks of that compatibility layer and there always being that one more thing to make it better.
I understand that many people are keen on such a compatibility layer, I’m just not one of them. Maybe, after you’ve done the heavy lifting of its introduction, its further development can become a “3rd party opportunity” and interested people can contribute directly or try that old schtick of crowdfunding a developer for it…
As it should be!
Great progress! Keep going.
Ok, my second attempt…
Can you take a look at QtWebEngine and try to fix crashes? It would be nice! It’s very necessary. Whole community will say thank to you!
And it will be BIG plus for future beta release. Modern fully functional browser - Falcon!
Great report waddlesplash.
Great to see your progress!
I’ve set up a monthly donation today and hope that you will look in to hardware improvements as well, like USB audio and HiDPI screen, and hopefully I will find a laptop I can install Haiku on. The Haiku installer doesn’t support the SSD on the laptop I have…
My intention is to switch back to other things once it’s stable enough to post it as a GTK port (and maybe also Tk.)
I do intend to do that at some point, but after I switch off Xlibe I imagine that beta4-related matters will start taking up my time (there are a number of regressions that need to be investigated.) Not sure if QtWebEngine stuff will make it in to my schedule before the beta…
Right now, I think @rudolfc is looking at that, though I’m helping him out with lower stack issues as he runs into them. (Though he is looking at USB 2.0 audio, not USB 1.1 audio which makes up the majority of adapters out there … maybe he can be persuaded to do both, though )
This is indeed on my TODO list, having a HiDPI screen myself. There is one major change related to this I hope to get in before beta4 as it will constitute a minor API break, actually.