|
|
| 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)
| |