Thank you for the information! Great work!!!
Amazing work!
I was wondering, does OpenGL work in Qt with this work? I remember that was missing previouslyā¦
I have try implement opengl context functions for haiku qpa plugin, but it very unstable and not usable.Iām not an expert in OpenGL.
Old screenshots:
2 Likes
Hi @3dEyes , Iāve seen/following your recent activity/commits on HaikuPorts, and seems that the most of the goals which you marked in this discussion has been achieved: what about to see this set of elements as installable packages to test this version of QupZilla with a better QtWebkit and so HTML5 audio and video support? Is just a matter to compile your recipes and make/upload packages? Is still miss something?
Thank you for your excellent work! 
Howās it looking!?
Dear friends, how about Qt 5.9 for x86_gcc2?
Probably, it is a barren scheme?
Would be amazing if a newer qupzilla version could be supported. I see 2.1.99 can get 517/555 vs 320 for 1.8.9. Could be enough to make haiku a daily driver for a lot of people!
It is impossible right now, as it requires QtWebEngine.
What are the major issues with porting QtWebEngine?
Does anyone know where @3dEyesā repository is? It appears that heās dropped off the radar and could someone else pick up this work?
I did not disappear from the radar.
All changes will be published to haikuports today.
1 Like
Ah, pardon me for being so presumptuous! I look forward to seeing your work - thank you!
ŃŠæŠ°ŃŠøŠ±Š¾ - probably one of the 10 words I know in Russian.
I want this binaries to replace the old qupzilla n.n look great and is good browser, but without youtube ā¦ 
QtWebEngine is based on Blink, the same engine that powers Google Chrome. If one manages to port Blink, then running Chrome or Vivaldi above it would be possible as well, and I donāt know if people would stick to Qupzilla.
I expect it to be a rather long journey (if only for Blinkās compilation time), but nothing impossible. Just a lot of patience needed, and good knowledge of Haiku and its quirks to provide the base layers (but there are a lot of people who can help with that).
Iām not aware of anyone actually trying to port Blink, so itās hard to tell where the main problems would be.
Also note that the HTML5test result isnāt all and everything. It is not a testsuite, it just checks what the browser pretends to support. So you may enable all the features to get more points, but then the implementation can be completely broken or even outright missing. Moreover, not all the features are used by websites, so it may not matter to get all the points. Focusing on the most common features and getting them to work well (on actual websites) sounds like a better plan. (and no, Iām not saying that because Qupzilla now has more points than Web+ 
good job guys!)
2 Likes
Could the Inc support a bounty for this? I see they paid out nearly $10k on contracts for a packaging tool, so an up-to-date browser should easily qualify for sponsorship.
I doubt it.
They paid me for one year working on WebPositive, which is based on WebKit, the engine powering Safai. I did not start from scratch, there was a lot of work done by other devs before I started. And it took me a further 2 years of free time to get the browser where it is now: a reasonable set of features and not too crashy. Not to mention extra help from other devs, for example the extensive work by Jua on profiling app_server to identify performance issues, then add the required rendering primitives to make Web+ much faster than it used to be.
The reason we went with WebKit in the first place is that it can be integrated into native APIs. Ultimately it will be possible for applications to use it and embed HTML as they would with native widgets. We have not even reached that goal yet.
As far as the Haiku project goes, I still think that continuing the work on WebKit is the way to go. Other browsers are either a stop-gap solution, or something that should be handled outside the Haiku project itself (as it is for any other OS - the people developing Windows are not the one developing Chrome).
And a final note, the $10K for package management was far from just āa package toolā. It involved designing a complete infrastructure for it, with impacts down to the bootloader and kernel, as well as setting up the initial set of packages at haikuports. If we just wanted a package tool, we would have used pkgsrc or some other existing solution. But that was not quite enough to satisfy our goals.
2 Likes
Understood, thanks.
I didnāt mean to state that development for the packaging tool was a waste of money - far from it - I would have just thought a browser would have been on par, or, IMHO, more important, considering how important web browsing is to any OS.
Of course, just my opinion.
Dave
1 Like
Thatās right, but there already was a contract for it. I was paid about ā¬2000 per month for around 12 months, or a total of 24Kā¬, IIRC. This was the longest contract ever run by Haiku, inc. It was made possible at the time by sustained donations from the community, but eventually they ran out of fund, still, and I had to go back to a ānormalā job.
Similarly to the contract for package management, the overall goal was more ambitious than just āa web browserā, as I mentionned in my previous post.
That being said, the fact that Haiku, inc is not the right place to go, does not mean a bounty for trying to port Blink then Chrome and/or QtWebEngine is a bad idea. Provided you can find someone up to the challenge and enough funding, that is.
I would humbly disagree here; if the Inc. doesnāt exist for funding improvements to the core OS (I would argue a web browser is more fundamental than even an office suite these days) then why does the Inc. exist at all?
Surely our objective (and I would guess my fellow members who donate, as I do) is to attract people to the OS?
1 Like
Just a web browser is definitely not part of the core OS. It is just an application, no matter how important.
This is why we went with WebKit, as I said. The project goes further than just the web browser, bringing the availablility of HTML rendering into any application.
Our vision for Haiku is not just doing things in the web browser, but rather writing native apps that interact with the web. You can see this with apps like Radio, the work in progress calendar application, the Weather app, or HaikuToDo. These are small examples of what weāre aiming at, and being able to render HTML directly inside native applications will likely play a role in that.
As a result, the project is more ambitious than just getting the web browser running, and most efforts are concentrated on the engine rather than the āchromeā (that is how they call the user interface - and where Google browserās name comes from). This is why WebPositive is a bit underwhelming as a web browser - it is there only to showcase the engine under it. However, it would be great if someone could step up and improve it, and it is also great that there are alternatives like Qupzilla until we get it ready. But, the main focus should still be on the native apps and integration with them, not just getting some random web browser to run.
3 Likes