4 ms·

>Too late, I did This reply makes no sense, I would greatly advise against falling for the sunk cost fallacy. If all you care about is GTK, then you could have

>Too late, I did This reply makes no sense, I would greatly advise against falling for the sunk cost fallacy. 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. With GTK4 it should be even easier because the backends were simplified and a lot of the weird X idiosyncrasies were removed, and you might actually have a chance to get hardware acceleration to work without having to go through the pain of dealing with GLX. The problem with Xlib is that's is not just the one library, it's actually about 30 libraries. So like I was saying earlier, it's cool that you have one, but the hard and annoying part that isn't worth it is doing the other 29. Nobody has gotten that far, and if you do get that far, the best way to do it would be to copy a huge amount of code. So the goal here can't really be reached in any practical terms, unless you just want to stop here.

yyyk 4y ago
It isn't practical to write a port even for every major GTK version, much less for every other toolkit used with X11. Firefox for example is still on GTK3, and so are many other applications. Haiku should want some form of generic compatibility, and this is one way to do it (I would have been lazy and used the embedded X server approach for it if I wanted to do it for some OS, but waddlesplash apparently has different tastes). Perhaps one day someone will want to do the work for a 'native' GTK4 port, but that does not degrade the important of this work for Haiku.
- throwaway82652 4y ago
  Using a hack of Xlib to port firefox is probably the worst possible approach, your rendering performance will be horrible and you still get to deal with the pain of the impedance mismatch from using a different API from what your system is designed to do. I get the desire to take shortcuts to get things ported quickly but that will not actually help in making these applications properly usable.
  - yyyk 4y ago
    Firefox was just one example. There's no practical way to port everything a user might desire - everyone has their own 90% as the saying/joke goes. Haiku needs a generic mechanism, and well, this is one way. Apparently waddlesplash likes this way, and is willing to invest doing the work. This is commendable and will help Haiku adoption. It's also technically interesting and cool enough for a HN post. I will say that I don't think it's the best path for an alternative OS, and other AltOSs might wish to pick a different path. IMHO, Reimplementing POSIX is a mug's game, a lot of work, while Linux will always be ahead and POSIX isn't much good anyway. Microsoft showed the way with WSL2. This would be a better path for alt OSs in general: A. Implement the OS with almost no compromises. Ignore POSIX/X11/etc. if they don't match the vision. B. Port/Create a few application to show and use the benefits of the OS and whatever it brings to the table. C. Implement an equivalent of WSL2 which should give broad compatibility at the relatively low cost of keeping up with a Linux kernel, given the kernel's rather good backward compat record we wouldn't have to be very prompt with porting new versions. At which point users would have a good reason to use the OS (B.) and no practical shortage of apps (C.) even if the experience with these apps would be somewhat lacking. One can then concentrate on improving the OS or on porting the most used applications. This acts like a Cuckoo - in the beginning, there'll a mostly Linux userland with a few AltOS apps. Eventually one ports enough so that the system is really AltOS with a few Linux apps on the side.
toast0 4y ago
I don't know how much work it was to do what waddlesplash has already done, but it seems like it's enough for GTK3, and almost enough for Xnest. If they get Xnest to work, then they can use that for anything that is doesn't use xlib, which sadly isn't a lot[1]. Maybe GTK4 would be easier to build a Haiku backend for (as was done for QT), but that doesn't help anybody run GTK3 applications on Haiku does it. [1] xlib is kind of terrible IMHO; it adds mandatory abstractions that are superfluous at best and in many cases (again IMHO) harmfully force synchronicity on the asynchronous protocol that is X11. Lots of xlib based programs wait for a response when they have other things they could be doing, and the result is poor experiences blamed on X, when xlib's fault. sigh
- lloeki 4y ago
  > xlib is kind of terrible IMHO [...] force synchronicity on the asynchronous protocol that is X11. Lots of xlib based programs wait for a response [...] Was fixing that the intent behind libxcb? (honest question, my understanding of X stuff is limited, I just feel to recall Awesome depends on libxcb instead of xlib and read some vague blurb about it back then)
  - waddlesplash 4y ago
    > Was fixing that the intent behind libxcb? Yes. Like I noted in another comment, XCB is basically just a loose wrapper around the X11 protocol. It is indeed a lot more verbose than Xlib, and modern Xlib is actually written on top of XCB, so you can use the two in the same application on the same X11 context if you really need to for some reason.
