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
Not always.
The main cause of “freezes” in haikuwebkit is well known and identified. Whenever a page has a video or audio element using html5, the way the code is written now, everything will be blocked until that audio or video file is fully downloaded. Then the other parts of the web engine will resume. Changing this would fix a lot of the problems.
There are two ways to fix this:
- Rewrite the media code properly, which should be done by someone with knowledge of the media kit. The current code is a quick hack I made back in 2014 to see how hard it would be to get video running, and was largely untouched since.
- Switch from webkitlegacy to webkit2. This is a new API for WebKit that splits the work accross several processes. As a result of this split, a freeze in a tab would not affect the whole application.
The second part is indeed a bit of work, but it is still of reasonable size. The first should be pretty easy for someone who knows how to use Media Kit properly.
4 Likes
Not really, the engine does not do all the rendering. Depending on the platform it relies on Cairo, some macOS APIs, or in our case it uses app_server. The advantage is we get font rendering that looks exactly the same as other apps. The problem is there are bugs in this part of the code, as well as limitations in app_server, that result in the rendering not being correct at all. We don’t have drop shadows effects. We don’t have correct support for dotted and dashed lines. And so on.
We could switch to cairo to solve this but then the font rendering would look different from other apps.
Yes, WebKitGTK does it. But it is only available in WebKit2 so we need to switch to that first, or add support in WebKitLegacy (but I would much prefer switching to WebKit2)
6 Likes
Yes.
But:
- ublock origin is completely unecesary with native webkit blocking
- dark reader is too slow and breaks dark mode, ironically enough
So while yes, we can totally add webextensions the usefullness is sonewhat limited. (funnily enough those extensions, apart from sponsorblock, are to me basically fixed for deficiencies in chromium browsers. We should just do it properly instead : D )
Does native WebKit blocking also remove webpage elements? That’s one of the main differentiators between uBlock Origin and most other adblockers, since it can prevent formatting abnormalities where ads would normally be. It also blocks regular YouTube ads too, although perhaps that could be implemented natively too.
Between the three extensions I mentioned, only SponsorBlock has an API:
https://wiki.sponsor.ajay.app/w/API_Docs
No C++ library yet, unfortunately.
Yes it can.
Sponsorblock might be interesting as a normal extension, but ublock is simply uneccesary with webkis api. (and dark readers implementation is plainly wrong, maybe we can do better… )
modifying app serrver sounds like a r2 issue, if using cairo fixes rendering issues, why is this still being discussed ? most people will happy that th rendering is fixed vrs concern over application specific font renders etc.
i get having the haiku look feel consistency, but at what cost ??.
if haiku could attract enough users, the funds will follow
What? why?
I care about font rendering ; (
That makes no sense. We can add whatever we need in app_server, it is one of the parts of Haiku that has no exposed API at all (applications do not communicate with app_server directly, only through the BView API).
No one has tried to enable Cairo rendering, as far as I know, for the last 9 years (since I started working on WebKit) and I don’t think it was tried before that either, since haikuwebkit exists. So, it does not “fix” anything at the moment. That solution doesn’t exist yet.
When it does, we can compare and start discussing.
Who will write the patch allowing to do it?
If Haiku attract users who are okay with a web browser using Cairo, the funds will not flow to writing a native web browser and improving app_server.
Anyway, as long as this solution doesn’t exist, we don’t know how workable it is, how good (or bad) it looks, what performances it has, and so on.
3 Likes
funds will flow to wherever the inc sends them. So the Board members will be making such a decision.
Which is the most efficient and maintainable path forward ??
add the required API and code to App server
or
get cairo working ?
the native fonts button etc doesn’t matter to end users