That is true, and yet our LibreOffice still lags behind a few versions. (on 64bit, on 32bit the situation is way worse)
For an office suite not using the latest version is not a big deal, but browsers get obsolete way faster.
Yes, I agree. It has been a long time since office suites made any real ground-breaking changes.
On my Mac, Chrome updates weekly.
I’m fairly sure they can’t be access at all, so this wouldn’t help.
WebKit and Chromium/Blink have forked 10 years ago. I assume they have little in common now. Even before the fork they were actually two independant projects sharing the same SVN repository (with separate javascript engines, different process models, etc).
The web browser is an important part of the system, wether we like it or not. However, if Haiku inc is going to pay for this, I would appreciate focus on a single web engine. Until now that has been WebKit. If we decide to change course, I would like to know, so that I stop spending my time maintaining WebKit ![]()
Sure, porting a new engine is more exciting, it’s new and shiny. But what you really need is someone to maintain it in the long term. Make sure it’s kept up to date. Fix the tiny bugs that takes hours to understand. Reply to upstream when they need to refactor something and Haiku specific code is in the way. And so on.
In that context, I think WebKit still has a much higher chance of success. It is the only one of the 3 major engines that:
- Is designed for embedding in various apps, such as our mail client or anywhere else we may want to display web content (this disqualifies Firefox)
- Is open to support for alternative operating systems and will upstream our patches (this disqualifies Blink).
Now, there are many ways to port WebKit to Haiku. We already have WebPositive and GTKWebKit (not sure how up to date that one is). There is ongoing work to move WebPositive to WebKit2. We could also switch from using app_server drawing to Cairo or Skia and in-application rendering, which would fix a lot of rendering bugs and be less code to maintain. I think at this point there’s a good chance of building a WPE based browser out of the box from upstream sources.
Anyway, I guess the main point is, I don’t think Haiku inc should be funding a Chromium port. If people are willing to get it and fund it separately, that’s fine, you do what you want with your money of course ![]()
I really don’t get the mentality behind this kind of comment. The developer in question expressed interest in working on a Chromium port. He didn’t provide a list of things he might be interested in. He only expressed interest in one thing, and now you want to discourage him from working on that one thing. The result might simply be that we get nothing at all.
This also sounds like a strange request. The Haiku Inc money is meant for the Haiku project itself. We could perhaps request advertisement or the mechanism to fund a Chromium port, but asking Haiku Inc for money is a bit much.
I realize I’m a n00b around here, but this makes sense to me.
Could it be a task for GSOCK 2026 ?
If someone is willing to mentor it.
Personally I’m more than happy to mentor students willing to work on WebKit instead, since that already works.
Chromium? I think, that would be yet another wasted GSoC opportunity. The task is too big to be handled in a short time frame by a student without a prior extensive Haiku programming knowledge. And then it will end being not finished, waiting for someone else to pick it up, which will probably never happen, and eventually PulkoMandy will write about it in his overview of the stalled PRs. We had quite a few of such stories in the past. GSoC can contribute to WebKit (preferably) or to the Firefox/Iceweasel port.
Ok, I changed my mind. Chromium port shouldn’t be sponsored by either Haiku Inc. or GSoC. If individuals would like to sponsors so that they can have it working, that’s their own business.
Haiku Inc fundings should be used for moving towards R1, and GSoC is better for projects that can be completed in the summer holiday period. Those previously incomplete projects should be prioritized.
For GSoC, unfortunately the priorization comes largely from whichever idea is popular with the GSoC participants. We only receive maybe a dozen or so applications each year, unlike other projects who have cybersecurity or machine learning in their description, and get hundreds. C++, operating systems and user interface are not as trendy at the moment, it seems (at least not in place where people consider doing GSoC)