Konqueror - Swap over to WebKit #239

Open
opened 7 months ago by hunter0one · 13 comments
Collaborator

Since this has been in talks I thought it would be relevant to open this as a wishlist request for discussion in the future. It's no doubt that web browsing with Konqueror is a difficult task in the 2020's, only the most basic of websites still function right with the version of KHTML/TDEHTML that Trinity uses. I find perfecting Konqueror to be fundamental since its our flagship file and web browser that's touted out of the box so I think the best option would be to use a modern engine that's based on KHTML - WebKit. What exactly it takes to do it I don't know, but I wouldn't mind tinkering with this myself. Thoughts?

Since this has been in talks I thought it would be relevant to open this as a wishlist request for discussion in the future. It's no doubt that web browsing with Konqueror is a difficult task in the 2020's, only the most basic of websites still function right with the version of KHTML/TDEHTML that Trinity uses. I find perfecting Konqueror to be fundamental since its our flagship file and web browser that's touted out of the box so I think the best option would be to use a modern engine that's based on KHTML - WebKit. What exactly it takes to do it I don't know, but I wouldn't mind tinkering with this myself. Thoughts?
hunter0one added the
SL/wishlist
label 7 months ago
Collaborator

I've done some research myself. This involves doing a port of WebKit to TQt/Trinity by writing all the platform-specific bits and integrating it all into their CMake scripts. One could do a fork of WebKit for this purpose (like QtWebKit did) or get in touch with the WebKit guys and push the changes back into upstream.

I've done some research myself. This involves doing a port of WebKit to TQt/Trinity by writing all the platform-specific bits and integrating it all into their CMake scripts. One could do a fork of WebKit for this purpose (like QtWebKit did) or get in touch with the WebKit guys and push the changes back into upstream.
Collaborator

The port should use the TDEParts technology in order to be usable in Konqueror and other TDE apps.

The port should use the TDEParts technology in order to be usable in Konqueror and other TDE apps.
Poster
Collaborator

I figured it would need to be forked (like WebKitGTK or Qtwebkit) so we can make a TQtWebKit.

I was also thinking TDEParts was still called KParts, but couldnt find that. Good to know =)

I figured it would need to be forked (like WebKitGTK or Qtwebkit) so we can make a TQtWebKit. I was also thinking TDEParts was still called KParts, but couldnt find that. Good to know =)
Owner

Konqueror is indeed outdated as a web browser and mostly unusable for that. It definitely needs an update for modern times :-)

Thoughts?

You are welcome to thinker with it and if you get a working version in future, we will definitely take a look at it.

I figured it would need to be forked (like WebKitGTK or Qtwebkit) so we can make a TQtWebKit.

I have no knowledge of the internals of WebKit, but I guess that is probably the way to go. One key point if we go this way, is how we make sure we keep it up to date as things evolve?
If there was a way to have a TQt/TDE wrapper build around the upstream webkit, it would likely be more maintainable in future, but as I said, I don't know the internals, so perhaps I am just saying something totally unfeasable or wrong.

Konqueror is indeed outdated as a web browser and mostly unusable for that. It definitely needs an update for modern times :-) > Thoughts? You are welcome to thinker with it and if you get a working version in future, we will definitely take a look at it. > I figured it would need to be forked (like WebKitGTK or Qtwebkit) so we can make a TQtWebKit. I have no knowledge of the internals of WebKit, but I guess that is probably the way to go. One key point if we go this way, is how we make sure we keep it up to date as things evolve? If there was a way to have a TQt/TDE wrapper build around the upstream webkit, it would likely be more maintainable in future, but as I said, I don't know the internals, so perhaps I am just saying something totally unfeasable or wrong.
Poster
Collaborator

If there was a way to have a TQt/TDE wrapper build around the upstream webkit, it would likely be more maintainable in future, but as I said, I don't know the internals, so perhaps I am just saying something totally unfeasable or wrong.

😄 Me neither. I was pretty sure things like WebKitGTK are forks, but they may be wrappers. Taking a look at their git pages it doesn't look like there's that much to porting a toolkit over to WebKit, but that's just from first glance. I need to actually experiment with it to find out.

Needless to say, if we pull this off, Konqueror could be the best WebKit browser available for FOSS Unix-likes. There's the very bare Midori and... That's about it?

> If there was a way to have a TQt/TDE wrapper build around the upstream webkit, it would likely be more maintainable in future, but as I said, I don't know the internals, so perhaps I am just saying something totally unfeasable or wrong. 😄 Me neither. I was pretty sure things like WebKitGTK are forks, but they may be wrappers. Taking a look at their git pages it doesn't look like there's *that* much to porting a toolkit over to WebKit, but that's just from first glance. I need to actually experiment with it to find out. Needless to say, if we pull this off, Konqueror could be the best WebKit browser available for FOSS Unix-likes. There's the very bare Midori and... That's about it?
Owner

