> GTK will always owner-draw its buttons, so you don't get a real native Be widget.
Well, I think it might be potentially possible to write a theme that uses Haiku control-drawing APIs, just like for Qt (already there are some CSS files that make GTK look like Haiku, but Haiku itself has a control-theming engine, so it would be good to look into that. But not something that's on my radar.)
> And it's clearly possible to do a good-enough X server integration as demonstrated by WSL, Quartz etc with minor complaints about clipboard syncing, decorations, having to run another daemon etc.
Having used X11+WSL and X11+forwarding quite extensively (and XQuartz a bit), my complaints about that approach are ... far from minor. Everything both looks and feels like it has been awkwardly shoehorned in. Window modality, sizing, and positioning always runs into problems.
Now, some of that is just MS Windows being Windows, and X11 not having a good way to deal with some of the differences between X11 models and Windows, etc. But I think a large part of it, having looked at X11 internals (and as you can see, knowing more than a bit about them in order to write this thing and make it work) is that distinctions which are more minor at the base levels of the API become significantly bigger the further up you go -- the window manager vs. display server is probably the most obvious one here.
Xlibe can largely forget there even is a "display server / window manager" distinction and take calls that deal with one or the other and invoke the necessary Haiku APIs.
> After all that, what would you say is the main benefit to this approach?
Besides the ones outlined above, I would say it's much more possible to integrate with the rest of the system in broad ways. For instance, clipboard handling can pretend to do the strange set/get property dance in Xlibe for compatibility's sake, and then turn around and invoke the (much more sane) Haiku clipboard APIs internally. With a real X11 server, the clipboard handling is just the standard get/set property system, and you have to have something else (in the X11 server) that forwards clipboard updates in both directions. That can quickly get very complicated.
Another thing is keyboard handling. I don't bother creating X11 keymap structures at all in Xlibe; applications either get XK_* values (for e.g. Return, etc.) or UTF-8 text (which can be locale-converted if needed.) That means you can swap keymaps in Haiku and Xlibe will follow right along. I have no idea how much code that would wind up being in an X11 server port to deal with, but I know for sure it would not be fun at all, having dealt with X11 keyboard APIs from more than one vantage point.
Drag and drop would probably be another, but I didn't implement that in Xlibe (yet?)
> GTK will always owner-draw its buttons, so you don't get a real native Be widget.
Well, I think it might be potentially possible to write a theme that uses Haiku control-drawing APIs, just like for Qt (already there are some CSS files that make GTK look like Haiku, but Haiku itself has a control-theming engine, so it would be good to look into that. But not something that's on my radar.)
> And it's clearly possible to do a good-enough X server integration as demonstrated by WSL, Quartz etc with minor complaints about clipboard syncing, decorations, having to run another daemon etc.
Having used X11+WSL and X11+forwarding quite extensively (and XQuartz a bit), my complaints about that approach are ... far from minor. Everything both looks and feels like it has been awkwardly shoehorned in. Window modality, sizing, and positioning always runs into problems.
Now, some of that is just MS Windows being Windows, and X11 not having a good way to deal with some of the differences between X11 models and Windows, etc. But I think a large part of it, having looked at X11 internals (and as you can see, knowing more than a bit about them in order to write this thing and make it work) is that distinctions which are more minor at the base levels of the API become significantly bigger the further up you go -- the window manager vs. display server is probably the most obvious one here.
Xlibe can largely forget there even is a "display server / window manager" distinction and take calls that deal with one or the other and invoke the necessary Haiku APIs.
> After all that, what would you say is the main benefit to this approach?
Besides the ones outlined above, I would say it's much more possible to integrate with the rest of the system in broad ways. For instance, clipboard handling can pretend to do the strange set/get property dance in Xlibe for compatibility's sake, and then turn around and invoke the (much more sane) Haiku clipboard APIs internally. With a real X11 server, the clipboard handling is just the standard get/set property system, and you have to have something else (in the X11 server) that forwards clipboard updates in both directions. That can quickly get very complicated.
Another thing is keyboard handling. I don't bother creating X11 keymap structures at all in Xlibe; applications either get XK_* values (for e.g. Return, etc.) or UTF-8 text (which can be locale-converted if needed.) That means you can swap keymaps in Haiku and Xlibe will follow right along. I have no idea how much code that would wind up being in an X11 server port to deal with, but I know for sure it would not be fun at all, having dealt with X11 keyboard APIs from more than one vantage point.
Drag and drop would probably be another, but I didn't implement that in Xlibe (yet?)