An odd debug message

[Peter Humphrey]

Hello list,

After an akonadictl stop and start I got this on the Konsole:

Qt WebEngine seems to be initialized from a plugin. Please set
Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute before
constructing QGuiApplication.

I thought this might be useful to someone - or should I report this to Gentoo?

[René J.V. Bertin]

Post by Peter Humphrey
Qt WebEngine seems to be initialized from a plugin. Please set
Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute before
constructing QGuiApplication.

Many KDE/Qt programs output such warnings/debug messages. Gentoo can't do
anything about it. The program developers can, so if you want to report it,
it should go to the KDE bugzilla.

Yep. It may not be of much consequence under Linux but the warning is there for a reason. IIRC applications can crash on Mac when OpenGL contexts aren't set to be shared.

Of course it's probably complete overkill that daemon processes would initialise a resource hog like QtWebEngine instead of using the much more appropriate QtWebKit but I'm afraid the powers have decided they wish to ignore that.

R.

[Peter Humphrey]

Post by René J.V. Bertin

Post by Peter Humphrey
Qt WebEngine seems to be initialized from a plugin. Please set
Qt::AA_ShareOpenGLContexts using QCoreApplication::setAttribute before
constructing QGuiApplication.

Many KDE/Qt programs output such warnings/debug messages. Gentoo can't do
anything about it...

OK; I just thought it might have been a subsystem configuration decision that
Gentoo had made.

Post by René J.V. Bertin

... The program developers can, so if you want to report it,it should go
to the KDE bugzilla.

https://bugs.kde.org/show_bug.cgi?id=400281

Post by René J.V. Bertin
Yep. It may not be of much consequence under Linux but the warning is there
for a reason. IIRC applications can crash on Mac when OpenGL contexts
aren't set to be shared.
Of course it's probably complete overkill that daemon processes would
initialise a resource hog like QtWebEngine instead of using the much more
appropriate QtWebKit but I'm afraid the powers have decided they wish to
ignore that.

No comment needed from me. ;)

[Ingo Klöcker]

Post by Peter Humphrey

Post by René J.V. Bertin
Of course it's probably complete overkill that daemon processes would
initialise a resource hog like QtWebEngine instead of using the much more
appropriate QtWebKit but I'm afraid the powers have decided they wish to
ignore that.

No comment needed from me. ;)

But from me, as (no longer actively programming) member of the KDE PIM team
and as moderator of this mailing list:
Please refrain from making uninformed allusions and claims. I perceive them as
unfriendly and detrimental for the motivation of the tiny group of still
active KDE PIM developers. Fact is that we were more or less forced to switch
because the Qt project deprecated Qt WebKit in Qt 5.5 [1] and removed it from
the official release packages in Qt 5.6 [2]. Since web engines are a mayor
attack target, we didn't really have much choice.

Regards,
Ingo

[1] https://wiki.qt.io/New_Features_in_Qt_5.5#Deprecated_Functionality
[2] https://wiki.qt.io/New_Features_in_Qt_5.6#Removed_Modules

[Pablo Sanchez]

This post might be inappropriate. Click to display it.

[René J.V. Bertin]

Critical, yes, and why not.

Thanks Erik.

Yes, I can be critical, but I try to be just and constructive. One of the uses of a user mailing list is also that it's a barometer that can show where things that aren't downright bugs could be done better.

I can understand the developers' decision to switch from QtWebKit tot
QtWebEngine.

I never said nor meant to imply I don't understand it at all. What I understand less is dropping support of the one for the other.
KDevelop also uses QWE by default for its documentation rendering, but it has never dropped support for QWK. I maintain a personal patch that adds support for using QTextBrowser. As far as I can tell the QWK code has just been working for the last couple of years, with little or no maintenance.

A productivity suite that is probably going to be running 24/24 7/7 should IMHO strive to be as lean as possible. If running it means we're basically running the equivalent of Chrome/ium behind the scenes, something we're probably all already running at the same time, then at some point resource considerations might well push many people to switch to using just the web browser.

Transistors may keep getting cheaper, but the form in which we need them does not - because software evolution makes we need ever more of them to keep a comparable level of performance. (Replacing my 7yo i7 13" MacBook Pro which is still mostly powerful enough for my needs with something equivalent that's equally future-proof as this one was will probably cost me twice the price I paid back then.)

Anyway, this has been off-topic long enough.

R.

[Paul Vixie]

Post by René J.V. Bertin
...
A productivity suite that is probably going to be running 24/24 7/7
should IMHO strive to be as lean as possible. ...

i disagree. we have to optimize for what we lack, not what we use. we
lack developer time we depend on; we do not lack the cpu cycles we use.
if the dev team were overfull of qualified people with a lot of time on
their hands, i'd say let's optimize for something else we lack.

[René J.V. Bertin]

Post by Ingo Klöcker
Please refrain from making uninformed allusions and claims.

It's not.

QtWebkit has been rebooted and the git repo holding it links to a page or two making a very strong point that QWK is better and leaner than QWE for just about everything except building a full-fledged web browser. That includes being significantly faster.
When I asked about bringing back support for it, after discovering that QWK was rebooted and that akonadi/kdepim now depend on QWE, I was told it wasn't going to happen. In a rather unfriendly manner too, I might add.
QWK may have been removed from the all-inclusive source tarball and the official installers, it has always been available as a community release. Given how the API hasn't evolved it should not have been that much of a burden to keep the old code behind a default-off build switch and leave the choice up to the user.

[Paul Vixie]

...QWK may
have been removed from the all-inclusive source tarball and the
official installers, it has always been available as a community
release. Given how the API hasn't evolved it should not have been
that much of a burden to keep the old code behind a default-off build
switch and leave the choice up to the user.

transistors are cheap and continuing to get cheaper.

human releng effort quite the opposite.

i am comfortable with the tradeoff they made.