Christian Dersch wrote:
> as we have QupZilla 2 in Fedora 24, which uses QtWebEngine (based on
> Chromiums rendering engine) and everything works very well here, I'll
> propose it as the new default browser starting with Fedora 25.
Yes, this is way overdue!
> We already have it in Fedora 24 spin as a preview (be sure to update to
> 2.0.1 before using it), but the default is Firefox right now.
Unfortunately. (I don't understand why QupZilla wasn't considered good
enough for Fedora 24 already.)
> Some features:
> * Qt5 based => Integrates perfectly in Plasma
In particular, it uses Qt theming (*), system icons (*), KDE file dialogs
(**), etc.
(*) Breeze by default under Plasma, but it follows the setting from KDE
System Settings, as all Qt applications
(**) KDE ones under Plasma, in general whatever the Qt platform plugin
defines on the desktop the user is using
> * Able to use KWallet (we have to add package qupzilla-kwallet to spin)
To be fair, there are, however, some limitations to KWallet support:
* The support is not enabled by default just by installing the package. In
fact, the user even has to enable it in 2 places:
1. enable the plugin in the list of plugins, and
2. set the password store to KWallet in the password-related settings.
* Passwords are stored in a QupZilla-specific format in an
application-specific section of the wallet. They are not shared with KHTML
or KWebKitPart (not even the KF5 versions – Konqueror is stuck on the KDE
4 ones, which are not even in the same wallet), which use the shared
password store of KWallet, not an application-specific store. So you get
only the single sign-on of KWallet (and improved security if you use a
nonempty KWallet password), but not the cross-application sharing.
But keep in mind that the alternative (Firefox) does not support KWallet at
all!
> * Adblocker included
That's a good point. Firefox, on the other hand, even tried to serve you its
own ads! (I've read recently that they backpedaled on that in recent
versions, not sure.)
> Even though Fedora QtWebEngine is shipped without proprietiary or
> patented codecs, most stuff like Youtube just works fine. It is also
> possible to replase QtWebEngine by a self-compiled one with all codecs
> without rebuild of QupZilla (maybe an option for rpmfusion?), then
> almost all pages work (not the ones using Flash, it is possible to use
> Chrome Flash Plugin).
A rebuilt QtWebEngine is indeed something RPM Fusion could carry. We could
also build the bundled FFmpeg as a shared library, which is easier to
replace, if wanted, but it is probably better to rebuild the whole
QtWebEngine because Chromium code hardcodes at compile time in several
places whether it supports "proprietary" (i.e., patent-encumbered) codecs or
not.
I had hoped to get GStreamer support working, but that is more work to get
going, I need changes in GStreamer packaging that have not been applied yet,
and a fix for the aforementioned compile-time hardcoding (which also affects
the GStreamer backend, see
https://github.com/Samsung/ChromiumGStreamerBackend/issues/16 ), and then
also testing with QtWebEngine (the GStreamer code was only ever tested with
vanilla Chromium). So this is something for the future. For now, a rebuild
of QtWebEngine with an uncensored FFmpeg in a third-party repository is the
best that can be done.
> I know many use Firefox and are also power users of this browser. My
> intention is to bring new users a well integrated experience of Plasma
> and for most users QupZilla will be fine. Of course people who prefer
> another browser like Firefox can install it after installation ;)
Indeed. I consider it a major embarassment for something that calls itself a
"KDE Spin" to choose a non-KDE, non-Qt application whose look&feel sticks
out like a sore thumb for probably the most used application role, when a
perfectly fine Qt alternative with decent Plasma integration is available.
Firefox was clearly only a stopgap when all we had was an outdated
Konqueror/KWebKitPart4/Qt4WebKit (and an ancient Konqueror/KHTML4). The main
arguments for Firefox back then (compared to Qt4WebKit
(Konqueror/KWebKitPart) or even Qt5WebKit (e.g. QupZilla 1.8.6)), i.e.:
* compatibility with websites out there,
* JavaScript execution speed,
* availability of security fixes,
are all no longer relevant with QtWebEngine-based QupZilla 2 (which even
beats Firefox on some of these points).
Kevin Kofler
_______________________________________________
kde mailing list
kde@xxxxxxxxxxxxxxxxxxxxxxx
https://lists.fedoraproject.org/admin/lists/kde@xxxxxxxxxxxxxxxxxxxxxxx
