5 ms·

> If all you care about is GTK, then you could have just done a native port of GTK. That would actually be a lot easier than trying to reimplement every X clien

> If all you care about is GTK, then you could have just done a native port of GTK. That would actually be a lot easier than trying to reimplement every X client library. 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? Of course I looked at the GTK codebase, and so did a number of other Haiku developers, and we came to the conclusion that writing a native Haiku backend would be a ridiculously unpleasant task (as one other Haiku developer pointed out, GDK backends are typically > 1 MB of source code, and in a dialect of C that I am, uh, if I put it politely, not a fan of.) It turns out that writing an Xlib compatibility layer was, in the final analysis, a far more expedient and efficient way to port GTK. 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.) Meanwhile, Xlibe does the job with only ~7000 SLOC. That's compared to ~23000 SLOC in the "gdk/x11" folder alone, not to mention all the other X11-related files scattered around the GDK and GTK source trees, or all the ifdefs throughout the codebase, and all the other projects that GTK depends on which interact with the X11 layers in GDK. There is a reason it took literal years to get GTK on Wayland natively... > With GTK4 it should be even easier because the backends were simplified and a lot of the weird X idiosyncrasies were removed I find that hard to believe given how deeply some of those X idiosyncrasies are embedded. But anyway, supposing you're correct: Why should I care about GTK4? Even GIMP of all projects, the (more or less) flagship GTK application and one of the primary reasons a GTK port is generally desirable, has decided that for now, a GTK4 port is "out of scope" (no, really [1]) at least for the immediate future. So even if a GTK4 port was more technically feasible, why exactly would I care if none of the software I want runs on GTK4? Oh, and let's not forget: with an Xlib compatibility layer, I can also get GTK2 and then whatever applications are still stuck on that; plus plenty of other X11-only things which otherwise I wouldn't be able to get. [1]: https://gitlab.gnome.org/GNOME/gimp/-/issues/6440 https://gitlab.gnome.org/GNOME/gimp/-/issues/6440 > you might actually have a chance to get hardware acceleration to work without having to go through the pain of dealing with GLX I didn't yet try to implement GLX but it looks more than feasible. Sure, it's not the most pleasant of APIs to deal with, but implementing it doesn't look so bad. > The problem with Xlib is that's is not just the one library, it's actually about 30 libraries. If you mean libraries like Xt, Xaw, Xmu, Xpm, etc., those just run on top of Xlib itself, they don't interact with the X11 protocol directly, and so I can and did build and use those unmodified directly from X.org. For all they know they are running with a strange X11 server that provides an odd but completely valid featureset. Xeyes, which you can see a screenshot of in the README, uses Xt and Xaw, so clearly those work already in this environment. > Nobody has gotten that far, and if you do get that far I think I have gotten "that far." I can run Xt/Xaw applications (albeit with a few font rendering glitches, though I just didn't bother to patch that), I can run GTK, and sure, I didn't implement every single drawing mode or every quirky feature, but I don't really care about running Motif, so why does that matter so much? > So the goal here can't really be reached in any practical terms, unless you just want to stop here. 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.)

throwaway82652 4y ago
>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.

throwaway82652 4y ago

>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.