Is it a WebKit2 wrapper for Qt? Blink was originally a WebKit fork, wasn’t it?
1 Like
and webkit ws a khtml fork. but the three engines are distinct, webkit2 especially is something that webkit didnt have when blink was forked.
qtwebengine uses chromium
Who said that? The posting says Falkon uses QtWebEngine not WebKit.
BTW Falkon is another impressive browser.
Greetings
Peter
Blink was a webkit fork in 2014 or so, since then the two projects are completely unrelated. And the fork happened because already before that, despite sharing the same svn repository, they had less and less things in common, for example they already had separate javascript engines.
So, no, it’s not webkit.
1 Like
I’m not sure what you expect from this, it will be at least as bad and broken as webkitlegacy, since itws the exact same engine with a different API on top of it.
1 Like
Continuation of:
Goal:
- WebKit2 usability
- load and view dynamic web pages using WebKit2 backend
- Migrate away from WebKitLegacy branch (i.e. WebKit1)
- Identify and fix any Webkit2 build issues as needed
Beneifits:
- runs separate UI split processes for each web browser tab (comparable to QtWebEngine).
- loading a dynamic web page in a tab doesn’t crash the whole browser
- better sandboxing
- No Qt libs dependency
- Modernization and compatibility to other WebKit2 ports
8 Likes
I’m not much of programmer, but wouldn’t it make sense to make to take whatever code the native net services need and in a way copy paste it and convert to beapi , i know it is a massive oversimplified view, but, if curl has that much functionality and it is hard to develope, what’s better ? external library or jist integration of the code into haik net services ?
1 Like
Reread what @PulkoMandy posted earlier in the thread. Around that post or earlier he had suggested making Haiku net services a wrapper for libCurl. That’s almost a no brainer.
As far as Blink based wrappers like QtWebEngine, they are more difficult to port than WebKit2. Both are ports. The bindings are the details in which the devils reside.
I am suggesting pulling curl into the netservices code base and making it a haiku thing, make it totally native with a semi re-write
1 Like
You and most of the community are in agreement on that point, I think. PulkoMandy suggested it earlier in this thread.
What do you mean with “most of the community”?
Pulkomandy offered one option, this wasn’t ment as dictating anything.
A new libnetservices is somewhat in development already.
External library, of course. Then there is 0 work to do to get the newest versions and bugfixes. And I don’t see what you would need to change in the curl code, anyway, it is a well designed piece of software, why would we need to change its internals?
We can write a nice C++ API around it that fits with Haiku in some way. Just like we use ffmpeg for the media kit and various existing libraries for the data translations. There is no difference between file formats and internet protocols, really.
But even for the native kit I am not sure what the proper way to fi it with the existing APIs is. I am not satisfied with the existing solution which has threads and locking problems, is quite confusing to use, and doesn’t even deliver good performances in result of this extra complexity. I am partly responsible for this and the conclusion is I’m not good at designing APIs.
3 Likes
A bit harsh on yourself there! API design can be iterative once you understand the problem better. I doubt there is any programmer that hasn’t written code that later they’ve thought is ugly and then recognised in hindsight that there is a better way to do it. Also there is a question of time (the fast way vs the better way), trading some technical debt for a faster release time, and of course over-engineering.
3 Likes
the first time i designed a intake manifold, it sucked, but i learned a lot. the 2nd one, it to sucked but it was on par with other intakes. the 3rd i take was a light-year improvement, but ugly.
intake manifold 10, that’s art and it’s got amazing performance.
i threw the other 9 units away when i was done learning what i thought i knew. if you have discovered non obvious truth through the engineering process, reroll the project with the new knowledge, iteration is key. start iver throw away old code if you know it’s not good
let failure teach you success
Hi everybody, I’m new to Haiku so I was interested in getting a better understanding.
I have been trying to play around with WebPositive, Falkon and Otter.
While I found WebPositive fairly functional and stable it’s very slow and freezes frequently (you have to wait tens of seconds before it recovers loading a page). Trying to open youtube is a good wait to freeze all my webpositive tabs.
On the other side, Falkon felt very responsive and feature complete. All websites worked very well in it. Sadly it crashes every 2 minutes.
In general my experience is that reworking a software that is sluggish to make it more isolated and fast is a fairly big work, while fixing a crash is usualy something to which you can at least find a work-around with reasonable effort.
So I’m not sure I get why at the moment there seems to be so much attention to improving WebPositive instead of starting on what seems a more solid base (Falkon) to fix the crashing problem. Am I missing something obvious?
Sorry for the stupid question, but it’s my first experience with Haiku
1 Like
Falkon is huge, complex, and used a webengine that operates as a black box. Severall devs have wasted their time on trying to fix the crashes.
Webkit and webpositive is the “native” stuff we want to use going forward, why put that much effort into trying to fix third party browsers that could have been used to improve webpositive instead?
Edit: the freeze you are experiencing is likely duo to how webpostives handles media elements now (badly)
4 Likes
Hello Javanx, welcome 
I also think we should improve WebPositive (that it can take on Safari). Thanks to Adrien we are very well positioned (kudos for that!).
Since we use the same engine, our rendering is almost identical, only the speed is a bit different and we still have some problems with fonts. If I use Haiku in a Pi-Hole protected network, the browser is working almost flawless. If not, I’m in advertising hell and everything is slow and partially unstable. Maybe we should get a software adblocker (is there something opensource available for Webkit based browsers? idk). It would not solve the actual problem but disguise it a bit. By the way, working with the .hosts file is annoying and makes some things even worse.
One of the first things people try on a new System is the web browser. Unfortunately usually something heavy with videos or something like that (youtube, twitch, discord, instagram, whatever) and that experience is usually not good.
Should someone find the time and dedicate to improving the webkit integration (media streaming, font loading, etc) or finish the webkit2 port, that would be fantastic, even if I can’t imagine how much work it is.
Long story short: I like WebPositive!
1 Like
Webkit can already do this by itself, and much more efficiently than dns based blocking too.
1 Like
From my personal perspective, Webpositive have more potencial to be more integrated and optimized with desktop and the native instructions.
Is not completed yet but, can be in long term the best option.
4 Likes
Would it be possible for WebPositive to get WebExtensions support? This could open up many very useful extensions to be used, such as uBlock Origin (which removes ads and their elements), Dark Reader, and SponsorBlock (blocks native ads in YouTube videos).
1 Like