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!