Le Fri, Feb 09, 2024 at 08:19:12AM +0100, Landry Breuil a écrit :
> Le Thu, Feb 08, 2024 at 09:06:44PM +0100, Rafael Sadowski a écrit :
> > On Thu Feb 08, 2024 at 07:54:26PM +0100, Landry Breuil wrote:
> > > Le Thu, Feb 08, 2024 at 03:12:17PM +0100, Rafael Sadowski a écrit :
> > > > Here is a simple diff to remove qtwebkit from. I modified configure.py
> > > > to make sure it will not picked up even it is present.
> > > > 
> > > > OK?
> > > 
> > > obvious question, but all the runtime consumers of py-qt5 been checked
> > > for not actually relying on qtwebkit ?
> > > 
> > 
> > I have prep'ed for webkit in all ports that use py-qt5.
> > 
> > What I see with my 99 years python experience:
> > 
> > - lots of "webkit" in qutebrowser, but it runs with py-qtwebengine and
> >   that's all css -webkit hacks.
> > - calibre and everything else looks good to me.
> > - I don't know if qgis parts are relevant
> 
> the qgis bits look to be for a bundled copy of it.. i havent tried
> runtime yet with qtwebkit disabled, but from what i've understood from
> some gh issues/PR identifying objects on layers with html format should
> still work.

now that i've tested 3.34.3p1, HTML query on features is rendered as
plaintext, so i guess there's some kind of fallback
mechanism/conversion.. not great, but i can live with that.

after some time i'll see what other features might be degraded.