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)
Just womdering would it be possible to compile a clone of Amiga Dopus4 commander named Worker that based on Xlib ?
Sorry for a newbie who I am.
I hoped Linux old experts behaviour I would not meet here.
Thanks for understanding.
I love that desktop environment 
Then this implementation can be feel at the end as the compiled software was native? As i understand, you are translating the instruction (?
I am so excited about this work, and this lib is a dependencie for Wine, i know wine need more than just the xlib but hey, now we are more close to this too.
Excelent work thank you so much.
This work is unlikely to bring wine any closer.
If somebody would be interested in porting wine could already progress to get CLI windows programs running. But seemingly nobody interested in doing any work, just in wishful thinking. Having an xlib wrapper/compatibility layer wont necessarily generate any breakthrough on this front.
@zelenoviy had initial wine port running cmd.exe about 10 years ago. Recently @3dEyes compiled wine with a very small patch but it crashes on start. Some kernel changes are needed to support wine. Basically, we need almost the same Serenity needs to get wine going https://github.com/SerenityOS/serenity/issues/6410
This looks like a great project-experiment, congratulations, it’s great that you entered the arena.
Have fun!
I mentioned it briefly in one of my replies above: “Xnest” appears to be the X.org X11 server running atop Xlib. However, based on the documentation and other details I found online, it does not seem to support “rootless” mode (and it seems Xephyr doesn’t either?) making it maybe less useful than it could be. I didn’t try building it myself, yet.
Building a “protocol inverter server” for Xlib, that turns X11 requests into Xlib calls, should be possible (or enhancing Xnest itself to support rootless mode.) I don’t have a lot of interest in that myself however, and while potentially useful it seems like a more niche case, so I don’t think I’ll wind up spending time on that. Or at least not contracted time anyway.
Those already work with the SDL2-based Tk package already available in the repositories, but it doesn’t support “rootless” mode, so it is kind of annoying to use applications that way, yes.
There is a certain tradeoff between stabilizing the system and making sure software is available for it. I spent the last few months on stabilizing in various ways (fixing lots of KDLs, the new NTFS driver, etc.), and things are much better than they were when I started, so now I figured it would be good to spend some time on porting software people have wanted for a long time. Haiku needs both to be generally viable.
Well, Xlib and GTK and related matters are all very complicated things which not a lot of people have the expertise and the time to tackle. At least for Xlibe, I am using quite a lot of knowledge both about Haiku itself, and about X11, and also about UIs and mapping and compatibility layers that I acquired over a period of years. While I’m far from the only person who could tackle this endeavor, I would estimate that there are not a lot of people who could, but whether they have the time (and interest) is another matter. So it seems to make the most sense for me to be the one to work on this, at least in these initial stages, as it will benefit not just a few users or developers but the whole community (and plenty of potential future users too.)
I’ve actually been keeping an eye out for things that use just plain Xlib and not some higher toolkit to use as testcases (Tk was originally good for that), so I might try both of these out and see what they uncover. 
It will probably be useful to get GUIs working with WINE once we do get main WINE working though. I do intend to look at WINE at some point, or rather the changes we have to make in Haiku itself to get it to work. I think we are just missing some fields from the signal context structures…
I’ve actually been keeping an eye out for things that use just plain Xlib and not some higher toolkit to use as testcases (Tk was originally good for that), so I might try both of these out and see what they uncover.
Emacs is a great program to use for that: the native port aside, you can build Emacs with “–with-x-toolkit=none --with-x --without-cairo --without-xft” to get a build of Emacs that only uses Xlib.
Yes, I know, but to be honest this is really awkward to use 
The X11 compatibility layer might yield better results once it is working.
I’m sure they’ll be some blasphemy called here, but this is a great stepping stone for an initial WINE port. Whilst many a moon ago, POSIX was a big stumbling block, the work done on POSIX in recent years probably largely makes that point moot. X11 is probably the biggest issue to getting an initial WINE port working now.
What is the point of guessing?
Last time I checked the biggest issues were still declared to be adress space layout and some signal stuff, aswell as registers.
Wine world just fine in headless mode, so someone should figure that out first.
Good day @waddlesplash ,
Great work you are doing with X. Having inkscape, gimp and Firefox on Haiku would reduce the need of using other oses. I personally use inkscape a lot so right now I switch back and forth quite more than what I would like.
Really appreciate your work on this topic.
Regards,
RR
Agree! This would be amazing.
I have fixed the redraw glitches (this was actually partially a problem in Haiku itself; I pushed some patches to Gerrit to resolve it), the hangs on mouse click events (the mouse now mostly works), and crashes on key events (however keyboard input does not work yet.) After a few other compatibility fixes, the “widgets” demo starts and displays largely correctly:
