Policy regarding QtWebKit and QtScript

[Thomas Friedrichsmeier]

Hi,

sorry for a somewhat bitter tone, I find it a bit hard to avoid(*):

On Sat, 5 Mar 2016 11:37:48 +0100
Allan Sandfeld Jensen <kde at carewolf.com> wrote:
> On Saturday 05 March 2016, Thomas Lübking wrote:
> > On Samstag, 5. März 2016 08:09:22 CEST, Thomas Friedrichsmeier
> > wrote:
> > > QtWebEngine can _only_ be compiled using (free
> > > as in beer) MSVC 2013. In particular, MinGW is explicitly _not_
> > > supported.
> > 
> > Out of pure curiosity: got details on this?
> > MSVC 2013 hardly supersets the GNU toolchain and the code cannot
> > make use of MSVC's "let's try to compile this junk, despite it's
> > not nearly valid c++" features, because it generally still needs to
> > compile on other systems.
> > 
> Chromium doesn't support it, and generally we try to stick to the
> same platforms Chromium support. We haven't actually investigated how
> much work it would be to make it work.

I think making a credible effort in that direction is really the _least_
thing you can and should do. I do understand your whole idea is to get
by with fewer (or no) patches(**). And I understand you are not
particularly keen to even think about introducing a significant
patch-set, when you have long since committed to QtWebEngine. But that
strategy simply carries a cost, and I'm not quite sure that this is
well-understood, yet.

As things stand, I think you are effectively phasing out MinGW-support,
and to be honest, my impression is that you have not been terribly
upfront about it, so far.

Regards
Thomas

---

(*) So, some background, in case anyone is interested: My application
needs an internal HTML-browser for several purposes. It also interfaces
with MinGW-only library / environment. (Why not try to support MSVC for
that library, I hear you ask? Because it has literally 8000+ add-on
packages, not all of which are cross-platform, not all of which contain
compiled code, but thousands of which are distributed as -
MinGW-compiled - binaries.)

I am lucky on two counts, here: First, I don't need to display any
remote HTML, and so I can get by using QtWebKit for now. But the time
will come when some of the add-ons start relying on browser features
that are not supported by QtWebKit, or some third application/framework,
that I'd like to interface with, will hard-depend on QtWebEngine.
Second, I am interfacing with a C-only API, and so I can (sort of) get
along with MSVC. But there are more subtleties in mixing the two
compilers than an incompatible C++-ABI, and these are no-fun at all to
debug. As one example, it took me almost an entire day to debug a
(deterministic!) crash, when the MinGW-library was trying to free a
pointer that I had to allocate myself (with MSVC). Getting lucky,
again, I did find a way to hack around this. But there are more,
non-derministic issues that appear to be unique to the MSVC-build.

(**) On the other hand, at least these patches would not be
Qt-specific. Even if they won't be upstreamed, I imagine you could
count on a least some community support in maintaining them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20160306/1da8396d/attachment.sig>