Qt-contributors-summit-2014-Qt-for-WinRT: Difference between revisions
Jump to navigation
Jump to search
No edit summary |
No edit summary |
||
Line 1: | Line 1: | ||
===Better collaboration with other ports=== | |||
* See coordination meta-task at https://bugreports.qt.io/browse/QTBUG-36015 | |||
* A cross-platform native webview <span class="caps">API</span> may be created in the future; WinRT should be able to provide the <span class="caps">API</span> as well. | |||
* <span class="caps">QPA</span> callbacks for Android intents may be needed – WinRT has various launching techniques as well, and includes an <span class="caps">IPC</span> mechanism for transferring data from one app to another. We should agree on some kind of <span class="caps">API</span> for this. | |||
* Text composition <span class="caps">API</span>s 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. | |||
===<span class="caps">XAML</span> integration=== | |||
* By rendering Qt into a <span class="caps">XAML</span> layer, we can integrate with the native controls which exist on <span class="caps">XAML</span> 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 <span class="caps">XAML</span> video playback for the high-level controls | |||
===Client-side composition=== | |||
* We should investigate reusing the <span class="caps">EGLFS</span> 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. | |||
===<span class="caps">SSL</span>/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 <span class="caps">PIMPL</span>s for WinRT. | |||
===Code sharing with desktop Windows 8=== | |||
* Most of the WinRT <span class="caps">API</span> 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 <span class="caps">QRC</span> | |||
* Another option is to use a framework bundle of the entire qt source tree, and depend on that (Android may use the same approach) |
Revision as of 14:11, 25 February 2015
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)