gstreamer updated from 0.10 to actual latest version
native haiku audio sink for gstreamer 0.10 and 1.x work fine
native haiku style plugin for qt5 (about 90% widgets set styled for now)
qtmultimedia builded with gstreamer backend and video and audio work fine
qtwebkit builded with qtmultimedia: html5 audio and video elements worked (youtube vimeo etc.), online media streams not worked for now (Media Source Extensions in qtwebkit 5.9 broken)
added to qpa plugin: system tray icons, initial opengl context initialisation
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?
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!
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!)
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.
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.
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.
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.
good job guys!)