> 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?
Let's keep in mind that this is about apps using Qt WebView and Qt WebEngine, not about the rest of Qt. > Wasn't this thread started by someone that was frustrated after having gone > through that exact process? > > We use QtWebEngine on Windows, and it works well, but do not use it on Mac or > iOS because of the App Store requirements. (We are a commercial customer) We tried to make Qt WebEngine on macOS to be compliant with the Mac App Store for some time. In Qt 5.9 there's a configure switch for it: -appstore-compliant. Anyhow, unfortunately we found out that this is not feasible anymore with newer Chromium versions, so we had to drop that for Qt 5.10 and future versions. But even in Qt 5.9 it was a (compile time) opt-in, because you effectively loose functionality which might not be what you want. > I was frustrated by a similar decision with Qt Multimedia where the default > backend on Windows was changed From > AVFoundation (Which can play x264 encoded video out of the box) to DirectShow > (which cannot). > > In both cases, this decision pushes users away from Qt because it does not > 'just work' as expected, and also > makes it necessary to compile Qt to get basic functionality working. > (IMHO, it should not be necessary for most end users to compile Qt) This is indeed a goal. But this is about tradeoffs: Unfortunately we don't have 'the perfect' backend that covers all use cases for Qt WebView on macOS right now. > Qt has gone to very great lengths with Qt Creator and the examples that 'just > work' out of the box, which in my Opinion is fantastic! > Although QtWebEngine is wonderful, it seems to me that given the App Store > requirements that we must use the native WebView, that it might be wise, and > benefit Qt as a whole to reconsider this decision. Indeed, and we agreed to solve this properly by introducing a plugin based architecture: https://codereview.qt-project.org/#/c/207651/ It's just not something you want to do in a patch level release, because stability. Regards Kai ________________________________ From: Development <development-bounces+kai.koehne=qt...@qt-project.org> on behalf of Steve Schilz <ssch...@pasco.com> Sent: Thursday, January 25, 2018 9:05:47 PM To: development@qt-project.org Subject: Re: [Development] Using Native web view on OS X >>>>> 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 A QML application that is using Webview will crash on ...<https://bugreports.qt.io/browse/QTBUG-63107> bugreports.qt.io No reviews matched the request. Check your Options in the drop-down menu of this sections header. >>>>> >>>>> 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/ Qt - Gerrit Code Review<https://codereview.qt-project.org/#/c/162337/> codereview.qt-project.org Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet Qt; Qt Repository Browser >>>>> >>>>> >>>>> 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/ Qt - Gerrit Code Review<https://codereview.qt-project.org/#/c/162337/> codereview.qt-project.org Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet Qt; Qt Repository Browser >>>> >>>> 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/ Qt - Gerrit Code Review<https://codereview.qt-project.org/#/c/217706/> codereview.qt-project.org Loading Gerrit Code Review... ... Qt Home; Qt Documentation; Qt-Project; Planet Qt; Qt Repository Browser >> >> 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? Wasn't this thread started by someone that was frustrated after having gone through that exact process? We use QtWebEngine on Windows, and it works well, but do not use it on Mac or iOS because of the App Store requirements. (We are a commercial customer) I was frustrated by a similar decision with Qt Multimedia where the default backend on Windows was changed From AVFoundation (Which can play x264 encoded video out of the box) to DirectShow (which cannot). In both cases, this decision pushes users away from Qt because it does not 'just work' as expected, and also makes it necessary to compile Qt to get basic functionality working. (IMHO, it should not be necessary for most end users to compile Qt) Qt has gone to very great lengths with Qt Creator and the examples that 'just work' out of the box, which in my Opinion is fantastic! Although QtWebEngine is wonderful, it seems to me that given the App Store requirements that we must use the native WebView, that it might be wise, and benefit Qt as a whole to reconsider this decision. Steve Schilz Software Engineer III PASCO scientific www.pasco.com<http://www.pasco.com> think science _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
