This is the progress on this issue: https://review.haiku-os.org/c/haiku/+/4790
Your ticket link is correct.
No idea about SVG fonts, never seen a ticket for them
Yes, let’s try yet another compatibility layer for a foreign kernel and usersspace api to port an even more foreign browser. I can’t see that going wrong.
The problem is exactly that: devs spending time on these wierd “surely this compat hack will work” endevaurd instead of working on improving webpositive or webkit.
This doesn’t give time to improve webkit but rather takes time away from it as users want instead even more work pouref into the stopgap of the week.
2 Likes
Netpositive “was originally developed as a stop-gap measure because no browsers had been ported to BeOS”. 25 years later of plentiful dev time, it’s still not fully functional to satisfy users, So, yes, the native-only approach is obviously working…
A fully functional web browser is - as reviewers have made clear - Haiku’s archiles heal.
2 Likes
We don’t use netpositive. We use webpositive and webkit.
Webpositive was never intended as a stopgap.
BeOS did get native browser ports yes. Browsers were much less complex the and BeOS had atleast some commerical interest, and literal paid developers, so this aproach was viable.
Haiku is unlikely to get a port from browsers themselves, so we have to do this ourselves… which we already are doing with the excelent webkit engine. We don’t need to write a webrowser, just the glue code and the native gui.
Porting a browser with wine is unlikely to be faster, wine still needs a huge ammount of work before it worls close aswell as it does on linux. And even there chromium browsers basically fo not work in wine.
2 Likes
What you call “plentiful dev time” is, for the last 7years, mainly me spending about 2 hours every month merging changes from upstream WebKit. That is not what I call “plentiful”, and that is indeed not going to get us a better working browser anytime soon.
In the periods where I and others were indeed working full time on it there was quite some more progress on things.
5 Likes
As opposed to the “let’s port the popular browser xxxxx” idea that is endlessly talked about here on the forum. 
2 Likes
What people don’t seem to understand is that first, it is not to Haiku devs to work on ports. In itself it would be kind of negation of what Haiku is. waddlesplash, as an Haikuports contributor gave a kickstart for QtWebengine, it is already a lot.
Second, complaining here without doing anything else is wasting the time of the few people working on solutions. People are complaining either for a better Web+ or a ported browser but they contribute neither with patches nor a working port. I’m not even sure that there are ‘usable’ bug reports… Because I have trouble with site x without even providing a link to the site… That’s also a waste of time.
On one hand, if you want a better Web+ report bugs in a manner that helps to understand the problem and if you can propose a patch to fix it. Better, if you have development skills, help on Haiku versions of Webkit, Webkit2.
If in the other hand, you’re one of those wanting a ported browser, head to Haikuports and do that same thing but for QtWebkit / QtWebengine browsers…
People with development skills can help debug QtWebengine.
2 Likes
There is quite a lot of intersection, for many reasons.
- Haiku does not force people to work exclusively for Haiku, developers are free to hack on whatever they want (with maybe the exception of developers being paid to do something, and even then, it can be discussed)
- People working on ports often end up uncovering bugs in Haiku and maybe fixing those and becoming Haiku contributors
- All of us (or at least most of us) are first and foremost Haiku users, and sometimes, porting existing software is indeed the best or fastest way to get something done.
2 Likes
Nobody (myself neither) mentioned that “Web+ crashes on some sites” means “Web+ is already doing a nice job on many sites”. Web+ and Netsurf are cool browsers.
As someone else already mentioned the cool aspects of Haiku are its technical elegance and that’s what people appreciate about Haiku. So porting solutions from other OS (xlibe and Wine) is quite cool and helpful but we don’t want Haiku to be just another Linux distro (or Windows variant). So Haiku WebKit is a good path imho.
Greetings
Peter
8 Likes
Webkit2 review:
Test (w/ Haiku hrev56288 and < 8GB RAM):
-
Falkon 3.2.0 w/QtWebEngine 5.15(.10-latest)
- Works with most websites and Youtube video/audio playback.
-
WebPositive 1.3-alpha / HaikuWebKit 1.8.x (WebKit 614.1.20.1, Legacy (WebKit1))
- Youtube video/audio playback works. Some media playback control issues.
- Has issues with certain dynamic web pages
- Recent WebKit release (within a month)
- HaikuWebkit2 - Webkit 614.1.20.11.1 (forked, latest
)
- Merged Haiku’s WebKit2 w/ Webkit 614.1.20.11.1
- Added new Haiku Services Kit patches (new test fork)
- Build configuration & generating done successfully
- Compiling…
UPDATE:
- Reverted Haiku Network Services Kit patches
- Missing UrlSession.h for libnetservices
- Fixed Haiku’s UserAgentHaiku.cpp code in Webkit2 branch (new code)
- code is not in haiku-webkit2-gsoc2019 or haiku-webkit2 branches
- Fix Haiku’s RemoteNetworkingContextHaiku code.
- Fix Haiku’s NetworkDataTaskHaiku code.
- Fix Haiku’s SharedMemoryHaiku code.
- Fix Haiku’s IPCSemaphoreUnix code.
STATUS:
- Webkit2 compilation: 92.4% completion
7 Likes
Falkon does not use webkit at all, what are you on about?
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