QtWebKit deprecated: MythBrowser plugin

MythTV / mythtv

The official MythTV repository

https://www.mythtv.org

GNU General Public License v2.0

700 stars 344 forks source link

QtWebKit deprecated: MythBrowser plugin #327

Open stuarta opened 3 years ago

stuarta commented 3 years ago

Mythbrowser plugin is using deprecated QtWebKit module

paul-h commented 2 years ago

I've attached my latest WIP patch to replace QWebKit with QWebEngine if anyone wants to test/help fix the remaining issues.

It isn't complete but has reached a point where it is mostly functional. webengine_v3.tar.gz

warpme commented 2 years ago

Paul, Many thanx for sharing you work. State is good - in sense that brief tests shows:

what works in qtwebkit also works in qtwebengine
what not works in qtwebkit also no works in qtwebengine

@all I think:

screen drawing issues described on ML are (imho) issue of mythtv as they are (in my case) very similar in: qtwebkit & qtwebengine)
ultimately i think mythtv should have selectable what web engine is used: qtwebkit or qtwebengine
reason to still keep of qtwebkit is it's perfect fit for small systems (i.e. in my case switch from qtwebkit to qtwebengine increases rootfs size by 25%).

stuarta commented 2 years ago

@warpme we don't really have a choice moving forward. QtWebKit is deprecated and the way forwards is QtWebEngine

warpme commented 2 years ago

oh - sure. I'm rather proposing: how to move froward.

going with QtWebEngine is no brainer. Q is about: what we will do with existing QtWebKit support. We can: a\keep optional (=>off by default unless asked explicitly to use instead of webengine with all consequences) b\remove (=>effectively loosing cases where WebKit is more preferable than WebEngine) I simply propose a\

in other words: do we want to have some more code+conditionals but address some corner cases or remove code and forget about optimal support of these corner cases?

stuarta commented 2 years ago

@warpme are there any cases where QtWekKit is preferrable to QtWebEngine (apart from any incomplete migration)???

warpme commented 2 years ago

Yes! MiniMyth2 :-)

garybuhrmaster commented 2 years ago

Yes! MiniMyth2 :-)

I somehow doubt that the users want an insecure browser. Have you asked them if that want an insecure implementation over a (at least arguable) more secure one?

QtWebKit has not gotten any of the chromium bug/security fixes for many many many years. In an appropriately controlled environment that might be ok, but it is not something someone typically designs for.

garybuhrmaster commented 2 years ago

ultimately i think mythtv should have selectable what web engine is used: qtwebkit or qtwebengine

The API is different (although similar). I would think supporting alternatives (to use the buggy/insecure implementation) will likely depend on someone (you?) creating a layering API for QtWebKit so that it offers the QtWebEngine API (if that is viable) and then they can just make sure to load the appropriate library during their builds (or using LD_PRELOAD at runtime, if they choose).

QtWebEngine is available in all the supported OS's that MythTV runs on. As far as I can remember the only time the devs worked to jump through hoops to support old and new Qt was when the OS's MythTV supported themselves had not yet moved forward. That is not the case here.

papoteur-mga commented 1 year ago

What is the status of this issue?

hamelg commented 6 months ago

any news ?

paul-h commented 6 months ago

https://forum.mythtv.org/viewtopic.php?p=22645#p22645

This post from the forum explains the current situation better https://forum.mythtv.org/viewtopic.php?p=26923#p26923