Hi, I'm very happy to contribute to Qt ! (I've been using it since 2003, so it's about time ;)
The latest version I tested with is r8 (I decided not to upgrade to r8b after reading some people complain of builds not working anymore :)... so I can't help you with the r8b issues at the moment, I will try to find some time to look into it... About the orientation change, yes, it will completely recreate the ui (including the QGuiApplication), it basically just restarts the the app (the native activity framework causes this). I am aware it does not work in the case of QQuickView ( a workaround is to fix the screen orientation in the manifest, like I did with the calqlatr example ), I think the problem is that the windowmanager class (QQuickSimpleWindowManager or something I need to look up the exact name) for QQuickView uses a local static instance variable and this does not get properly reinitialized after the orientation change (because the static initialization is skipped). Note that this problem extends to *every* static variable in Qt that is only initialized during static initalization (in the android_main function I added a call to reset theMainThread pointer for example). Android more or less fits the last model, I believe in a Java activity it just reports the orientation change via a callback, but for some reason in the Native Activity, it reports this by "resetting" the app with different configuration settings (I'm not exactly sure why they do this). This is not necessarily a problem as one gets the chance to save the state before the app finishes and this state can/should be restored when the app restarts. I added some state management functions (but I must admit I haven't tested them yet, I added them just before I sent the patch to you ;)). The state management is the one thing that I am not sure about how to integrate it transparently into Qt as it seems to be unique to Android. The state should be built at specific moments and the user should be allowed to put any data in the state. QSettings might be a candidate together with some signals that request a state to be built and restored? (for regular systems the build signal would probably only fire on an application quit and for android at every APP_CMD_SAVE_STATE command - see the event handler) Also note that on android destroy() and create() calls should really do their job well: switching an app to the background abandons its native window and EGL context, so platform resources *must* be properly cleaned up and recreated, QQuickView seems to do a pretty good job, QGLView doesn't (hence the patch). Walter PS: Yesterday I noticed that my QGLView patch may sometimes cause a segfault on application destruction on OSX (probably a pointer that does not get properly set to 0). On 11 Nov 2012, at 02:21, Shawn Rutledge wrote: > I was able to do the build using NDK r8b, but I ran into the following NDK > bugs along the way: > > http://code.google.com/p/android/issues/detail?id=35616 (applied both > workarounds) > https://android-review.googlesource.com/#/c/41833/ > https://android-review.googlesource.com/#/c/41613/ > > I didn't find a good solution to the fenv issue yet, but worked around it by > commenting out some stuff in src/corelib/tools/qlocale_tools.cpp. The > examples work. > > In the PDF you wrote > > Screen Orientation Change: The activity will call onDestroy and onCreate, > without unloading shared libraries or going through static initialization! > > so does that mean it's actually going to destroy and re-create the UI? It > doesn't seem to work in the qquickview_example; I just get a black screen if > I change orientation from whichever orientation it was when I started the > app. So far I've been thinking on platforms on which it's possible to rotate > the whole windowing environment (e.g. desktops), an application will not > necessarily need to care, but can detect changes in QScreen properties; > whereas on platforms which do not auto-rotate everything, a Qt Quick app will > need to rotate its own content (by binding to the relevant QScreen > properties, probably just primaryOrientation). Does Android not fit either > of those models? > > Anyway, this looks like a good starting point to me. So thanks for the > contribution! >
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
