[Interest] Qt 6.3.0 and OpenGL on macOS [was: Re: Creating fat binaries for Qt6 on macOS]
> On Apr 13, 2022, at 06:52, Sze Howe Koh wrote: > Apple has let their OpenGL implementation stagnate since 2010 [1]. > They then officially deprecated it in 2018, citing significant > advantages of Metal over OpenGL [2]. They have not revealed when > OpenGL will be removed. > > Most of Qt Quick works well with Metal -- it's only QQuickWidget that > doesn't. In contrast, the graphics API setting affects all of Qt > Quick. Furthermore, QQuickWidget has limitations [3] compared to other > ways of displaying a Qt Quick UI, so it shouldn't be the first choice > unless you really need to mix widgets with Qt Quick. > > Given all this, I don't think it makes sense for Qt to default to > something that can be killed off any day now, just to make it easier > to use QQuickWidget. > > In any case, I think the error message "QQuickWidget is only supported > on OpenGL. Use QQuickWindow::setGraphicsApi() to override the default" > is clear enough as a once-off message for those who want to use > QQuickWidget. So I finally found time to try and figure out what to do here. This is all rather confusing. I have two different QML modules that are included in my Qt Widget based app. One of them works. It shows maps, not a problem. I get the warning: QQuickWidget is only supported on OpenGL. Use QQuickWindow::setGraphicsApi() to override the default. but it still works just fine. The other one, however, crashes in the software render when I try to instantiate the Widget: Exception Type:EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x Exception Codes: 0x0001, 0x Exception Note:EXC_CORPSE_NOTIFY Termination Reason:Namespace SIGNAL, Code 11 Segmentation fault: 11 Terminating Process: exc handler [80775] VM Region Info: 0 is not in any region. Bytes before following region: 4332961792 REGION TYPESTART - END [ VSIZE] PRT/MAX SHRMOD REGION DETAIL UNUSED SPACE AT START ---> __TEXT 10243c000-102aa8000[ 6576K] r-x/r-x SM=COW ...OS/Subsurface Kernel Triage: VM - Compressor failed a blocking pager_get VM - Compressor failed a blocking pager_get VM - Compressor failed a blocking pager_get Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 QtQuick0x1057423a8 QSGSoftwareRenderableNode::update() + 544 (qsgsoftwarerenderablenode.cpp:187) 1 QtQuick0x1057423a8 QSGSoftwareRenderableNode::update() + 544 (qsgsoftwarerenderablenode.cpp:187) 2 QtQuick0x105744a6c bool QSGSoftwareRenderableNodeUpdater::updateRenderableNode(QSGSoftwareRenderableNode::NodeType, QSGImageNode*) + 288 (qsgsoftwarerenderablenodeupdater_p.h:135) 3 QtQuick0x10577eb24 QSGNodeVisitorEx::visitChildren(QSGNode*) + 108 (qsgadaptationlayer.cpp:355) 4 QtQuick0x105746008 QSGSoftwareRenderableNodeUpdater::updateNodes(QSGNode*, bool) + 1100 (qsgsoftwarerenderablenodeupdater.cpp:282) 5 QtQuick0x10573826c QSGAbstractSoftwareRenderer::nodeAdded(QSGNode*) + 124 (qsgabstractsoftwarerenderer.cpp:267) 6 QtQuick0x105737ee4 QSGAbstractSoftwareRenderer::nodeChanged(QSGNode*, QFlags) + 164 (qsgabstractsoftwarerenderer.cpp:108) 7 QtQuick0x105772750 QSGRootNode::notifyNodeChange(QSGNode*, QFlags) + 44 (qsgnode.cpp:1277) [inlined] 8 QtQuick0x105772750 QSGNode::markDirty(QFlags) + 84 (qsgnode.cpp:671) [inlined] 9 QtQuick0x105772750 QSGNode::appendChildNode(QSGNode*) + 144 (qsgnode.cpp:454) 10 Subsurface 0x10272c2a4 ChartPixmapItem::render(StatsTheme const&) + 172 (chartitem.cpp:71) 11 Subsurface 0x10276006c StatsView::updatePaintNode(QSGNode*, QQuickItem::UpdatePaintNodeData*) + 160 (statsview.cpp:186) Ok, so maybe the software renderer is the problem... after all everyone tells me to use OpenGL QT_QUICK_BACKEND="opengl" ./Subsurface.app/Contents/MacOS/Subsurface -v ... Could not create scene graph context for backend 'opengl' - check that plugins are installed correctly in /Users/hohndel/src/subsurface/build/Subsurface.app/Contents/PlugIns QQuickWidget is only supported on OpenGL. Use QQuickWindow::setGraphicsApi() to override the default. So I'm trying to use the OpenGL backend, but it's unclear how to do that. I looked high and lo for such a plugin. I copied all plugins... nothing. I saw elsewhere that I actually should include the OpenGL component when building like this: find_package(Qt6 COMPONENTS OpenGL) LIST(APPEND SUBSURFACE_LINK_LIBRARIES Qt6::OpenGL) That builds, but
Re: [Interest] Creating fat binaries for Qt6 on macOS
> On Apr 13, 2022, at 03:52, Sze Howe Koh wrote: >>> >>> My guess is that it has to be explicit on your side because Metal has some >>> advantage that OpenGL doesn't. I wouldn't know what, since it's not an area >>> I >>> pay attention to. >>> >> >> :-) >> >> So instead of defaulting to something that works, Qt defaults to something >> that >> may have some vague advantage that you aren't certain about. >> >> Solid reasoning. 藍 > > Apple has let their OpenGL implementation stagnate since 2010 [1]. > They then officially deprecated it in 2018, citing significant > advantages of Metal over OpenGL [2]. They have not revealed when > OpenGL will be removed. > > Most of Qt Quick works well with Metal -- it's only QQuickWidget that > doesn't. In contrast, the graphics API setting affects all of Qt > Quick. Furthermore, QQuickWidget has limitations [3] compared to other > ways of displaying a Qt Quick UI, so it shouldn't be the first choice > unless you really need to mix widgets with Qt Quick. Thanks for that explanation. I really appreciate it. Yes, this is a complex classic Qt application (started in the days of Qt4) with a ton of widget based code, which uses QtQuick for two specific purposes (maps and statistics) embedded into the widget UI. So we do need to use QQuickWidget, I believe. If there's another way to do this, please let me know! > Given all this, I don't think it makes sense for Qt to default to > something that can be killed off any day now, just to make it easier > to use QQuickWidget. Yes, you are correct. I apologize for my snarky remark, based on partial information. > In any case, I think the error message "QQuickWidget is only supported > on OpenGL. Use QQuickWindow::setGraphicsApi() to override the default" > is clear enough as a once-off message for those who want to use > QQuickWidget. Yes /D ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Creating fat binaries for Qt6 on macOS
> On Apr 12, 2022, at 06:20, Thiago wrote: > > On Monday, 11 April 2022 23:17:17 PDT Dirk Hohndel wrote: >>> The error message is talking about how the same path was being removed >>> more >>> than once, which means your binary has it twice. I guess this had simply >>> never occurred in the past. Deduplicating the paths is not a bad idea in >>> macdeployqt, but you can also investigate why your build arrived at this >>> point with twice the same rpath and change that. >> >> I will look into this. I'm thinking that this is a result of this being fat >> binaries with identical rpath in both sides. > > It's possible. The tool is parsing the output of otool -l, so if that prints > the rpaths for both members of the fat binary, it would indeed get confused. That's exactly what it does. I'm surprised that no one else ran into this, though. After all, the Qt distribution binaries are all fat binaries. Here's an example: % otool -l Subsurface.app/Contents/MacOS/Subsurface | grep -A2 LC_RPATH cmd LC_RPATH cmdsize 48 path /Users/hohndel/src/install-root/lib (offset 12) -- cmd LC_RPATH cmdsize 48 path /Users/hohndel/Qt/6.3.0/macos/lib (offset 12) -- cmd LC_RPATH cmdsize 32 path @executable_path (offset 12) -- cmd LC_RPATH cmdsize 128 path /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6/lib/darwin (offset 12) -- cmd LC_RPATH cmdsize 48 path /Users/hohndel/src/install-root/lib (offset 12) -- cmd LC_RPATH cmdsize 48 path /Users/hohndel/Qt/6.3.0/macos/lib (offset 12) -- cmd LC_RPATH cmdsize 32 path @executable_path (offset 12) -- cmd LC_RPATH cmdsize 128 path /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/13.1.6/lib/darwin (offset 12) > >> So... hear me out here... if Qt can switch to OpenGL... and if this thingy >> doesn't work unless it's OpenGL... shouldn't Qt simply switch to OpenGL? >> Or is this too radically useful? > > My guess is that it has to be explicit on your side because Metal has some > advantage that OpenGL doesn't. I wouldn't know what, since it's not an area I > pay attention to. :-) So instead of defaulting to something that works, Qt defaults to something that may have some vague advantage that you aren't certain about. Solid reasoning. 藍 I'll keep playing with the rest and send updates once I have more time figuring out the details. /D___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Creating fat binaries for Qt6 on macOS
Hi Thiago, Thanks for the detailed response. > On Apr 11, 2022, at 13:43, Thiago wrote: > > On Sunday, 10 April 2022 10:22:21 PDT Dirk Hohndel wrote: >> ERROR: "error: >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolch >> ain/usr/bin/install_name_tool: \"-delete_rpath >> /Users/hohndel/src/install-root/lib\" specified more than once\nUsage: >> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolch >> ain/usr/bin/install_name_tool [-change old new] ... [-rpath old new] ... >> [-add_rpath new] ... [-delete_rpath old] ... [-id name] input\n" > > This one looks like a legitimate bug. The code doing the looping that adds > -delete_rpath has been there since 2014 and the man page for it says: > > -delete_rpath old > deletes the rpath path name old in the specified Mach-O > binary. More than one of these options can be specified. [...] > > The error message is talking about how the same path was being removed more > than once, which means your binary has it twice. I guess this had simply > never > occurred in the past. Deduplicating the paths is not a bad idea in > macdeployqt, but you can also investigate why your build arrived at this > point > with twice the same rpath and change that. I will look into this. I'm thinking that this is a result of this being fat binaries with identical rpath in both sides. >> QQuickWidget is only supported on OpenGL. Use QQuickWindow::setGraphicsApi() >> to override the default. > >> That first error is weird... I thought Qt on macOS was using OpenGL.. > > No, it now uses Metal. Because Apple likes to deprecate perfectly good APIs > and replace with something new. We don't do that on Linux (*cough* PipeWire > *cough*)... > > https://doc.qt.io/qt-6/quick-changes-qt6.html#changes-to-qquickwidget > "QQuickWidget is functional only when the scenegraph is rendering with > OpenGL. > It will not be functional when using another graphics API, such as Vulkan or > Metal. Applications relying on QQuickWidget should force the usage of OpenGL > by calling QQuickWindow::setGraphicsApi(QSGRendererInterface::OpenGL) in > their > main() function." > > I don't know why the default has changed or why Metal is better. Maybe > someone > else can chime in. So... hear me out here... if Qt can switch to OpenGL... and if this thingy doesn't work unless it's OpenGL... shouldn't Qt simply switch to OpenGL? Or is this too radically useful? >> And that second one is why I'm mainly writing this message... because >> QtQml.WorkerScript is there. macdeployqt doesn't copy it (I'll need to >> figure out how to write a bug report for that one), but I manually copy it >> in place: >> >> % ls -l ./Subsurface.app/Contents/Frameworks/QtQmlWorkerScript.framework > > That's the framework. There must be a plugin somewhere. I have the plugin in my plugin path. The error went away after I forced an explicit link against this framework. Makes no sense to me, TBH >> Any idea what I may be doing wrong? This appears to work if I only build an >> arm64 binary. But I get the error above for a fat binary. All the libraries >> and plugins that I can find are indeed fat, e.g.: >> >> % lipo -info >> ./Subsurface.app/Contents/Frameworks/QtQmlWorkerScript.framework/QtQmlWorke >> rScript Architectures in the fat file: >> ./Subsurface.app/Contents/Frameworks/QtQmlWorkerScript.framework/QtQmlWorke >> rScript are: x86_64 arm64 >> >> Any pointers welcome :) > > Probably a failure to load the plugin, for one of two reasons: either > QPluginLoader concluded the file in question isn't a valid plugin, or it did > but dlopen() subsequently failed. That's what I thought as well. The debugging output was extremely useless. And thanks to macOS being infallible, we of course have no decent 'stroke' replacement anymore, so that felt hard as well. > Can you run with QT_DEBUG_PLUGINS=1 set in your environment and see if it > logs > a reason why? Unlike the new COFF-PE parser and the rewritten ELF parser, I > didn't add extra debugging to the Mach-O parser itself in 2013. But it should > accurately report at the end why it doesn't think a given .dylib isn't a > plugin. Yes, I'll do that... that requires undoing my "hack" to make things work, though. I'm not sure my brain is fresh enough right now to work on that and create useful information. 4+ hours of diving make you tired... > As you said it works if you build thin binaries, either there's something > that > remained thin and you're missing it, or most likely there's a failure in that > parser trying
[Interest] Creating fat binaries for Qt6 on macOS
Hi all,
I'm running into a number of interesting problems on macOS. I am testing
against the 6.3.0 RC
This is for a fairly complex app called Subsurface, in case anyone cares.
When I create fat binaries for the app by setting CMAKE_OSX_ARCHITECTURES to
arm64;x86_64 things mostly work, but a couple of odd things throw me off.
In the make install step I get this error from macdeployqt
Log: change rpaths in
"/Users/hohndel/src/subsurface/build/Subsurface.app/Contents/MacOS/Subsurface"
Log: using QList("-delete_rpath", "/Users/hohndel/src/install-root/lib",
"-delete_rpath", "/Users/hohndel/Qt/6.3.0/macos/lib", "-delete_rpath",
"/Users/hohndel/src/install-root/lib", "-delete_rpath",
"/Users/hohndel/Qt/6.3.0/macos/lib",
"-add_rpath", "@loader_path/../Frameworks")
ERROR: "error:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
\"-delete_rpath /Users/hohndel/src/install-root/lib\" specified more than
once\nUsage:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool
[-change old new] ... [-rpath old new] ... [-add_rpath new] ... [-delete_rpath
old] ... [-id name] input\n"
ERROR: ""
Log: Using install_name_tool:
Log: change rpaths in "Subsurface.app/Contents/Frameworks/libzip.5.dylib"
Log: using QList("-delete_rpath", "/Users/hohndel/src/install-root/lib",
"-delete_rpath", "/Users/hohndel/src/install-root/lib", "-add_rpath",
"@loader_path/.")
ERROR: "error:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
\"-delete_rpath /Users/hohndel/src/install-root/lib\" specified more than
once\nUsage:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool
[-change old new] ... [-rpath old new] ... [-add_rpath new] ... [-delete_rpath
old] ... [-id name] input\n"
ERROR: ""
Log: Using install_name_tool:
Log: change rpaths in "Subsurface.app/Contents/MacOS/Subsurface"
Log: using QList("-delete_rpath", "/Users/hohndel/src/install-root/lib",
"-delete_rpath", "/Users/hohndel/Qt/6.3.0/macos/lib", "-delete_rpath",
"/Users/hohndel/src/install-root/lib", "-delete_rpath",
"/Users/hohndel/Qt/6.3.0/macos/lib", "-add_rpath", "@loader_path/../Frameworks")
ERROR: "error:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool:
\"-delete_rpath /Users/hohndel/src/install-root/lib\" specified more than
once\nUsage:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/install_name_tool
[-change old new] ... [-rpath old new] ... [-add_rpath new] ... [-delete_rpath
old] ... [-id name] input\n"
ERROR: ""
this seems like a fairly obvious violation of the calling convention of
install_name_tool (from Xcode Version 13.3 (13E113) - which I believe is
current).
It seems to continue, though, and I can't find anything drastically wrong with
the dynamic libraries and the main app afterwards. The dependencies all look
right in otool.
But what puzzles me, is this:
% ./Subsurface.app/Contents/MacOS/Subsurface
QQuickWidget is only supported on OpenGL. Use QQuickWindow::setGraphicsApi() to
override the default.
qrc:/qml/statsview2.qml: module "QtQml.WorkerScript" is not installed
That first error is weird... I thought Qt on macOS was using OpenGL... is there
something that I need to do in the app to avoid that error (the app seems to
work fine, mind you).
And that second one is why I'm mainly writing this message... because
QtQml.WorkerScript is there. macdeployqt doesn't copy it (I'll need to figure
out how to write a bug report for that one), but I manually copy it in place:
% ls -l ./Subsurface.app/Contents/Frameworks/QtQmlWorkerScript.framework
total 0
lrwxrwxrwx 1 hohndel staff 24 Feb 11 12:35 Headers ->
Versions/Current/Headers
lrwxrwxrwx 1 hohndel staff 34 Feb 11 12:35 QtQmlWorkerScript ->
Versions/Current/QtQmlWorkerScript
lrwxrwxrwx 1 hohndel staff 26 Feb 11 12:35 Resources ->
Versions/Current/Resources
drwxr-xr-x 4 hohndel staff 128 Feb 11 12:35 Versions
Any idea what I may be doing wrong? This appears to work if I only build an
arm64 binary. But I get the error above for a fat binary. All the libraries and
plugins that I can find are indeed fat, e.g.:
% lipo -info
./Subsurface.app/Contents/Frameworks/QtQmlWorkerScript.framework/QtQmlWorkerScript
Architectures in the fat file:
./Subsurface.app/Contents/Frameworks/QtQmlWorkerScript.framework/QtQmlWorkerScript
are: x86_64 arm64
Any pointers welcome :)
/D
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
[Interest] copying the object in the delegate
Hi there, So this may be a strange question. I have a sorted filtered list in C++ that is accessed through a list model in QML. In the delegate I need to access many of the members of the object underlying the model. Through properties that should be fairly low overhead, if I could "cache" that object in QML. But what seems to happen is that every time I access one of the members of theobject in the delegate, the data function of the model is called with the correct index. For complicated but reasonably important reasons, this actually creates a new C++ object for return back to QML, one member of that object is accessed and then the object is destroyed. So, in order to access a 32bit integer member of my object and display this in my delegate, the model is called, a new object with 20+ distinct members is created from underlying data structures, only one 32bit integer is accessd, and the rest is immediately discarded. And that is done for each of the 20+ distinct members. And I suspect that this is done more than once because I count ~150 calls to the object constructor from the data() function of the model to display that delegate - a lot more than member references are in that code. That is of course ridiculously inefficient. Even ignoring the issue on my side that forces me to run the constructor every time the data() function is called, it seems silly to not just be able to have a local copy of that object for the delegate QML object which then accesses the members of that object without calling back to the underlying model. Is there a way to do that and I just didn't find it when looking? Thanks /D ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] how do I tell cmake that I need libQt5PositioningQuick.so
> On Jul 10, 2018, at 8:19 AM, Thiago Macieira > wrote: > > On Tuesday, 10 July 2018 08:00:37 PDT Dirk Hohndel wrote: >>> On Jul 10, 2018, at 7:23 AM, Thiago Macieira >>> wrote:> >>> On Monday, 9 July 2018 23:42:06 PDT Dirk Hohndel wrote: >>>> When upgrading to Qt 5.11 we ran into an odd problem when packaging our >>>> app... we seem to be missing a dependency for libQt5PositioningQuick.so >>>> (or >>>> QtPositioningQuick.framework on Mac). What's odd is that this worked >>>> perfectly fine with Qt 5.10 - so nothing from our side has changed. >>>> >>>> I'd love to hear if there's a magic incantation I could tell cmake to >>>> make >>>> sure that library is bundled. >>> >>> There should be no magic, not more than for any other module. The cmake >>> files are autogenerated for all Qt modules, so Qt5PositioningQuick is not >>> different from any other. >> >> Yet we have to manually copy/bundle that library on Mac, we still haven't >> figured out how to get it added on Windows or Android... >> I'm happy to show you a LOT more details :-) >> But what would help you understand what's going on? > > Well, start with the description of what happened that led you to the > conclusion that you needed this module. The only reference I see in the > Subsurface source code to QtPositionngQuick seems to be a workaround to this > particular issue. > > My wild guess: a new plugin that gets deployed by macdeployqt, which links to > this library, but isn't added by macdeployqt. What happens is that when Subsurface (or Subsurface-mobile) starts, loading the Map fails (that's QML in both desktop and mobile app). And when you look at the error messages, it's because a QML component isn't loaded because it needs this library. You can easily see this for yourself. Build from latest master on your Mac, try it. Everything works. Now revert the one commit that adds the workaround, remove Subsurface.app (so you don't get the already copied Framework) and build again. You'll see the failure to load the Map and the corresponding errors in the console output. I'm happy to provide those here, but I think you have a much better chance to figure out what's wrong if you get to play with it yourself :-) And building Subsurface on the Mac has become super easy lately. /D ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] how do I tell cmake that I need libQt5PositioningQuick.so
> On Jul 10, 2018, at 7:23 AM, Thiago Macieira > wrote: > > On Monday, 9 July 2018 23:42:06 PDT Dirk Hohndel wrote: >> When upgrading to Qt 5.11 we ran into an odd problem when packaging our >> app... we seem to be missing a dependency for libQt5PositioningQuick.so (or >> QtPositioningQuick.framework on Mac). What's odd is that this worked >> perfectly fine with Qt 5.10 - so nothing from our side has changed. >> >> I'd love to hear if there's a magic incantation I could tell cmake to make >> sure that library is bundled. > > There should be no magic, not more than for any other module. The cmake files > are autogenerated for all Qt modules, so Qt5PositioningQuick is not different > from any other. Yet we have to manually copy/bundle that library on Mac, we still haven't figured out how to get it added on Windows or Android... I'm happy to show you a LOT more details :-) But what would help you understand what's going on? /D ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] how do I tell cmake that I need libQt5PositioningQuick.so
When upgrading to Qt 5.11 we ran into an odd problem when packaging our app... we seem to be missing a dependency for libQt5PositioningQuick.so (or QtPositioningQuick.framework on Mac). What's odd is that this worked perfectly fine with Qt 5.10 - so nothing from our side has changed. I'd love to hear if there's a magic incantation I could tell cmake to make sure that library is bundled. Thanks /D PS: all this is for Subsurface and I'm happy to provide tons of details - but instead of drowning you in output, maybe this makes it easier for someone to spot what we need to do. Please let me know if you'd rather have the nitty gritty... ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] [Android-development] responding to an Android intent in a Qt app
Ekke,
This is awesome. I browsed through your posts and cloned the SHAREexample.
I think it will take me a moment to follow this and understand how to apply
this to my situation,
But this is by far the best explanation and best documented example that I've
found, so thanks
to your information I'm much more optimistic that I should be able to figure
this out.
I will post here if I get stuck, but yeah... definitely a huge help!
/D
> On Jun 28, 2018, at 9:57 PM, ekke wrote:
>
> Dirk,
>
> if your app was running this method will be called inside your Activity:
>
> public void onNewIntent(Intent intent)
>
> if your app wasn't running and started by the Intent, the App was started with
>
> public void onCreate(Bundle savedInstanceState)
>
> then you can see if there's an Intent causing the app start:
>
> // now we're checking if the App was started from another Android App via
> Intent
> Intent theIntent = getIntent();
> if (theIntent != null){
> String theAction = theIntent.getAction();
> if (theAction != null){
> Log.d("ekkescorner onCreate ", theAction);
> // QML UI not ready yet
> // delay processIntent();
> isIntentPending = true;
> }
> }
>
> Attention: if your app was started by the Intent, then at this point your UI
> isn't ready,
> so it's a good idea to set a bool isIntentPending
> and as soon as your App UI is ready you can ask if there was an Intent and
> process your logic
>
> to get the whole story, see this example app:
> https://github.com/ekke/ekkesSHAREexample
> <https://github.com/ekke/ekkesSHAREexample>
> and my blogs:
> http://blog.qt.io/blog/2017/12/01/sharing-files-android-ios-qt-app/
> <http://blog.qt.io/blog/2017/12/01/sharing-files-android-ios-qt-app/>
> http://blog.qt.io/blog/2018/01/16/sharing-files-android-ios-qt-app-part-2/
> <http://blog.qt.io/blog/2017/12/01/sharing-files-android-ios-qt-app/>
> http://blog.qt.io/blog/2018/02/06/sharing-files-android-ios-qt-app-part-3/
> <http://blog.qt.io/blog/2017/12/01/sharing-files-android-ios-qt-app/>
>
> hope you get the idea HowTo get the data from your Intent
> I haven't used
> action.USB_DEVICE_ATTACHED
> so cannot help with this in detail, but will add this usecase next weeks
>
> ekke
> Am 28.06.18 um 19:32 schrieb Dirk Hohndel:
>> Hi,
>> ...
>>
>> Here comes the question - inside the app, how do I know that I was
>> launched by that intent? And how do I get to the extra data that is
>> available through that intent?
>>
>>
>> Thanks
>>
>> /D
>
> ___
> Android-development mailing list
> android-developm...@qt-project.org <mailto:android-developm...@qt-project.org>
> http://lists.qt-project.org/mailman/listinfo/android-development
> <http://lists.qt-project.org/mailman/listinfo/android-development>
___
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
[Interest] responding to an Android intent in a Qt app
Hi, I'm pretty sure that I'm missing something fairly basic... Our Android Qt app registers its desire to be opened when a certain type of USB device is plugged into the Android phone / tablet: AndroidManifest.xml: ... ... The xml/device_filter.xml file is setup to list the devices that we want to respond to. Now if the user plugs in such a device, an Android system message pops up and asks if they want to launch our app. Awesome, exactly what I want. Here comes the question - inside the app, how do I know that I was launched by that intent? And how do I get to the extra data that is available through that intent? Andrid docs tell me (https://developer.android.com/guide/topics/connectivity/usb/host) that in Java all I need to do is: UsbDevice device = (UsbDevice) intent.getParcelableExtra(UsbManager.EXTRA_DEVICE); and now I can get the deviceName, PID and VID for that device... But how do I do this from a Qt app? I found the documentation here http://doc.qt.io/qt-5/qandroidintent.html but that still doesn't tell me how I know that I have received an intent and how to get the Java intent object. Because once I know that I think I should be able to get to that info via QAndroidIntent::extraVariant(const QString ) ... Does someone have a working example of how a Qt Android app can respond to a USB device being plugged in? Or any other pointers to working code? Thanks /D ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Compile problems with Qt 5.9.1 from git
> On Jul 2, 2017, at 3:55 AM, Allan Sandfeld Jensen <k...@carewolf.com> wrote: > > On Samstag, 1. Juli 2017 20:41:45 CEST Dirk Hohndel wrote: >>> On Jul 1, 2017, at 11:39 AM, Thiago Macieira <thi...@macieira.org> wrote: >>> >>> On sábado, 1 de julho de 2017 11:35:33 PDT Dirk Hohndel wrote: >>>> I still wish someone would just make binaries available that include >>>> QtWebKit and ran on reasonably old OS/hw combinations... >>> >>> Hey Dirk >>> >>> Can you try the 5.212 branch instead of the 5.9.1 released package? It >>> contains a much updated engine. >> >> 5.212 - that's an odd branch :-) >> Is that newer than 5.9.1? >> > Yes it is based on a 3 years newer branch of WebKit than the old deprecated > QtWebKit branch, the version number is because the version is comparative to > WebKitGTK 2.12, and because the version has been decoupled from Qt releases. > If we had had the new branch ready in time we never have made a 5.9 branch of > qtwebkit let alone 5.9.x source packages, but we got started to late and > 2.212 > only came about around the same time 5.9.0 was released That sounds great. Oddly, I also need some BLE fixes that went into 5.9.1 (that's the only reason I'm so eager to switch to 5.9.1 in the first place). But if those are in 5.212 as well, then I'll switch to that of course. Thanks! /D ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Compile problems with Qt 5.9.1 from git
> On Jul 1, 2017, at 11:39 AM, Thiago Macieira <thi...@macieira.org> wrote: > > On sábado, 1 de julho de 2017 11:35:33 PDT Dirk Hohndel wrote: >> I still wish someone would just make binaries available that include >> QtWebKit and ran on reasonably old OS/hw combinations... > > Hey Dirk > > Can you try the 5.212 branch instead of the 5.9.1 released package? It > contains a much updated engine. 5.212 - that's an odd branch :-) Is that newer than 5.9.1? And a much updated engine of 'what'? > I can create the tarball for you if it helps. I have all of the git trees. Can I just check out that branch? /D ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] Compile problems with Qt 5.9.1 from git
> On Jul 1, 2017, at 10:14 AM, Dirk Hohndel <d...@hohndel.org> wrote: > > I'm trying to build Qt from source (since my project relies on QtWebKit and > there are no pre-built binaries for that - which is a shame). > > As always, building from source is a remarkably painful, time intensive and > overall frustrating experience. > > In order to have the binaries that we ship run on a reasonably wide set of > hardware, this is the configure line that I use: > > ../qt5/configure \ > -release -opensource -confirm-license \ > -skip qt3d -nomake examples -nomake tests \ > --prefix=/Users/hohndel/Qt5.9.1 -sdk macosx10.10 -no-avx512 -no-avx2 \ Turns out that picking the sdk appears to be the cause for this problem. I blew away my build tree and tried again without that and while the build is still running it certainly made it past that point. I still wish someone would just make binaries available that include QtWebKit and ran on reasonably old OS/hw combinations... /D___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Compile problems with Qt 5.9.1 from git
I'm trying to build Qt from source (since my project relies on QtWebKit and there are no pre-built binaries for that - which is a shame). As always, building from source is a remarkably painful, time intensive and overall frustrating experience. In order to have the binaries that we ship run on a reasonably wide set of hardware, this is the configure line that I use: ../qt5/configure \ -release -opensource -confirm-license \ -skip qt3d -nomake examples -nomake tests \ --prefix=/Users/hohndel/Qt5.9.1 -sdk macosx10.10 -no-avx512 -no-avx2 \ 2>&1 | tee configure.log Running make afterwards doesn't get very far. It fails with this error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang++ -c -pipe -stdlib=libc++ -O2 -std=c++1z -fapplication-extension -arch x86_64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk -mmacosx-version-min=10.10 -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -Wall -W -fPIC -DQT_NO_NARROWING_CONVERSIONS_IN_CONNECT -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_PLUGIN -DQT_NETWORK_LIB -DQT_CORE_LIB -I/Users/hohndel/src/qt5/qtbase/src/plugins/bearer/corewlan -I. -I../../../../include/QtNetwork/5.9.1 -I../../../../include/QtNetwork/5.9.1/QtNetwork -I../../../../include/QtCore/5.9.1 -I../../../../include/QtCore/5.9.1/QtCore -I../../../../include -I../../../../include/QtNetwork -I../../../../include/QtCore -I.moc -I/Users/hohndel/src/qt5/qtbase/mkspecs/macx-clang -F/Users/hohndel/src/qt5.9.1-build/qtbase/lib -o .obj/qcorewlanengine.o /Users/hohndel/src/qt5/qtbase/src/plugins/bearer/corewlan/qcorewlanengine.mm /Users/hohndel/src/qt5/qtbase/src/plugins/bearer/corewlan/qcorewlanengine.mm:290:5: error: type arguments cannot be applied to non-parameterized class 'NSArray' NSArray *wifiInterfaces = [CWWiFiClient interfaceNames]; ^ /Users/hohndel/src/qt5/qtbase/src/plugins/bearer/corewlan/qcorewlanengine.mm:605:5: error: type arguments cannot be applied to non-parameterized class 'NSArray' NSArray *wifiInterfaces = [CWWiFiClient interfaceNames]; ^ 2 errors generated. Any ideas how to address this? Thanks /D___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Bluetooth LE support for Windows
Hi there, I thought I had read that this was being considered for 5.9, but I can't find that post anymore. Can anyone shed some light on the plans regarding Bluetooth LE? Thanks /D ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] Qt 5.6.0 on iOS - QGeoPositionInfoSource issues
Hi there, I run an interesting little project that provides an application across quite a few different OSs - with a Qt/QWidget UI for Windows, Mac, and various Linux flavors, and a QML UI (with currently significantly limited functionality) that can be built for Mac and Linux, but that is mainly targeted at Android and iOS. Our Android app has been in testing for a while and was recently released and QGeoPositioningInfoSource there seems to be doing what I expected it to do, but on iOS (our newest platform where we just started beta testing) I'm running into some problems: a) on iPads without GPS (so only WiFi location guestimation), supportedPositioningMethods() returns QGeoPositionInfoSource::AllPositioningMethods, therefore claiming that there are satellite based positioning methods available, even though there clearly aren't. b) regardless of the update interval given via setUpdateInterval() the application receives a nearly constant flow of positionUpdated() signals - usually more than once a second c) even though the Info.plist file contains NSLocationAlwaysUsageDescription Explanation why the position information service stops the moment the application is no longer running in the foreground (and resumes once the application is in the foreground again) Looking at the ObjectiveC APIs for position services on iOS neither of these three issues are platform limitation. iOS clearly tells an app whether a satellite based position service is available, iOS allows positionUpdates to be delayed both by time interval and (that's something I'd love to see in the Qt API) by geo-fencing, specifically distance from the last fix. And iOS allows applications to continue to receive position updates in the background and when the phone is asleep (that's the perfect of the Info.plist key mentioned under c). Any help addressing these issues would be extremely welcome! Thanks /D___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
