coverart-browser
coverart-browser copied to clipboard
Crashes when webkit support is missing
In the majority of the code there are checks in place to prevent importing Webkit
using the webkit_support
function, but in https://github.com/fossfreedom/coverart-browser/blob/master/coverart_artistinfo.py#L28 there is a direct import WebKit
which crashes coverart-browser when there is no webkit support.
Thanks for the report. Well caught!
The plugin needs to move on from using the now obsolete WebKit and move towards the supported webkit2 api. I would welcome any suggested fixes in this area.
I'll tag this and hopefully resolve soonest.
Well, I thought about doing a quick fix specifically for coverart_artistinfo.py
, but that whole view is basically a webkit view, so only thing I could do was make it a dummy, which seems kinda pointless.
Would it be possible to fix it without depending on webkit? I assuming moving to the webkit2 api there would still be a dependency on webkit.
I don't have webkit installed and would like to keep it that way since it's quiet a big package to install...
webkit2 is a different python package - you don't (and shouldn't) have both webkit and webkit2 in the same application.
The workaround fix to remove webkit usage is to stop the use of the artistinfo classes;
if you look at coverart_browser_source.py and search for "webkit" you can see how other areas of webkit usage is "worked around" - so you signal webkit support (or not) via a dconf-key.
so maybe something similar for using artistinfopane class in the same module - remove it from the import at the top of the source file - import it just before the usage of artistinfopane and surround the could with a "webkit_support()" if then catch statement.
Is there a workaround?
sorry - no workaround. The plugin needs some help from someone with a bit of time to remove the webkit part and fix outstanding issues caused by GTK+3.18 and later.