WebKit based browser initiative

Just for more info,

We are working/waiting/hoping on fixes to adtools right now. The late discussions in the qt6 progress thread are relevant here. We want to build with newlib and clib2. Since it takes a while to get additions to newlib we have been looking at clib2 and for that we need to make sure that shared objects are working as expected.

So, progress is happening.

@rjd324
Is there real needs to build newlib based version too ? I mean, we all know that os4's newlib is closed, and when there will be needs to fix something in newlib, it will mean rely on years of waiting for bug-fix to be released ? With clib2 there no such issues anymore.

Also, is there needs to have "sobjs" support for ? I mean in meaning of webkit port. Morphos version didn't have that, so why should we ? (and usage of sobjs, slowing down the whole loading on startup, always). ScummVM are good example : the static build loads up in a second, the sobjs based one take 2–3 seconds to loads up. With such a heavy beast as browser, every second count IMHO.

so sometimes are needed. Take VLC for example. It will never work with a static build. Same for python that use a plugin system. So it is not always needed but it is better to have them..

@afxgroup

Second.
With limited RAM comes shortcuts and .so's are a great way to save RAM and still provide big projects

@Afxgroups
Sure, sobjs may needs sometimes, but everyone should be aware that using sobjes with browser will slow the starting, and that will be noticeable.

But in case with exactly this port from morphos they didn't use sobjs, and all fits fine in the ram and so on. Using sobjs just in our version because it may easy some porting, will just slow starting up with no reasons.

@Raziel
In case with ScummVM, sobjes need it (at least for now) only for building on the amigaos native, the running are fine in static version still when it builds on cross-compiler. And it definitely noticeable when i just run 2 the same versions of scummvm : the one which build statically runs in a second. The one which use sobjs, take a 3 seconds for just a startup.

Quote:

Sure, just if it will slow starting up much, then on the same machines with limited ram (and then probably slow cpu), the loading speed will be even more noticeable and slower.

@kas1e

I don't care if an app needs their time to start up (even Odyssey has a splash screen, because it isn't instantly available).
It's not like we are talking minutes here...or our live depending on the start up time.

Give them apps their time to get everything ready, as long as it doesn't slow down anything while using the app, it's fine.
Saying that, i'm perfectly aware that ScummVM takes it's time if one closes a game, returns to the launcher and chooses to play another game...engine switching will make a new .so engine plugin load.

But to be perfectly honest, this is fine as well, as no one (i am aware of) is game jumping in ScummVM, and if there was one, he/she/it could always, like you wrote, grab the cross-compiled static build instead (which doesn´t have all the features of the local builds, i might add), if it bothers them so much.

I'll stick with shared objects in ScummVM, because i love the concept of having the engines as seperate files.

Once we (maybe) get a working debugger this will make debugging engine flaws a breeze (says the guy who knows nothing about coding)

...


plus, we shouldn't (again) start to limit stuff just for speed of development...we've been there and look how awesome Timberwolf came about /sarcasm off
Let's get the development environment ready and let the devs do what they imagine they want to do, if we limit "their" experience they will be out of the game faster than we could snap our fingers.

@kas1e

Quote:
You are aware that this project might not run very well (if at all) on anything else than the X series anyway?
(CPU grunt, RAM availability, maybe even GPU power will be important, don't get your hopes up to get an app that will run as fast as IBrowse or even Odyssey on anything lower than an X1000 - i don' t know that, of course, but just look at that beast...)

No matter what kind of tricks you pull or optimizations you build in, this browser will demand, and it's demands will be huge.

@kas1e
Quote:

I'd like to assure you all that we are not waiting for newlib changes. We provide information on what is needed and we work the webkit port with afxgroup's clib2.

The work rjd324 and afxgroup are doing with clib2 and the shared objects support are things that make clib2 even better for all of us.

We have been a little bit silent the past months, and that's not because we were doing nothing. On the contrary, we actually did a lot of work which I will try to summarize below.

We are working on porting all the needed libraries and helping afxgroup to develop further his new clib2. The work we do for webkit requires changes in adtools and gcc itself. This means that we do not actually work only on the webkit but a lot more stuff around our dev environment. We have some issues with threads which we try to solve which rjd324 is working to make pthreads work with clib2. All these changes are going to benefit not only the Webkit port but every software that will be created or ported in the future.

A couple of week ago we finished the majority porting of the needed third-party libraries like the harfbuzz and many others. They are all compiled with afxgroup's clib2 and are available at his ubuntu packaging server. These were blocking me from continuing the work on a mini-browser, but now I am able to continue that work and move it forward. So far we are at 42% of the port. The goal is to have a mini browser that would load a single page.

Meanwhile, we were updating our developing environment to have that up to date and easy to update when more changes will happen on afxgroup's clib2 or other tools.

We also have two more people joining our small team and helping us with what we are doing. They are FlynnTheAvatar and sTix, both very experienced developers and good guys to work with. We for sure have to gain a lot from their knowledge.

If you need more details on what we are doing please let us know. And make sure to follow our progress on WebKit port at the https://github.com/users/walkero-gr/projects/1

@walkeroQuote:

This reads very well. I hope you can find more support to make this project a reality.

Thanks for the status update.

@walkero

SO watching this space

@walkero

Thanks for the status update- it's good to know that progress is being made. It seems like every day Odyssey loses the ability to access another web site that used to work, so work towards an eventual replacement is very welcome.

Quote:
Something to look forward to in the next SDK!

Quote:
Hopefully these ports will also show up some place like OS4Depot, where they're accessible to native developers.

@walkero

Keep up the good work guys! Glad to hear you've got more people on board for this project!

Can we ask for some new information? :)

@mr2
I planned to give an update tomorrow, but since you asked, here it is.

For some time now, the port was around 54% of the WebCore library compilation. At that point, I was getting around 10K of errors, and I was trying to figure out why this was happening and where exactly was the problem. Just last week, with the help of Kas1e who discovered what was wrong, he found that the problem was a missing curly bracket I stupidly removed a year ago accidentally. By fixing that, I managed to have WebCore library compiling up to 99%.

What needs to be done as the next step, I hear you asking. Actually, I already started working on a minimal window with a web view that will be able to show just one website. That's the next goal.

I know that this is not much, but it is the next step we need to make. Depending on how hard or easy it is to do, I plan to have more frequent updates on how it goes.

You all can track the development at https://github.com/AmigaLabs/webkitty

As you might see from the link above, we changed the main repository, as it is now moved under our organisation named AmigaLabs. We decided to gather all our projects in one place, so that people can find them easier and track their progress. More on that in future announcements, as it is still quite new for us.

@walkero

Yay...progress

@walkero

Quote:

Thats good news I hope it will not be the case that the hardest is the last remainig percent
I was afraid that AOS4 had deficiencies that made it impossible to do this job.
Thanks a lot

@walkero

Thanks for this update, and thanks to the team for the work. Cheers!

@walkero

Thanks for the update and your work!

And the Amiga Elite Award 2023 goes to kas1e for finding THAT missing bracket! 10k compile errors must have felt like a good punch in the face.

@walkero

This is great news, I hope that at some point this project can result in a new, independent InterBrowser with the latest WebCore.

Or would it also be interesting for existing browsers like iBrowse/Odyssey/Netsurf?