Then I wait for 32bit LadyBless3d 
Did you already try compiling my patched codebase on 32bit Haiku?
I have only 64bit devices here,but I think it should work using the modern compiler.
GCC13 is required to build Ladybird,from what Iāve seen on HaikuDepot thatās also available on 32bit.
At least Iāve seen on all screenshots - there are 2 additional menupoints : āEditā and āViewā
so besides the engine score points improvements the browser itself has improved a lot.
View may contain some sizeing features
and
Edit may contain basic text/picture editing possibilities ā¦
How large are the SerenityOS libraries? I guess theyāre still handling drawing, and the like?
If we could make things sufficiently ānativeā, maybe thereād be some argument for using Ladybird as the backend for WebPositive instead of WebKit. Seems much easier to maintain a port, and while it does support fewer web standards, it seems to be getting better at a pretty amazing rateā¦
8 Likes
I donāt think thatās a good idea. Itās too fast developing project and its api is very unstable. In addition, I doubt that the total of all the libraries needed will be smaller than webkit.
3 Likes
Decided to replicate the interface of the old BeOS browser NetPositive. Implement the standard SAT mechanism instead of tabs. Hereās what Iāve got so far:
35 Likes
Can we please stop this āanything but WebKitā approach to web browsers? It is very annoying and Iām starting to take it personally. Do you have specific complaints about WebKit or the way we handled our port? Or is it just āoh, shiny new engine over there!ā?
8 Likes
May I suggest restoring the old good replicant feature? It would be great for third-party apps being able to embed a web view.
One use case that comes to mind is showing the documentation of a class or method in Genio.
6 Likes
It seems unlikely to me that ladybirdās engine could do any better than WebKit for daily use.
However, I can see some potential in having a lightweight alternative for browsing documentation like the Be/Haiku Book or showing an e-mail HTML part especially under the form of an embedded replicant like the old NetPositive or some early versions of NetSurf allowed.
2 Likes
NetSurf is cleanly made from several libraries which can easily be used by other applications. That would result in a much better integration than the hack with a replicant that Be came up with.
WebKit could also do this, in principle. In the current implementation it is a bit too invasive (your window has to be a BWebWindow instead of a normal BWindow) but that could be fixed.
And WebKit2 would allow to run the rendering in a separate process, which would be a better idea than a replicant loading the whole webkit code into any application.
5 Likes
I appreciate it was a bit hacky but that could be improved too, I think?
Generally speaking the idea of replicant that could be embedded and combined together is fascinating and opens up many interesting scenarios if done clean.
Having said that, do you know of any application that uses NetSurf like this?
I was not clear enough, BeHappy used to embed NetSurf as a replicant but this doesnāt work anymore with the latest versions.
I was asking of an example using NetSurf libs to implement an embedded web view not using the replicant way
Not the whole of NetSurf, but in Renga I use their css parser (libcss) to handle CSS in XHTML-IM messages from the XMPP network (I donāt need the other parts because I already have an XML parser, and the subset of CSS allowed in XHTML-IM is easy enough to render in a simple BTextView, for now. But I may use more of it later on for other needs (inline images, ā¦)
I second this, itās not very encouraging if all the feedback ammounts to āletās port something else insteadā
6 Likes
Well, itās just that WebKit is a lot of work to keep working, isnāt it? If we could have a ānativeā browser that was less work, wouldnāt that be better?
I certainly didnāt mean it personally. I know youāve remarked about the time it takes to keep WebKit up to date, and how youād prefer to spend time on other things, and wondered if there could be a way to do that. Thatās all.
6 Likes
I like the idea to have a native browser based on the Serenity libraries,but itās better to offer more browser choice instead of replacing one with the other.
On BSD you can choose between Firefox and its Forks,dozens of Chromium Forks,multiple WebKitGTK,QtWebKit and QtWebEngine browsers and Ladybird.
What we have is only WebKit (GTK,Qt and native) and soon Ladybird as a second option.
My goal with starting this port was not to replace HaikuWebKit but to simply offer more choice.
Also I think Ladybird isnāt at the point where you can actually use it for everyday browsing yet.
Itās somewhat like Internet Explorer but with more crashes (sorry).
Iām really impressed what the SerenityOS project achieved in only a few years as a hobby project and thereās a good chance that it will become ready for everyday use in another one or two years.
2 Likes
Some recent news:
The patches to upstream Haiku support to Ladybird/SerenityOS are still work in progress.
Iāve just rebased my patches against the latest commits from the master branch.
Some patches arenāt required anymore due to changes in Haiku and SerenityOS.
The last two things that need to be done are:
- Use Haikus find_paths API for finding the correct directories for StandardPaths.cpp
- Remove the _DEFAULT_SOURCE, _GNU_SOURCE and __USE_GNU definitions when @waddlesplash fixed the Haiku header files so that they arenāt needed anymore.
1 Like
Only because the web is a moving target and website keep using new features all the time. But, changing the web engine will not help with that.
If that was not the case, there would not be a need to synchronize with upstream WebKit every month or so just to keep websites working.
There is also another path to consider: so far our WebKit work is based on using app_server for rendering. This causes most of the rendering glitches. It would be possible to build HaikuWebKit to use cairo (and/or possibly GStreamer for HTML5 video) as well. Then we would have a lot less platform specific code to care about. This is also worth experimenting with, at least until the app_server backend can be brought up to speed (most of the flickering problems have been solved I think, the next step is rendering fonts with ligatures for all these āicon fontsā).
And of course there is WebKit2 that would be nice to have running. Maintaining WebKitLegacy is more and more work as it gets slowly removed from WebKit, and it gets in the way of using many of the WebKit features. The current approach was to use as much of Haiku native things to get it running (using BMessage for interprocess messaging, etc). Maybe it is worth exploring other solutions as well (such as using our newly added UNIX domain datagram sockets), there as well we can possibly avoid a lot of Haiku specific code and instead rely on the standard āUNIXā code (which is well tested both on Linux by gtkwebkit, and on BSD by the Playstation port, so it is portable without too much trouble).
Whily Ladybird is making a lot of progress, I donāt think they have caught up with WebKit, and I donāt know if they will.
9 Likes
Personally Iād prefer to stick with app_server rendering, even if it may be slower. Iāve invested some work and energy to improve the rendering already, and i donāt think itās worth it to use something else.
1 Like