>LOL! Do you really think I woke up one day and said "hmm, I need a GTK port. I know, I'll reimplement Xlib!" without even taking a look at the GTK codebase?
No. I would also greatly suggest against making these wrong assumptions. But from this comment it actually does sound like you didn't look at the GTK4 codebase.
>It turns out that writing an Xlib compatibility layer was, in the final analysis, a far more expedient and efficient way to port GTK.
This analysis is extremely incorrect and wrong. I'll get more into the details.
>If I went the long way around, I would have had to write probably over 100k lines of code across GTK, Cairo, and who knows how many other projects (I stopped counting how many dependent libraries I built in the first stages of this attempt.
Implementing the full X11 protocol with all the extensions and all the quirks in the server is much, more more than 100k lines. Also this entire sentence is extremely incorrect and I'm very confused as to what you were trying to do, you don't have to do anything in Cairo or Pango because those support client side rendering and have supported that for a really long time now. I assume you were basing this analysis off an ancient Haiku port or something that was trying to do things the old way? That stuff is obsolete.
>Meanwhile, Xlibe does the job with only ~7000 SLOC. That's compared to ~23000 SLOC in the "gdk/x11" folder alone
This comparison is complete nonsense. Please don't sink yourself to the level of doing this. The GDK X11 backend includes support for a bunch of extensions that you didn't implement. So no, it's not "doing the job" at all. IIRC if you look at the GTK4 backends for the more modern windowing systems (Wayland, macos) those have both shrunk to around 13000 SLOC. A native Haiku backend would probably be even shorter if you dropped all the optional features and only implemented the bare minimum, I bet you could do it in... around 7000 SLOC. There is nothing magical about any particular approach to this, it's all the same code you have to write in either case. Draw a box here, render some text here, translate these input coordinates, etc. You can't avoid this by implementing Xlib or doing any other approach.
>and all the other projects that GTK depends on which interact with the X11 layers in GDK.
Well actually those will still break with your approach if they link against the other libraries or depend on some X server functionality.
>There is a reason it took literal years to get GTK on Wayland natively...
Actually it took years because the protocol was still being worked on while the backend was being developed.
>I find that hard to believe given how deeply some of those X idiosyncrasies are embedded.
Well it's true, they were removed in GTK4, the entire rendering pipeline was rewritten.
>I didn't yet try to implement GLX but it looks more than feasible.
You could get it to work but it's not going to be feasible without also hacking the mesa implementation or re-implementing several parts of mesa yourself along with the GLX extensions. IMO this is not a good way to spend your time, please don't waste your donors' money on this. If you have a working EGL backend already you can avoid all that and just use the EGL support that GTK has already.
>But anyway, supposing you're correct: Why should I care about GTK4?
I don't know, you tell me. When you say "GTK" to me that means all versions of GTK that are currently in use by applications. If all you care about is GIMP then I would still say a better approach is to do a native backend because then you can also just skip everything that isn't used in GIMP. It's the same approach really.
>Oh, and let's not forget: with an Xlib compatibility layer, I can also get plenty of other X11-only things which otherwise I wouldn't be able to get.
Well no, this is also wrong, to get the full X compatibility (including network support) you will still need to port the full X server. And if someone ever wants that, basically all the work you did is going to be a waste and will have to be thrown out because then you're right back where you started with needing an X server. This is not a new revelation, Linux distros have been through all these conversations before, several times over the last 30 years in fact. I'm not telling you this because I'm trying to give you a hard time, I just wish other OSes would stop repeating the bad mistakes made by Linux.
>If you mean libraries like Xt, Xaw, Xmu, Xpm, etc., those just run on top of Xlib itself
No this would be the other libraries that implement protocol extensions.
>How about this: You tell me some X11 application you think I can't run under this, and we'll just see if you're wrong (or why nobody cares.)
You're being unnecessarily combative about this, please stop. I actually wish I was wrong about this, and it was as easy as you're suggesting, but experience says it's not, and also the problems that you've stated with your approach aren't helping either. But anyway, according to what you said, right now it's any application that requires XInput or XInput2 or requires 3d acceleration or wants to get run over the network. Or even just stuff like GIMP will have degraded functionality, for example you can't use drawing tablets with that right now. I would really advise against making these kind of comments if you're trying to represent a project or get more funding.
> I would really advise against making these kind of comments if you're trying to represent a project or get more funding.
Look, a little snark never hurt anybody.
The fact is that you are being extremely pessimistic about whether this will work at all, when in fact it is already being used "in production," and most of the other things you are saying are not possible or very difficult I have already investigated and made similar assessments to the ones I made before I started this.
So all evidence points to you being largely wrong, and your supreme confidence that you are correct despite all the evidence to the contrary makes it quite attractive to have a bit of fun while trying to demonstrate where you are incorrect.
That's nothing new in open source, or even software development in general, where much worse like actual insults and derogatory comments are much more an unfortunate norm, and toxicity is often the rule of the day. Plenty of stuff that goes on (or at least used to) on the Linux kernel mailing list would get you warned and then banned from Haiku's discussion channels. But at the same time, there is a place for criticism, even strong criticism, in any healthy discourse.
> But from this comment it actually does sound like you didn't look at the GTK4 codebase.
I gave it a cursory glance, but indeed I didn't look at it much in depth, because all the big GTK-based applications don't yet run on it, so it was a moot point.
> Implementing the full X11 protocol with all the extensions and all the quirks in the server is much, more more than 100k lines.
Sure, but I have already stated, multiple times, that we neither need nor want to implement all the extensions and quirks.
> you don't have to do anything in Cairo or Pango because those support client side rendering and have supported that for a really long time now.
GDK's backends presume Cairo has support for native "surfaces"; e.g. the GDK X11 backend uses Cairo's Xlib interfacing layer to draw stuff to the screen. I didn't look too closely, but the other backends seem to make similar usages on Windows and macOS. So I would have probably had to either revive the BeOS interfacing code in Cairo, or would have had to do lots of software copies in a Haiku backend of GDK in lieu of a Cairo interface.
Pango indeed doesn't deal with native "surfaces", so that wouldn't be a problem.
> I assume you were basing this analysis off an ancient Haiku port or something that was trying to do things the old way?
Nope. There may have been some work on GTK 1 for BeOS or something like that, I can't recall, but I didn't go looking for it, much less analyze it.
> The GDK X11 backend includes support for a bunch of extensions that you didn't implement.
For now. Some of those extensions (like XSync and XInput2) are probably worth implementing. This also ignores all the other X11-related code scattered throughout the GTK/GDK trees, anyway.
> A native Haiku backend would probably be even shorter if you dropped all the optional features and only implemented the bare minimum
Okay, but that's again GTK4, and totally ignores GTK2 and GTK3 which quite a lot of applications still use, and the entire point of a GTK port is to run GTK applications. Not much use in porting a version of GTK that very little supports.
> You can't avoid this by implementing Xlib or doing any other approach.
No, but I can decide that the GTK codebase is so far outside the realm of my and the other Haiku developer's programming tastes that we'd quite literally rather write an X11 implementation than deal with it. Even the minimal time I had to spend with the GTK code in a debugger while fixing incompatibilities in Xlibe was more than enough, thanks.
Furthermore, GTK is entirely C while Haiku's APIs are C++. Is GTK ever going to accept a C++ backend upstream? Almost certainly not. So if I am going to have to maintain this totally outside GTK, forever, why not do it in a way that's much more resistant to GTK changes?
And, again, there's more than just GTK here. Someone took Xlibe and apparently got some audio plugins from Linux (LV2, I think) to work with minimal code changes.
> Well actually those will still break with your approach if they link against the other libraries or depend on some X server functionality.
Again: which other libraries? You mean like Xinerama or something? If something actually needs Xinerama, or any of those other libraries, then we can implement those, too. (So far, those have turned out to be entirely optional, I haven't yet tried to build something that couldn't just disable those features.)
> Well it's true, they were removed in GTK4, the entire rendering pipeline was rewritten.
Okay. What about input events? Does GTK4 still have keysym values that map 1:1 to X11 keysyms, or did they break with that?
> Actually it took years because the protocol was still being worked on while the backend was being developed.
It's my recollection that Qt had a working Wayland backend long before GTK did. Am I incorrect?
> You could get it to work but it's not going to be feasible without also hacking the mesa implementation
I don't intend to hack the Mesa implementation of GLX, I'd just implement GLX on top of the Haiku OpenGL APIs directly (which use Mesa internally but that's an implementation detail.)
> IMO this is not a good way to spend your time, please don't waste your donors' money on this.
GLX is unimportant enough that I don't intend to spend time on it at present anyway. When/if there's a demand for it, I'll take a stab at it. But I've worked with GLX before, and I don't think it'll be nearly as much a challenge as you seem to think it will be.
> If all you care about is GIMP then I would still say a better approach is to do a native backend because then you can also just skip everything that isn't used in GIMP.
There's also Inkscape, wxGTK, and plenty of other GTK applications besides GIMP. Not to mention X11-only applications like AzPainter, etc. So it's not "just GIMP," but if whatever GTK version I'm porting, GIMP doesn't support, that's a good argument I picked the wrong GTK version.
> Well no, this is also wrong, to get the full X compatibility (including network support) you will still need to port the full X server.
Yeah, but I wasn't talking about that in the section you replied to, I was talking about things like Tk or AzPainter or the like which have X11/Xlib backends, and so by implementing this we also get those, not just GTK.
> And if someone ever wants that, basically all the work you did is going to be a waste and will have to be thrown out because then you're right back where you started with needing an X server.
Not if you port the X server using this, via Xnest! Which, like I mentioned above, I did get to compile and attempt to start but it crashed, and I decided I wasn't going to spend more than five minutes poking at it in a debugger because I didn't care enough about having X11 forwarding. If someone else wants to, then I imagine it will be much easier to patch the X server and Xlibe than writing a totally new X11 server backend for Haiku.
> This is not a new revelation, Linux distros have been through all these conversations before, several times over the last 30 years in fact.
I am quite aware, I've read some (or even many) of them.
> I just wish other OSes would stop repeating the bad mistakes made by Linux.
Hear, hear!
But this isn't one of those. As you pointed out yourself, nobody else did this before successfully; and it seems we've now already been more successful than Linux. Isn't that evidence that, just maybe, we aren't repeating a mistake here?
> No this would be the other libraries that implement protocol extensions.
As noted above, either most applications treat those as optional, or we can just implement them, too (Xft for instance would be pretty easy.)
> You're being unnecessarily combative about this, please stop.
I'm not sure why I couldn't say the same about you.
My offer still stands: tell me the name of some X11 application you think I can't run under this (obviously stuff like "window managers" don't count), and I'll make a pass at it and we'll see what happens.
> I actually wish I was wrong about this, and it was as easy as you're suggesting, but experience says it's not
I didn't anywhere say it was "easy." I'm drawing on many years of experience with both the Haiku APIs, the X11/Xlib APIs, graphics programming and widget toolkits in general, and even with that there's a lot of good old trial and error.
> But anyway, according to what you said, right now it's any application that requires XInput or XInput2
Quite literally because I just didn't implement those yet. I read through the XInput2 headers briefly and while they look particularly unpleasant in some ways, nothing looks technically impossible or even difficult, just tedious to deal with.
Plus it's another thing we would only have to do once: implement XInput2, and now all GTK applications, AzPainter, and anything else that can support it now has drawing tablet support on Haiku.
No. I would also greatly suggest against making these wrong assumptions. But from this comment it actually does sound like you didn't look at the GTK4 codebase.
>It turns out that writing an Xlib compatibility layer was, in the final analysis, a far more expedient and efficient way to port GTK.
This analysis is extremely incorrect and wrong. I'll get more into the details.
>If I went the long way around, I would have had to write probably over 100k lines of code across GTK, Cairo, and who knows how many other projects (I stopped counting how many dependent libraries I built in the first stages of this attempt.
Implementing the full X11 protocol with all the extensions and all the quirks in the server is much, more more than 100k lines. Also this entire sentence is extremely incorrect and I'm very confused as to what you were trying to do, you don't have to do anything in Cairo or Pango because those support client side rendering and have supported that for a really long time now. I assume you were basing this analysis off an ancient Haiku port or something that was trying to do things the old way? That stuff is obsolete.
>Meanwhile, Xlibe does the job with only ~7000 SLOC. That's compared to ~23000 SLOC in the "gdk/x11" folder alone
This comparison is complete nonsense. Please don't sink yourself to the level of doing this. The GDK X11 backend includes support for a bunch of extensions that you didn't implement. So no, it's not "doing the job" at all. IIRC if you look at the GTK4 backends for the more modern windowing systems (Wayland, macos) those have both shrunk to around 13000 SLOC. A native Haiku backend would probably be even shorter if you dropped all the optional features and only implemented the bare minimum, I bet you could do it in... around 7000 SLOC. There is nothing magical about any particular approach to this, it's all the same code you have to write in either case. Draw a box here, render some text here, translate these input coordinates, etc. You can't avoid this by implementing Xlib or doing any other approach.
>and all the other projects that GTK depends on which interact with the X11 layers in GDK.
Well actually those will still break with your approach if they link against the other libraries or depend on some X server functionality.
>There is a reason it took literal years to get GTK on Wayland natively...
Actually it took years because the protocol was still being worked on while the backend was being developed.
>I find that hard to believe given how deeply some of those X idiosyncrasies are embedded.
Well it's true, they were removed in GTK4, the entire rendering pipeline was rewritten.
>I didn't yet try to implement GLX but it looks more than feasible.
You could get it to work but it's not going to be feasible without also hacking the mesa implementation or re-implementing several parts of mesa yourself along with the GLX extensions. IMO this is not a good way to spend your time, please don't waste your donors' money on this. If you have a working EGL backend already you can avoid all that and just use the EGL support that GTK has already.
>But anyway, supposing you're correct: Why should I care about GTK4?
I don't know, you tell me. When you say "GTK" to me that means all versions of GTK that are currently in use by applications. If all you care about is GIMP then I would still say a better approach is to do a native backend because then you can also just skip everything that isn't used in GIMP. It's the same approach really.
>Oh, and let's not forget: with an Xlib compatibility layer, I can also get plenty of other X11-only things which otherwise I wouldn't be able to get.
Well no, this is also wrong, to get the full X compatibility (including network support) you will still need to port the full X server. And if someone ever wants that, basically all the work you did is going to be a waste and will have to be thrown out because then you're right back where you started with needing an X server. This is not a new revelation, Linux distros have been through all these conversations before, several times over the last 30 years in fact. I'm not telling you this because I'm trying to give you a hard time, I just wish other OSes would stop repeating the bad mistakes made by Linux.
>If you mean libraries like Xt, Xaw, Xmu, Xpm, etc., those just run on top of Xlib itself
No this would be the other libraries that implement protocol extensions.
>How about this: You tell me some X11 application you think I can't run under this, and we'll just see if you're wrong (or why nobody cares.)
You're being unnecessarily combative about this, please stop. I actually wish I was wrong about this, and it was as easy as you're suggesting, but experience says it's not, and also the problems that you've stated with your approach aren't helping either. But anyway, according to what you said, right now it's any application that requires XInput or XInput2 or requires 3d acceleration or wants to get run over the network. Or even just stuff like GIMP will have degraded functionality, for example you can't use drawing tablets with that right now. I would really advise against making these kind of comments if you're trying to represent a project or get more funding.