12 ms·

I hate to be the one who has to say this, but this is a bad idea. If this is being done for practical reasons then don't waste your time with this. It might wor

I hate to be the one who has to say this, but this is a bad idea. If this is being done for practical reasons then don't waste your time with this. It might work for some clients but you'll get stuck in the same place that every other re-implementation of X11 over the last 30 years got stuck at, which is supporting any kind of weird quirky behavior in Xlib and its large collection of client libraries, and the rest of the quirky behavior in the X server. Eventually you'll end up copying large sections of code out until it slowly transforms back into Xlib and Xorg and effectively it becomes another approximation of an X server. If that's fine with you then by all means keep going, but please don't continue along with the idea that you can avoid this. It has been tried many, many times before.

waddlesplash 4y ago
> If this is being done for practical reasons then don't waste your time with this. Too late, I did, and it's already being used "in production" to power GTK on Haiku! > It might work for some clients Well, GTK was the one client I really cared about, and it works for that, so... It should work for Tk, too, but there's one really annoying bug somewhere in Xlibe which is causing Tk problems; and I didn't figure out what it was in the Tk codebase (this is doubly strange because Tk itself has Xlib compatibility layers to run on other OSes, you would think they would have excised any such quirky behavior.) The "AndroWish" developer said he'd try to take a look and figure out what was going on, at some point. > you'll get stuck in the same place that every other re-implementation of X11 got stuck at So far as I've been able to tell, this is now the single most advanced Xlib compatibility layer ever written (well, that's publicly available and locateable, anyway. I wouldn't be surprised if there's more advanced ones behind closed doors.) At least, I don't see any others powerful enough to run GTK, do you? So I think I've not gotten stuck at that same place then!
- throwaway82652 4y ago
  >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.
- electroly 4y ago
  I'm curious why this approach was chosen for GTK, whereas Qt was ported directly. Is there some detail about GTK that made the approach taken with Qt infeasible?
  - waddlesplash 4y ago
    Yes: the GTK codebase is, uh, not fun to work with and write backends for. See my comment above (https://news.ycombinator.com/item?id=31192099 https://news.ycombinator.com/item?id=31192099) and also one of my replies on the Haiku forums (https://discuss.haiku-os.org/t/xlibe-an-xlib-x11-compatibility-layer-for-haiku/11692/4?u=waddlesplash https://discuss.haiku-os.org/t/xlibe-an-xlib-x11-compatibili...) for more details.
    - electroly 4y ago
      7 kLOC is a lot smaller than I had guessed this must have been. Pretty cool!
AshamedCaptain 4y ago
I am not even sure about what quirks you mention from Xlib. That said, I do think that having this server-less is going to be challenging. Even if the author claims this would ease things like DnD, I am not entirely convinced...

waddlesplash 4y ago

> If this is being done for practical reasons then don't waste your time with this. Too late, I did, and it's already being used "in production" to power GTK on Haiku! > It might work for some clients Well, GTK was the one client I really cared about, and it works for that, so... It should work for Tk, too, but there's one really annoying bug somewhere in Xlibe which is causing Tk problems; and I didn't figure out what it was in the Tk codebase (this is doubly strange because Tk itself has Xlib compatibility layers to run on other OSes, you would think they would have excised any such quirky behavior.) The "AndroWish" developer said he'd try to take a look and figure out what was going on, at some point. > you'll get stuck in the same place that every other re-implementation of X11 got stuck at So far as I've been able to tell, this is now the single most advanced Xlib compatibility layer ever written (well, that's publicly available and locateable, anyway. I wouldn't be surprised if there's more advanced ones behind closed doors.) At least, I don't see any others powerful enough to run GTK, do you? So I think I've not gotten stuck at that same place then!

throwaway82652 4y ago
>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.
electroly 4y ago
I'm curious why this approach was chosen for GTK, whereas Qt was ported directly. Is there some detail about GTK that made the approach taken with Qt infeasible?
- waddlesplash 4y ago
  Yes: the GTK codebase is, uh, not fun to work with and write backends for. See my comment above (https://news.ycombinator.com/item?id=31192099 https://news.ycombinator.com/item?id=31192099) and also one of my replies on the Haiku forums (https://discuss.haiku-os.org/t/xlibe-an-xlib-x11-compatibility-layer-for-haiku/11692/4?u=waddlesplash https://discuss.haiku-os.org/t/xlibe-an-xlib-x11-compatibili...) for more details.
  - electroly 4y ago
    7 kLOC is a lot smaller than I had guessed this must have been. Pretty cool!

AshamedCaptain 4y ago

I am not even sure about what quirks you mention from Xlib. That said, I do think that having this server-less is going to be challenging. Even if the author claims this would ease things like DnD, I am not entirely convinced...