Qt 5.15 Released With Graphics Improvements, Preparations Ahead Of Qt 6

[carewolf]

Seriously, why has every UI framework their own webkit fork? Can't they depend on a common library?

That would require somebody to write and maintain one. Also you usually need different integrations. At least for WebKit it had different backends depending on what it integrated into, making each integration very unique. Chromium is more top down and could be reusably, if Google actually cared to maintain a reusable library, which they do not (also there is the debate over removing all the questionable call-home features of Chromium that Google does not like to have removed, but many others do).

[bug77]

Seriously, why has every UI framework their own webkit fork? Can't they depend on a common library?

Google and Apple tried to share Webkit and it didn't work out. Turned out they had different priorities and didn't see eye to eye every time. Google ended up forking and is now using Blink.

[ssokolow]

That would require somebody to write and maintain one. Also you usually need different integrations. At least for WebKit it had different backends depending on what it integrated into, making each integration very unique. Chromium is more top down and could be reusably, if Google actually cared to maintain a reusable library, which they do not (also there is the debate over removing all the questionable call-home features of Chromium that Google does not like to have removed, but many others do).

Also, I don't know if they ported it to QWebEngine, but I know QtWebKit added an API the other integrations didn't offer, which allowed querying and manipulation of the DOM directly from C++ in a Selenium-like fashion, rather than by eval-ing snippets of JavaScript like the other integrations required.

[ZeroPointEnergy]

Google and Apple tried to share Webkit and it didn't work out. Turned out they had different priorities and didn't see eye to eye every time. Google ended up forking and is now using Blink.

But that does not explain why there is qtwebkit and gtkwebkit. Why don't they use one of the two libs and maintain their own fork?

[DanL]

It's an LTS for paying consumers.

Maybe you missed this part?:

Qt 5.15 is available now for all our users. For our open source users, it will be supported in the same way as other regular Qt releases until the release of Qt 6. For commercial customers, Qt 5.15 will be long-term-supported (LTS) for three years with regular bug fix releases beyond the release of Qt 6.

[Vistaus]

But that does not explain why there is qtwebkit and gtkwebkit. Why don't they use one of the two libs and maintain their own fork?

Qt WebKit? What are you talking about? That has been dead for years (except for an updated community fork, but that's not Qt's responsibility). QtWebEngine is what replaced it and is based on Blink, which is a WebKit fork. So QtWebEngine and GTKWebKit could never use the same lib as they both have a different base.

[Setif]

They don't offer installers, only source code.

http://download.qt.io/archive/qt/5.15/5.15.0/

[ZeroPointEnergy]

Qt WebKit? What are you talking about? That has been dead for years (except for an updated community fork, but that's not Qt's responsibility). QtWebEngine is what replaced it and is based on Blink, which is a WebKit fork. So QtWebEngine and GTKWebKit could never use the same lib as they both have a different base.

Yeah I don't really care whos responsibility it is. I was just complaining about the fact that each of this projects bring with them a complete fork of webkit in their sources and don't depend on an upstream lib. And the question is: why is that?

[cl333r]

It took at least a year for Qt 5 to be stable enough to serve as a usable replacement. Get ready to use this one for a while.

More like 5 years, at least, because one's project needs to wait on all other projects it depends on to transition too, and those projects could be in same situation, catch 22?

[bug77]

But that does not explain why there is qtwebkit and gtkwebkit. Why don't they use one of the two libs and maintain their own fork?

I thought it explains it perfectly: different needs, different priorities.
I'm pretty sure they're both upstreaming where it makes sense and keep customizations to a minimum. Otherwise it would be pretty hard to keep up.