Just to get this written down as reference:
http://kde-apps.org/content/show.php/WebkitGTK+KParts+for+konqueror+KDE+3.5?content=161554

This should be an insiparation rather than a port, since we should try to stay away from GTK dependency where possible.

Just to get this written down as reference: http://kde-apps.org/content/show.php/WebkitGTK+KParts+for+konqueror+KDE+3.5?content=161554 This should be an insiparation rather than a port, since we should try to stay away from GTK dependency where possible.
Poster
Collaborator

Interesting, this can be reverse engineered for TQt instead. I agree, we are the source for Qt3 (Tqt3) and its best we stick to it.

Interesting, this can be reverse engineered for TQt instead. I agree, we *are* the source for Qt3 (Tqt3) and its best we stick to it.

I don't know if It's even doable but the html/javascript Basilisk engine (https://www.basilisk-browser.org) forked from Mozilla might also be a candidate.

Palemoon is been using/developping It since Mozilla went all Rust, we can notice that they have grafted a GTK+3 UI over It lately.

I don't know if It's even doable but the html/javascript Basilisk engine (https://www.basilisk-browser.org) forked from Mozilla might also be a candidate. Palemoon is been using/developping It since Mozilla went all Rust, we can notice that they have grafted a GTK+3 UI over It lately.
Collaborator

I don't know if It's even doable but the html/javascript Basilisk engine (https://www.basilisk-browser.org) forked from Mozilla might also be a candidate.

Mozilla itself has dropped the embedding code a long time ago, with no working alternatives. The Gecko/Goanna engine used in Basilisk+PaleMoon does not care about the embedding code either. The only way to use seems to be developing a UXP/XPCOM application, that is with the graphical toolkit which imitates the native toolkit via GTK+2/3. Unfortunately, making it to use TQt looks like it would be more trouble than it's worth it.

Still, https://mirror.git.trinitydesktop.org/gitea/TDE/tdebindings/src/branch/master/xparts/mozilla (using the XParts technology) might be worth a look, but maybe a WebKit port is a priority after all.

> I don't know if It's even doable but the html/javascript Basilisk engine (https://www.basilisk-browser.org) forked from Mozilla might also be a candidate. Mozilla itself has dropped the embedding code a long time ago, with no working alternatives. The Gecko/Goanna engine used in Basilisk+PaleMoon does not care about the embedding code either. The only way to use seems to be developing a UXP/XPCOM application, that is with the graphical toolkit which imitates the native toolkit via GTK+2/3. Unfortunately, making it to use TQt looks like it would be more trouble than it's worth it. Still, https://mirror.git.trinitydesktop.org/gitea/TDE/tdebindings/src/branch/master/xparts/mozilla (using the XParts technology) might be worth a look, but maybe a WebKit port is a priority after all.
Owner

Still, https://mirror.git.trinitydesktop.org/gitea/TDE/tdebindings/src/branch/master/xparts/mozilla (using the XParts technology) might be worth a look, but maybe a WebKit port is a priority after all.

I think a port of WebKit is definitely likely to be more functional, considering how old are TDE code base origins.

> Still, https://mirror.git.trinitydesktop.org/gitea/TDE/tdebindings/src/branch/master/xparts/mozilla (using the XParts technology) might be worth a look, but maybe a WebKit port is a priority after all. I think a port of WebKit is definitely likely to be more functional, considering how old are TDE code base origins.
Owner

It may be worth considering back porting QtWebKit from Qt4, it may be easier to do.

It may be worth considering back porting QtWebKit from Qt4, it may be easier to do.
Poster
Collaborator

It could be backported and then patched. I think whenever KDE started pushing WebEngine they gave up on QtWebKit (at least for use in the Plasma version of Konqueror).

It could be backported and then patched. I think whenever KDE started pushing WebEngine they gave up on QtWebKit (at least for use in the Plasma version of Konqueror).
Collaborator

QtWebKit has not been receiving security updates for a while or so. The best for security would be starting off with the most fresh WebKit revision (ideally an interface over a WebKit backend which could easily pull updates from Git without the need for code changes to Trinity-specific code).

Taking manpower into account, it might be easier to consider CEF as a (temporary?) solution. I have been experimenting with CEFPython and TQt/TDE Python bindings and it seems feasible to create a part/interface over CEF which could be easily updated afterwards. The only drawback is I couldn't find any way to make extensions of any kind work.

QtWebKit has not been receiving security updates for a while or so. The best for security would be starting off with the most fresh WebKit revision (ideally an interface over a WebKit backend which could easily pull updates from Git without the need for code changes to Trinity-specific code). Taking manpower into account, it might be easier to consider CEF as a (temporary?) solution. I have been experimenting with CEFPython and TQt/TDE Python bindings and it seems feasible to create a part/interface over CEF which could be easily updated afterwards. The only drawback is I couldn't find any way to make extensions of any kind work.
Sign in to join this conversation.
No Milestone
No Assignees
4 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.