waddlesplash 4y ago
> 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.)

yyyk 4y ago

It isn't practical to write a port even for every major GTK version, much less for every other toolkit used with X11. Firefox for example is still on GTK3, and so are many other applications. Haiku should want some form of generic compatibility, and this is one way to do it (I would have been lazy and used the embedded X server approach for it if I wanted to do it for some OS, but waddlesplash apparently has different tastes). Perhaps one day someone will want to do the work for a 'native' GTK4 port, but that does not degrade the important of this work for Haiku.

throwaway82652 4y ago
Using a hack of Xlib to port firefox is probably the worst possible approach, your rendering performance will be horrible and you still get to deal with the pain of the impedance mismatch from using a different API from what your system is designed to do. I get the desire to take shortcuts to get things ported quickly but that will not actually help in making these applications properly usable.
- yyyk 4y ago
  Firefox was just one example. There's no practical way to port everything a user might desire - everyone has their own 90% as the saying/joke goes. Haiku needs a generic mechanism, and well, this is one way. Apparently waddlesplash likes this way, and is willing to invest doing the work. This is commendable and will help Haiku adoption. It's also technically interesting and cool enough for a HN post. I will say that I don't think it's the best path for an alternative OS, and other AltOSs might wish to pick a different path. IMHO, Reimplementing POSIX is a mug's game, a lot of work, while Linux will always be ahead and POSIX isn't much good anyway. Microsoft showed the way with WSL2. This would be a better path for alt OSs in general: A. Implement the OS with almost no compromises. Ignore POSIX/X11/etc. if they don't match the vision. B. Port/Create a few application to show and use the benefits of the OS and whatever it brings to the table. C. Implement an equivalent of WSL2 which should give broad compatibility at the relatively low cost of keeping up with a Linux kernel, given the kernel's rather good backward compat record we wouldn't have to be very prompt with porting new versions. At which point users would have a good reason to use the OS (B.) and no practical shortage of apps (C.) even if the experience with these apps would be somewhat lacking. One can then concentrate on improving the OS or on porting the most used applications. This acts like a Cuckoo - in the beginning, there'll a mostly Linux userland with a few AltOS apps. Eventually one ports enough so that the system is really AltOS with a few Linux apps on the side.

toast0 4y ago

I don't know how much work it was to do what waddlesplash has already done, but it seems like it's enough for GTK3, and almost enough for Xnest. If they get Xnest to work, then they can use that for anything that is doesn't use xlib, which sadly isn't a lot[1]. Maybe GTK4 would be easier to build a Haiku backend for (as was done for QT), but that doesn't help anybody run GTK3 applications on Haiku does it. [1] xlib is kind of terrible IMHO; it adds mandatory abstractions that are superfluous at best and in many cases (again IMHO) harmfully force synchronicity on the asynchronous protocol that is X11. Lots of xlib based programs wait for a response when they have other things they could be doing, and the result is poor experiences blamed on X, when xlib's fault. sigh

lloeki 4y ago
> xlib is kind of terrible IMHO [...] force synchronicity on the asynchronous protocol that is X11. Lots of xlib based programs wait for a response [...] Was fixing that the intent behind libxcb? (honest question, my understanding of X stuff is limited, I just feel to recall Awesome depends on libxcb instead of xlib and read some vague blurb about it back then)
- waddlesplash 4y ago
  > Was fixing that the intent behind libxcb? Yes. Like I noted in another comment, XCB is basically just a loose wrapper around the X11 protocol. It is indeed a lot more verbose than Xlib, and modern Xlib is actually written on top of XCB, so you can use the two in the same application on the same X11 context if you really need to for some reason.

waddlesplash 4y ago

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