Phonon MMF: Implement video window repositioning

Device: Nokia 5800
Firmware version: 40.0.001
Release: 5695b50d
Platform: armv5 udeb
Compiler used: RVCT 2.2 build 686
Application: draggablevideo
Launched from: application launcher

The current video widget implementation in the Phonon MMF backend does not propagate changes of video screen region into the MMF client utility, unless the change causes a moveEvent to be sent to the VideoOutput widget itself. If a moveEvent does occur, the backend calls CVideoPlayerUtility::SetDisplayWindowL, which re-positions the video playback. If, on the other hand, the video window moves as a result of one of the VideoOutput's ancestors being moved, SetDisplayWindowL is not called. The resulting behaviour is that the video is not moved, but is just clipped to the new window rectangle.

This behaviour can be observed by running the 'draggablevideo' test app which is available from the (internal) projects/research/repos/mmfphonon repo. To load a video, double-click on one of the widgets. To move it, click and drag in the middle of the widget. Clicking and dragging in any corner causes the widget to resize.

Possible solutions to this problem include:

1. Propagate move events from ancestor widgets down to the video output widget
This could be done by installing an event filter on the application widget.

2. Listen for 'window moved' events from the window server
In principle this is the preferred option, but conversations with the Symbian graphics team suggest that no such event is available. The rationale for this is that only the owner of the window - i.e. the Qt GUI thread - can cause it to move in the first place, so there is not need to provide a notification back to that client thread.

3. Use DSA
The VideoOutput object could create a CDirectScreenAccess object, via which it would receive an abort when the display region changes - which will occur when the video window moves outside the original screen rectangle. The problem with this approach is that the client thread already owns a CDirectScreenAccess object (inside the CVideoPlayerUtility), and creating another one could lead to complicated race conditions when Abort callbacks occur.