Qt-contributors-summit-2014-Qt-for-WinRT
Jump to navigation
Jump to search
Better collaboration with other ports
- See coordination meta-task at https://bugreports.qt.io/browse/QTBUG-36015
- A cross-platform native webview API may be created in the future; WinRT should be able to provide the API as well.
- QPA callbacks for Android intents may be needed – WinRT has various launching techniques as well, and includes an IPC mechanism for transferring data from one app to another. We should agree on some kind of API for this.
- Text composition APIs may need to be improved to support Android/iOS/WinRT in a similar manner
- Text context callbacks may also be needed, which e.g. change the Enter key on the virtual keyboard depending on what the action is.
XAML integration
- By rendering Qt into a XAML layer, we can integrate with the native controls which exist on XAML layers. This may be useful for a native webview as well as various platform controls such as the command bar. A proof-of-concept is available at https://codereview.qt.io/86264
Multimedia
- Camera, Video, Audio, Radio are all possible to support
- Video texture handles are easily accessible, but we might also be able to use XAML video playback for the high-level controls
Client-side composition
- We should investigate reusing the EGLFS compositor to improve the raster window situation
Qt Quick Controls
- Some native styling has been started for 5.4 – should be relatively simple due to the simplistic style of WinRT/WinPhone
- Native dialogs and simulated native popups should be written though
Qt Creator
- We should contribute to a cross-platform manifest editor (see http://qt.io/groups/qt-contributors-summit-2014/wiki/QtCS14CrossPlatformManifestXmlInfoPlist)
- Implementing a debugging for msvsmon would be hard but possible through some observation of the communication between VS and msvsmon. This would allow Creator to debug Windows (including WinRT/WinPhone) apps from any environment.
Shader precompilation
- We could cache/precompile shaders using the scene graph adaptation like Jolla already does. Someone should investigate this.
SSL/networking
- We should follow the lead of the new iOS backend (https://qt.gitorious.org/qt/sharkys-qtbase/source/7745df2a61447acf7e7debc0786ef80a1ff7bb29:src/network/ssl) and create PIMPLs for WinRT.
Code sharing with desktop Windows 8
- Most of the WinRT API runs on desktop
- No urgent places to do this, apart from possibly sensors (https://bugreports.qt.io/browse/QTBUG-39590)
Solving the test data problem
- Testlib data is usually not in the application package
- One option is to use QRC
- Another option is to use a framework bundle of the entire qt source tree, and depend on that (Android may use the same approach)