I hope fixing QtWebEngine in your todo list. Now we have more drivers to get network. But we still haven’t fully feature tool to interact with Web. Falkon can be that tool, but buggy QtWebEngine doesn’t let it. New beta without fully feature modern browser will again suffer the same fate as the previous betas. All reviews will say that we still don’t have a normal browser that is why system not ready for typical using, etc…
To fix QtWebEngine we need to rebuild it with the debug option enabled, that requires very high resources from the hardware configuration. If someone have a powerfull pc and be able to build it when it might shed light on the causes of the qtwebengine falling, and the case is most likely in a large number of stubs inside of the Kasper’s patch, only debug may show it.
@SCollins if you (or any one else) are having problems with haikuporter may I suggest bundling them so we could see if we could get you on track to be able to use it.
There has been an (older) thread that could be used for that: Error building packages from haikuports - #15 by humdinger
While I agree that Inc money is rather better spent on Haiku native stuff, if someone is voluntarily fixing QtWebEngine and finds it fun, the law of open source states they are free to do so,and quality of your (or anybody else’s) work is out of topic.
That being said, I do appreciate your work on HaikuWebEngine. If I knew any C++ beyond pronunciation, I’d probably work on that.
And more generally, about the direction we are trying to go with Haiku. Honestly, if it turns out Haiku is just a different OS to run the same apps that exist on Linux, with an integration that’s just as bad or possibly worse, then I don’t have much interest in it anymore. I can already do that perfectly fine on Linux.
My personal interest in Haiku is because it’s a very polished OS where all apps seamlessly integrate. Not just the looks, but also much subtle details in the behavior, and in the ability to transfer data between apps (copypaste or drag and drop for complex objects, not just plain text, etc).
I don’t think we can get there by adding Qt apps.
Maybe I am stupidly idealistic. Maybe we can temporarily go with Qt, gain more users, and then get donations from them and use that to fund the native apps we really want to get. But then suddenly there is talk about using the funds to do… more Qt?
No, Haiku already have significant advantages over Linux even if not using native applications:
Easy of installation and administration. System do not need any config files for booting and boot loader can load another Haiku installation without cryptic boot commands. System can be installed in a few seconds and moved to another disc/PC just by copying files.
Package management. Mountable packages allow much faster install/uninstall, keep system integrity (can’t accidentally modify/delete package files), boot to previous package configuration.
Binary compatibility. It is possible to distribute software in binary form that will be functional in future system versions. Compiling software for a lot of distributions is not needed.
Fully featured GUI system. Linux advertise Wayland based GUI systems that is very restricted and many common operations (like setting window position) are not possible. X11 is not actively developed and planned to be deprecated. Some core GTK developers propose to drop X11 backend for next major GTK release.
Lightweight. Haiku use much less RAM and disk space compared to Linux distributions. Even non-GUI Linux distributions takes more resources.
Tracker and Deskbar. I find it easier and convenient to use in many aspects compared to GNOME, KDE and other Linux desktop environments.
Unified source code. It is easier to understand Haiku internals and modify code compared to a lot of Linux libraries written using different concepts.
… until you start using Qt apps and suddenly you may need to start a dbus server, or refresh a fontconfig font cache, or other strange things will happen.
This works if the apps are built to be stateless, and not need to run scripts for installation or uninstallation. Which is possible for Haiku apps but usually not so much the case for ported ones.
Unless your app is ported from Linux and has a thousand dependencies for no reason.
Only useful if the apps actually take profit of it, which is not the case for ported ones.
Until you start loading all the Linux libraries to run your Linux apps.
So, yes, of course the situation is a bit more complex, but the general idea still stands: by using more and more Qt apps, we are putting the things that make Haiku work at risk.
In the short term, I agree that it is possibly more convenient when there isn’t any other way, or when writing a native app would be too much work. But I don’t think that is the case for web browsers, with Haikuwebkit being so close to working, it is a bit sad to see how much time and effort is being spent into everything else. It is especially sad for me because of all the work I put on haikuwebkit, that the first thing people will ask is “but when do we get QtWebEngine and Falkon? Firefox? Chrome?”
Qt already works better in Haiku then Wayland based Linux systems because Wayland simply have no protocols for many Qt functionality. The same is for Wine. It is not possible to implement Wayland Wine backend. Some attempts exists, but it violate WinAPI specs and breaks some applications.
I have a 32 core 128gb ram machine I don’t use. I’d be happy if someone wants to use it for debugging but I normally only turn it on when needed as it uses 100w at idle. So you’d need to message me when you want it. Come to think of it it has a management interface, I guess it might be able to get it to power up from another machine on the network… Also I guess it would need haiku installed?
Honestly, why would we want to debug an application that requires specialized hardware to even build?
I can build webkit just fine /on my laptop/ even if it takes a bit…
Anyway, I agree with @PulkoMandy here, it makes no sense to try and port “just another browser”. This has been attempted countless times with qtWebkit and now qtwebengine browsers, and the result is the same: another half working browser ported and nobody is happy.
Haikuwebkit has had some crashes resolved, improved rendering (also a unmerged patch for proper dark mode controls by me) and keeps improving, it would go a lot faster if there were more hands on deck instead of trying to port just another stopgap.
@madmax has made good progress fixing rendering issues and investigating the big one with svg (and native buttons)
Pulkomandy has been rebasing webkit and fixing some issues, aswell as making progress toward a webkit2 port, and additionally make it buildable with curl to compare against the network kit.
Some of the more annoying issues like cookie sessions probably not that huge to fix, if somebody would do it, but in all reality the number of big issues that make it annoying to use are getting less. (audio and video streaming probably needs a bit bigger patch… soon we should have BMemoryRingIO that makes this easier iirc)
Well, the same thing is true of webkit to some extent. I believe 32 bit debug builds require more RAM to link than you can have in a single process on a 32 bit machine, for example, so you have to cross compile them on a 64 bit machine. And I guess that with enough swap and time you can build qtwebengine on any 64 bit machine?
In any case I am not taking a stance on if it should be done, but if someone needs it I can make it available.
I already did look at QtWebEngine a few months back and didn’t manage to figure anything out. I don’t understand why it crashes, and I added a bunch of hacks that should have at least changed its behavior to crash differently but it still crashed basically the same way.
There are other developers besides me, in fact most of the work on QtWebEngine already was done by @KapiX and @korli. I do intend to work on HaikuWebKit at some point, but maybe not before the next beta release. We’ll see.
