It must have been an earlier version, it was not on haiku though. I remember having trouble with it, but I last built webkit ~10 years ago. The first google hits suggests this was indeed true in 2012
https://forums.gentoo.org/viewtopic-p-7093866.html
/rant
When I say stupidity, I mean increased complexity with no end user benefit, I am just not seeing the gain of user functionality with the ever increasing complexity of the web. Innovation for the sake of innovation is not progress. It is a lot like the never ending growth of managerial culture in government and business.
At 1 point, GM had 76k white collar workers and 78k hourly workers.
I think it’s the MBA problem, but with programmers and team managers. The goal of everything should be to reduce complexity to the lowest possible level. The best part is no part and the greatest sin of any engineer is to optimize a thing that doesn’t even need to exist. Musk isn’t wrong here.
rant/
3 Likes
Maybe Flow engine might be interesting. If not for code, then maybe as a concept.
https://www.ekioh.com/flow-browser/
https://www.fastcompany.com/90611677/flow-ekioh-web-browser-new-engine
3 Likes
Oh look, it is this thread, again.
Dear naysayers: try to use the search function on the forum and actually read the results, we dont need yet another flamewar about your feelings, ideas and favorite webbrowser. If you cant add anything new then consider to not open a topic.
Also please consider to divide a different community (thats a *nixy habit btw) with your shiny ideas, thank you for the understanding.
1 Like
It is not about the topic but about the people who came up with the same ideas in every 5-6 months.
“Guize, i have the greatest idea, you should port my favorite webbrowser, this is the only way. Also switch to the l*nux kernel in the same time. I am a genius. I also wont touch any code, so please do everything as i suggested. Now.”
Please grow up.
3 Likes
in the ability to transfer data between apps (copypaste or drag and drop for complex objects, not just plain text, etc).
Speaking of which, the WebKit port doesn’t currently have drag-and-drop support, right? I’ve been looking for a complicated program to test Emacs with, but all I can find is Tracker, Pe and StyledEdit.
It doesn’t?
Open a ticket and I’ll try to look into it :)
First it was derailed, then you made a second topic. why not start the new topic first?
In any case, it does not matter much, currently Haiku needs a webrowser, full stop.
There simply is no way to use many modern services without it, like informatin from a local city etc.
This is regardless of weather some parts of the web are overly complex, the not so complex parts have to work. This includes streamed media, this should work properly in haikuwebkit and MediaPlayer. Maybe even using Picture in Picture handoff to MediaPlayer.
We can’t sit on out hands and complain that many parts of the modern web are shit if we can’t solve any of it. This won’t help getting people less dependant on it but rather more as they can’t use Haiku then and instead will be pushed more into chromeOS or windows.
1 Like
No that’s a bad hack. If we can’t play a video without the help of MediaPlayer, we should not dig ourselves deeper into that ridiculous situation. We should move code from MediaPlayer to the media kit so that normal humans can actually use it with an API that does not require a galaxy brain and a PhD in BeOS history to understand how the media kit is architectured.
So let’s fix that and not pile up hacks on top of it to avoid the problem.
10 Likes
I didn’t suggest using MediaPlayer as the thing to play media with normally, I think it would make sense to implement PiP with it, the playback inside the browser would be in the media kit anyway.
Currently streaming works badly in both of them, so the media kit would be a good place to fix this if we need streaming support.
is there a open source library in one of the other browsers that could be used to fix the streaming issues, or is that part of the network services project ? did that ever get clower to completion ? kit know it’s been worked on over the years. i thought the new network services stuff had to wait for webkit2 multiprocess design
- WebKit (legacy) builds to completion. (recently updated)
- WebKit2 builds (but required repatching a few areas). (not recently updated)
Testing is very close to Webkit/Safari test results. Issue seems mainly wiith Haiku API integration/features work.
If focus is on Webkit2 build, someone can update it to a recent snapshot (I did this before on my own fork(s)) and we can focus on fixing the builds from there… (start decommisioning WebkitLegacy at some poiint)…
7 Likes
WebKit could use GStreamer for that, but it would be better to use the Media Kit I think?
Well, GStreamer is possibly easier but doesn’t help with improving things for native apps, and it’s yet another dependency added to Haiku (and not just one, GStreamer in turn brings lots of Linux stuff).
Similarly, the network side can be done either with curl or with the native netservices (both already work and it’s easy to switch with a few compiler flags). Likewise the graphics could be done either with app_server or with cairo, and so on.
5 Likes
For my education, do Cairo and Curl have any advantage over their native counterparts?
Why may we want to take them into consideration?
Curl and Cairo are used by for example playstation webkit.
The advantage is that they have tested this stuff extensively, so it may run better in places (they simply have more engineering power than us)
It may also help expose which bugs are in out webkit <-> haiku glue code and which in other parts of the system.
The disadvantage is that each additional dep to do something the OS could do already adds complexity and slows down application startup since more libraries need to be loaded.
Additionally the integration becomes much worse. say goodbye to native Haiku buttons in webkit views or libnetservices debug logging (and potential system proxy support, etc.)
As another thing haikuwebkit caused many improvements to Haiku because it used native apis, these improvements benefit all applications that use those native apis.
2 Likes
The problem is to know what we like in Haiku. You will often find mature open source libs to fill a purpose but, introduction of this calls introduction of that and, at the end of that snowball effect what’s left of Haiku? The kernel? Some already suggested to use linux instead… So, if we like that Haiku is different, we have to prefer native solutions even if for a while they will lack this or that.
I think at least 90% of what is in Haiku repo should be fully native. What’s on Haikuports is another story but you can hope that priority is given to native apps.
3 Likes
In the case of curl, it has support for HTTP 1.1, HTTP/2 and HTTP/3, while our netservices code currently only has HTTP 1.0. It also implements a few more things needed by webkit such as synchronously loading a page (that would not really be a problem to implement with libnetservices, but it needs a rearchitecture of haiku-specific code inside webkit and no one had time to do it).
The reason we started the whole netservices work in the first place was performance issues in webkit curl backend, in particular, the cookie jar was known to be a problem. However, I would say it was a bit too ambitious from us to decide to write a complete HTTP implementation from scratch, and expect that we could do any better than curl. I think it is worth it to reconsider our choices and maybe reimplement libnetservices as a C++ wrapper on top of curl, even?
In the case of cairo, the big change is that it does client-side drawing. This has some advantages in the case of webkit because the drawing does not happen in the app that will eventually display the data on-screen, so doing drawing on the server side results in some complications.
The price is higher for switching to cairo, for the reasons mentionned by nephele: the app will not look native (not only buttons, but even font rendering will be slightly different than in other apps for example), and there will be extra dependencies so extra memory use. However, the current rendering isn’t exactly working great, so, in the short term, maybe cairo can be enabled, and, in the case of webkit2, that would also solve (very easily) one of the problems with the porting, which is that we’d need to transfer BBitmap between two apps. Which is in theory possible, but not implemented yet.
So, the general idea is to allow to get webkit2 started from reusing as much as possible code that is already maintained for other platforms. Once we have it up and running we can see about making it fully (or partially) native.
8 Likes
If Wine gets to be working well on Haiku, then several browsers - portable ones, for example - will likely work with it. This will allow users to happily browse the web, while giving time to devs to improve netpositive. So you have to juggle legacy with practicality.
2 Likes
I remember at one time fonts had to be installed before they were used in the browser. Is that still the case? Also, are OpenType SVG color fonts still unsupported? That may be something I could tinker with.
Edit:
Is it this ticket? #13361 (Webkit: @font-face not working) – Haiku
2 Likes