Ladybird already uses some external libraries, such as Qt.
Many commentators have said that the operating system is just this vestigial thing to prop up the browser, a solved problem, over which it is not worth experimenting or trying to make better. This is hardly something you would expect the creator of an operating system to believe, but here we are.
Now Iām off to browse Gemini capsules with 9Frontā¦
He is working from Linux. He has not booted Serenity in a while, his only contact with Serenity is in the form of āsigh, this thing doesnāt build on Serenity on the Github continuous integration and Iām not motivated to fix it myselfā. Also, he got donations to work specifically on the browser and not the OS.
It seems clear at this point that 1) he found a market and people willing to donate money for the browser, not really for the OS and 2) he lost interest in the OS, which was a nice toy project for a while, but not much more than that.
Why would you demand that he keeps maintaining the Serenity port? I think this would only lead to burn out. If youāre not interested in a project, youāre not interested. Unless someone is going to pay you to continue doing it anyway, thereās no reason to continue.
Iām sure things will settle and maybe someone from the Serenity team will step up to maintain the Ladybird port. Or maybe they will decide they donāt need a web browser, or pick another one.
Also, if I understand correctly, Ladybird is a Qt based browser and never ran on top of Serenity. All they share is a HTML/CSS/JavaScript engine (LibWeb), that is used by both Ladybird and Serenity browser. Why would you maintain a Qt based browser that doesnāt run on Serenity inside the Serenity github repository? It would be like having Qt applications inside the Haiku sourcecode repository.
It seems clearly a point where the projects have diverged so far that they share nothing but a git repository. You say itās just a build infrastructure problem, but I see quite the opposite: two largely independant projects that end up stuck together by sharing only the build infrastructure. They have separate websites, separate READMEs in the Git repository, and, at this point, separate developers. Itās time to admit they are separate projects and cut the last link, donāt you think?
I get the feeling more and more that Iām misunderstanding somethingā¦
Iāve read a few times now that SerenityOS and Ladybird are totally different projects that need to be separated,but from my understanding they mostly share the exactly same codebase.
Developing a browser UI on top of a rendering engine isnāt a big deal,as the dozens of QtWebKit and GTKWebKit ports in the HaikuDepot show.
The difficult task is creating and maintaining a web engine,such as LibWeb,that is capable of rendering modern websites without huge issues.
And that effort with LibWeb was shared between SerenityOS and Ladybird,which was a good thing as it is a lot of work.
Now how is that supposed to continue?
Will LibWeb become a part of Ladybird and SerenityOS wonāt have a browser at all?
Thatās what I thought when first reading this topic,but I canāt imagine why the SerenityOS devs would want that.
Or will they both have their own variant of LibWeb,forked at one date and then developed independently from each other?
That would duplicate the needed effort,also a bad idea in my view?
Or will they continue to use one LibWeb that they share,and only the Ladybird UI/frontend code it moved into a separate project?
Thatās what it looks like when reading the last reply here,but as a browser UI isnāt that much of a big deal,I also donāt get where the benefit would be.
Does anyone actually know whatās going on and can tell me?
Based on what some SerenityOS maintainers have been saying so far in the SerenityOS Discord community, it sounds like changes from Ladybird will be backported to SerenityOS where possible.
Thanks,thatās good news.
If Ladybird changes in a way that makes cross-platform support more complicated (by requiring more third-party stuff or something like that),we can base our port on SerenityOS code and will still get a good browser.
Some more discussion has occurred and it seems like itāll go both ways. That is, changes in either will be cherry-picked to the other where appropriate. However, itās prolly better to focus more on the Ladybird codebase. Itās considerably more preferable to not have an entire OS codebase being pulled into HaikuPorts just for a web browser.
Well,that depends on where development goes.
Iād prefer to avoid Linux-style dependency hell where I can,and currently the SerenityOS code is very portable and independent.
Maybe Ladybird will keep that route,weāll see.
No, Ladybird has multiple UIs.
I think they are cross-platform Qt, macOS AppKit, and Android UI.
The Serenity OS browser code is entirely specific to Serenity OS. Ladybird instead uses Qt which makes it possible to run it on Haiku (as well as a few other frontends, yes, forgot about these in my previous comments). The libweb part is made to be more portable, but itās reasonable to think that this is not going away especially in Ladybird, which has plans to support multiple OS (on the Serenity side they may chose to take some shortcuts and simplify it by making it OS specific). From what I understand, other purts (GUI and network backend) of Ladybird are already based on 3rd party libraries.
If anything, reusing existing 3rd party libraries (letws say: curl, openssl, ā¦) is making our job easier for an Haiku port if we already have those. With no details so far about which libraries Andreas plans to use, itās hard to say anything. Will it be curl, openssl and the like? Will it be a switch to webkit? (Unlikely I think, but the statements Iāve seen so far donāt rule it out). Will it be relying more on Qt? Will it be some weird library that no one knows about and that is extremely tied to Linux? We have to wait a bit and see what happens, but if the project remains as it was before (Qt gui and libweb backend), With the occasional extra dependency (maybe libpcre for regex, boehm for garbage collection, that kind of thing (these are completely random guesses, but itās the type of thing I could reasonably imagine)), I donāt think we should have much problems for an Haiku port.
Git is git. If you have a public repo he should be able to get the changes. If it is because there is no PR on github, maybe someone can fork it and submit a PR on your behalf?
I have forked so many projects and re-hosted them on Github, locally via something like Gittea or at work where we have a self hosted Gitlab instance. The actual underlying repo will absolutely be in a format he can access - the āgetting it to himā part is just about making a PR that he can easily get access to.