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:
Awesome progress! I wonder if it is possible to change the widget look to be more native?
GTK supports theming, yes. @3dEyes took the time to install a Haiku-like theme for his demos; I haven’t bothered with that for the present.
Another update: a number of patches to GTK itself were required in order to avoid having to implement the full XKB structures (which basically nothing else seems to make use of), in addition to a variety of patches to Xlibe, but now keyboard events largely work; only Ctrl/Cmd-based shortcuts do not seem to activate for some reason (however, they also apparently do not work in Tk, so there is likely some common cause.)
Try using DispatchMessage instead of MessageRecieved to handle keyboard messages.
The same way you should handle B_UNMAPPED_KEY_UP/B_UNMAPPED_KEY_DOWN also.
Yes, I’ve just remembered that, and have over half of it written already. 
Done. Now Cmd-key shortcuts work in GTK windows. Next I should probably implement some or part of pointer grabs so it stops crash-asserting on menus, and figure out why windows seem to have no title most of the time.
Can you provide GTK build instructions to be used with Xlibe?
Would it be possible to use Haiku font rendering in GTK applications? Looks like X11 an Tk applications already use native rendering?
At present it requires a number of hacks and some other patches that I only have locally (for example, fixing the build without XSync, though I probably should just add compatibility stubs for this; and now more importantly, calling Xlib to do key-event translation instead of reading the XKB tables directly.) I will post these somewhere before too long, but not just yet.
Indeed they do.
Unfortunately I don’t think it is, at least that I can see. While there is some Xft code in GTK it appears to just be used to get certain settings (e.g. antialiasing on/off) and not to do any actual font rendering that I can see 
As far as I know, starting from GTK 2 all rendering is done offscreen using cairo, including font rendering. The only X11 rendering method GTK uses is XPutImage.
Doesn’t it can use XRender?
No and Yes 
Cairo has several rendering backends. Software rendering is pretty fast, robust and portable (I really love it, tbh). There are pdf, svg, ps, OpenGL, OpenVg backends… more or less maintained. And there is also a Xlib/XRender (where available).
Not sure if there is a way to force Cairo to work with a specific backend. Not sure also if Xlib backend relies on Xlib to render fonts.
It’s going to be great to get GTK working on Haiku and great apps like GIMP ported.
GTK font rendering is done exclusively through Cairo, yes, but if someone cared to resurrect the native BeOS backend for Cairo I think it would be possible to write a BFont font driver for Cairo.
GTK 2 doesn’t do offscreen rendering by default, it draws to a cairo xlib surface. Ditto for GTK 3.
Congratulations on everything that you have done so far. (pat on back to you). Anything that makes Haiku more interesting, fun, and where I can actually --work-- in Haiku is VERY much appreciated.
I --used-- to be a programmer (too long of a story) and I can follow most of what you are talking about so it is fun to read your posts. If this helps encourage you on days (and nights) where you don’t feel as much like coding and working on this as others, then this post will be of some value.
@waddlesplash
It would be terrific if you could complete this ticket https://dev.haiku-os.org/ticket/2657 while you’re at it, and add it to the port.
So far, nothing actually needs XSI shared memory. X11 uses it internally of course, but Xlibe can just use Haiku’s shared memory routines instead.