[Development] Development Digest, Vol 76, Issue 53
sschilz at pasco.com
Fri Jan 26 17:57:59 CET 2018
On 1/26/18, 7:22 AM, "Development on behalf of development-request at qt-project.org" <development-bounces+sschilz=pasco.com at qt-project.org on behalf of development-request at qt-project.org> wrote:
>On 25 Jan 2018, at 21:05, Steve Schilz <sschilz at pasco.com> wrote:
>>>>>>22.01.2018, 18:37, "Alberto Mardegan" <mardy at users.sourceforge.net>:
>>>>>> Hi all!
>>>>>> ??I've developed a desktop application which uses the WebView QML
>>>>>> module, with the hope of publishing it in the Apple store. However,
>>>>>> unless I am seriously mistaken, this is just not possible (or maybe the
>>>>>> documentation needs some serious love).
>>>>>> No matter what I try, it seems that QtWebEngine is always required!
>>>>>> If I simply remove QtWebEngine from my Qt installation, building the
>>>>>> application succeeds but then when I run it I get the same error as in
>>>>>> If I look at src/webview/qtwebviewfunctions.cpp it looks like the
>>>>>> decision to use the native webview vs QtWebEngine is done at runtime,
>>>>>> but for some reason it looks like one still needs to have QtWebEngine
>>>>>> available in order for QtWebView to build successfully. With the obvious
>>>>>> consequence that one won't be able to publish one's app into the Apple
>>>>>> Is there some reason why the QtWebEngine support library isn't dlopen'ed
>>>>>> at runtime? Can I file a bug about that?
>>>>>> From  it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable
>>>>>> is required to use native backend.
>>>>>>  https://codereview.qt-project.org/#/c/162337/
>>>>> ?On 22/01/2018 18:49, Konstantin Tokarev wrote:
>>>>> ?From  it seems like QT_MAC_USE_NATIVE_WEBVIEW environment variable is required to use native backend.
>>>>> ? https://codereview.qt-project.org/#/c/162337/
>>>> ?On 22 Jan 2018, at 18:22, Alberto Mardegan <mardy at users.sourceforge.net> wrote:
>>>> ?Yes, but still QtWebEngine is required, as QtWebView is linking to it.
>>>> ?I've now removed a few lines of code here and there and got a version of
>>>> ?QtWebView which builds fine under macos without being linked to QtWebEngine.
>>> ?I'll soon try to see if it actually works.
>>> >> 23.01.2018, 17:09, "Morten S?rvig" <morten.sorvig at qt.io>:
>>> The QtWebEngine requirement does seem to run counter to the purpose of the QtWebView module.
>>> It?s not really clear from the history what happened, but I think we can restore the original behavior:
>>> There was a discussion about run-time plugins in QtWebView, if they were implemented it won't be
>>> a problem to load and use QtWebEngine backend if it is really needed, and avoid it otherwise
>> 23.01.2018, 17:09, "Morten S?rvig" <mailto:morten.sorvig at qt.io>:
>> In the end we decided to go with this approach and finalize the plugin patch for dev. The other branches
>> will be left as-is. In the mean time it's possible is to build QtWebView from source with the above patch
>> If you want to avoid the QtWebEngine requirement.
>>Apologies in advance if this comes off in any way as rude, I love Qt, and respect everyone here greatly.
>>Am I correct in understanding that you are saying that prebuilt Qt packages cannot be used to submit to the app store,
>>And that anyone who wishes to use Qt to develop an app on OSX and submit to the app store must be savvy enough to
>>Build from source, and locate this thread in the dev newsgroup, and then apply the patch specified?
> I agree with this point, but as I said we concluded with not changing the current Qt versions. Order
> will be restored once the plugin patch is released. I?m not sure what the default plugin will be yet, but at
> the very least you can select the native plugin by not building QWebEngine or not deploying the QWebEngine
> plugin (e.g. with macdeployqt -appstore-compliant).
Thanks for the additional clarifications from Morten and Kai. It wasn't clear to me from the above discussion at 23.01.2018, 17:09
that there are definite plans to go forward with the plugin. We have been using Qt for 8 years now, since the 4.x timeframe, and
from that vantage point we definitely understand that things don't happen immediately, but that they do happen in as timely a
fashion as is possible while maintaining the high standards that Qt is known for.
More information about the Development