Distros and QtWebEngine

[Jeremy Whiting]

Even simple applications may want to use a webview for stuff. Kanagram at
one point had a QtWebkit Web view just to show the wikipedia entry of the
current word. It was disabled because QtWebKit at the time was crashing.
I'd like to use something light and secure, but am not sure what options we
have going forward tbh.

On Mon, Apr 20, 2015 at 2:16 PM, Luigi Toscano <luigi.toscano at tiscali.it>
wrote:

> Albert Astals Cid ha scritto:
> > El Dilluns, 20 d'abril de 2015, a les 15:52:12, Lisandro Damián Nicanor
> Pérez
> > Meyer va escriure:
> >
> >> I could also say that Fedora+Debian+Debian derivatives (Ubuntu is
> mostly in
> >> the same position as us) is also a large userbase for KDE to loose.
> >>
> >> But *it's not really* about which distro or app is going to loose more
> user
> >> base, it's about keeping the current one. I don't want Debian nor KDE to
> >> loose users, in the same way I do not want to ship something that's
> >> unmaintainable.
> >
> > Maybe you guys should just trust the Qt project to maintain QtWebEngine
> and
> > just run with what they provide instead of needing 3 people to
> "maintain" it
> > yourselves?
>
> Qt project can maintain their bits, sure. Are they looking "inside" the big
> block, or do they import the core engine as it is? If the latter, well,
> it's
> not that simple as trusting them.
>
>
> >
> > What's wrong with that besides it going against your rules?
>
> The rules are there not because someone wants to have unhappy users; think
> about the rule about untangling tons of embedded libraries and patching
> issues.
>
> >
> > That you need to provide longer maintaince times than what Qt upstream
> > provides?
> >
> > Just state that there's no such long maintaince time for that package or
> just
> > install the newer version of Qt. And yes again that probably goes
> against your
> > rules, but it's your rules, so you can just improve them for everyone's
> > benefit :)
>
> Even Firefox ended up providing an yearly stable release for make it
> easier,
> and it's not an hard dependency (and they don't even provide a stable API).
>
>
> That said, let's talk for a moment on real use cases: how many applications
> can need an *hard* dependency on the beast, apart from mail apps?
>
> Ciao
> --
> Luigi
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20150420/c6da257e/attachment.htm>