On 1/26/18, 7:22 AM, "Development on behalf of
development-requ...@qt-project.org"
<development-bounces+sschilz=pasco....@qt-project.org on behalf of
development-requ...@qt-project.org> wrote:
>On 25 Jan 2018, at 21:05, Steve Schilz <ssch...@pasco.com> wrote:
>>>>>>22.01.2018, 18:37, "Alberto Mardegan" <ma...@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
>>>>>> https://bugreports.qt.io/browse/QTBUG-63107
>>>>>> 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
>>>>>> store.
>>>>>> Is there some reason why the QtWebEngine support library isn't
dlopen'ed
>>>>>> at runtime? Can I file a bug about that?
>>>>>> From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW environment
variable
>>>>>> is required to use native backend.
>>>>>> [1] https://codereview.qt-project.org/#/c/162337/
>>>>>>Ciao,
>>>>>? ?Alberto
>>>>> ?On 22/01/2018 18:49, Konstantin Tokarev wrote:
>>>>> ?From [1] it seems like QT_MAC_USE_NATIVE_WEBVIEW
environment variable is required to use native backend.
>>>>>
>>>>> ?[1] https://codereview.qt-project.org/#/c/162337/
>>>>> Regards,
>>>>> Konstantin
>>>> ?On 22 Jan 2018, at 18:22, Alberto Mardegan
<ma...@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.
>>>> ?Ciao,
>>>> ??Alberto
>>> >> 23.01.2018, 17:09, "Morten S?rvig" <morten.sor...@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:
>>> https://codereview.qt-project.org/#/c/217706/
>>> 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
>>> Morten
>> 23.01.2018, 17:09, "Morten S?rvig" <mailto:morten.sor...@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.
>>
>> Morten
>>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).
>
> Morten
>
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.
Steve Schilz
Pasco Scientific
Think Science
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
