| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
mmfphonon
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The debug{} directive in src/plugins/phonon/mmf/plugin/plugin.pro does not have
any effect - this can be seen by looking at the generated MMP file, which has a
STATICLIBRARY directive which is applied in both UDEB and UREL builds. This is
the general problem that .pro files cannot tell distinction between the
different targets that one makespec covers.
Also remove objectdumpstub; objectdump was originally prepared for QtGui
inclusion, but since that never happened, no other platforms than Symbian needs
to be covered.
Task-number: QTBUG-5466
Reviewed-by: Gareth Stockwell
|
|/
|
|
| |
Reviewed-by: trustme
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This statement calls a function (RWindowBase::ClientHandle) which was
introduced in S60 3.2. Although there is a runtime check, a build
made against 3.2 or above will fail on a 3.1 device. This manifests
itself by the plugin failing to load.
The log statement is not really necessary anyway, because, for
window-owning controls, the window handle is the same value as the
CCoeControl* pointer. This means that logging
RWindowBase::ClientHandle is redundant information.
Task-number: QTBUG-5406
Reviewed-by: trustme
|
|\ |
|
| |
| |
| |
| | |
Reviewed-by: Oswald Buddenhagen
|
| |
| |
| |
| |
| | |
Task-number: QTBUG-4662
Reviewed-by: Frans Englich
|
| |
| |
| |
| | |
Reviewed-by: trustme
|
| |
| |
| |
| |
| | |
Task-number: QTBUG-5302
Reviewed-by: trustme
|
| |
| |
| |
| |
| | |
Task-number: QTBUG-4777
Reviewed-by: trustme
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes a bug introduced by 58efa8aa, which meant that, when a new
clip was opened:
1. Playback did not start automatically
2. The current volume setting in the app UI was not applied to the
MMF client API
Task-number: QTBUG-4999
Reviewed-by: trustme
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Errors reported via:
* the DummyPlayer didn't work due to it not doing the usual state
transitions/emission
* MediaObject::setSource() due to errors being emitted
before connections being set up.
* A general state bug.
Task-number: QTBUG-4752
Reviewed-by: Gareth Stockwell
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
being moved.
Because QWidget::moveEvent is only called when a widget moves relative
to its parent, a widget's absolute screen position may change without it
receiving a moveEvent (for example, as a result of its parent being
moved).
The MMF video playback API on Symbian v9.4 requires, in addition to a
window handle, an absolute screen rectangle. Changes in the video
widget's absolute screen position therefore need to be propagated
into the MMF.
This change introduces a new object, AncestorMoveMonitor, which
installs an event filter on the QCoreApplication instance. A
VideoOutput object registers with the AncestorMoveMonitor, which
listens on its behalf for MoveEvents and ParentChangeEvents directed
at any of the ancestors of the VideoOutput. MoveEvents trigger a
callback to the VideoOutput instance, which then notifies the MMF of
the new screen rectangle. ParentChangeEvents cause the
AncestorMoveMonitor to update the ancestor list associated with the
target VideoOutput instance.
The video position now tracks that of the associated widget, but there
are two problems which require further investigation:
1. The video window lags behind. This may be an unavoidable
consequence of the fact that setting a new screen rectangle causes the
MMF to tear down its DSA session and start a new one; this is known to
block the window server and take some time to complete.
2. Artifacts are visible around the edges of the moving video widget.
Task-number: QTBUG-4787
Reviewed-by: Frans Englich
|
|
|
|
| |
Reviewed-by: Gareth Stockwell
|
|
|
|
|
|
|
| |
Tested on Symbian and Windows(DS9).
Task-number: QTBUG-4869
Reviewed-by: Gareth Stockwell
|
|
|
|
| |
Reviewed-by: TrustMe
|
|
|
|
|
| |
sed -i -e 's/\t/ /g' `find -name "*.cpp" -or -name "*.h" -or -name
"*.pro"`
|
|
|
|
| |
"*.pro"`
|
|
|
|
| |
"*.pro"`
|
| |
|
| |
|
|
|
|
|
| |
Task-number: QTBUG-4664
Reviewed-by: Frans Englich
|
|
|
|
| |
Reviewed-by: Frans Englich
|
|
|
|
|
|
| |
Moved common code into videoOutputRegionChanged()
Reviewed-by: Frans Englich
|
|
|
|
|
|
| |
This prevents a crash when applied to controls which are non-window owning
Reviewed-by: Frans Englich
|
|
|
|
| |
Reviewed-by: Frans Englich
|
|
|
|
| |
Reviewed-by: Frans Englich
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
getNativeWindowSystemHandles now checks the window handle and screen
rectangle against the previous value; SetDisplayWindowL is only called
if the window and/or screen rectangle have changed. This allows
videoOutputRegionChanged to be called 'speculatively' - i.e. in response
to Qt events which may or may not reflect a change in the underlying
window system - with only actual window system events getting propagated
into the MMF.
The reason for this change is that SetDisplayWindowL results in the
current DSA session (owned by CVideoPlayerUtility) being torn down and
a new one set up. This in turn requires handshaking with the window
server, and may be slow.
Reviewed-by: Frans Englich
|
|
|
|
|
|
|
|
|
|
|
| |
Now retrieve RWsSession and CScreenDevice from CCoeEnv::Static() once
(at construction), instead of at every call to
getNativeWindowSystemHandles().
Collapsed m_screenRect and m_clipRect into a single m_rect member,
since the two rectangles are always identical anyway.
Reviewed-by: Frans Englich
|
|
|
|
| |
Reviewed-by: Gareth Stockwell
|
|
|
|
|
|
|
| |
The MediaPlayer requires that an output device is available.
Task-number: QTBUG-4755
Reviewed-by: Gareth Stockwell
|
|
|
|
|
|
| |
The constructor initializer relied on member variables.
Task-number: QTBUG-4689
|
| |
|
|\
| |
| |
| |
| | |
Conflicts:
src/gui/kernel/qwidget_s60.cpp
|
| | |
|
| | |
|
|\ \
| | |
| | |
| | | |
mmfphonon
|
| |/
| |
| |
| | |
Fixes tst_MediaObject::testReconnectBetweenTwoMediaObjects().
|
| |\ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
Replace them by calls to QCoreApplication::translate() to
provide translators with context information.
Reviewed-by: Frans Englich <frans.englich@nokia.com>
|
|/ /
| |
| |
| | |
This is part of an attempt to get the draggablevideo test app working on Symbian. Use of the dummy video output object causes a top-level window to be created, which was suspected of being the reason why video is not visible. This is not the case - for some reason, when the VideoOutput window is activated, it is still marked as 'hidden' by the window server (CWsClientWindow::ResetHiddenFlag, triggered from CCoeControl::ActivateL).
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
mmfphonon
Conflicts:
src/3rdparty/phonon/mmf/abstractplayer.cpp
|
| | | |
|
| | |
| | |
| | |
| | | |
Volume changes made before playback starts are now correctly propagated.
|
| |/ |
|
|/
|
|
|
|
|
|
|
|
|
| |
This brings tst_MediaObject to 15/7, from previously not running. Changes
involves:
* Skipping .qrc related tests
* Loading/mimetype detction from file:/ URIs
* State fixes
* As part of previous point, move state and error handling down in
AbstractPlayer.
|
|
|
|
|
|
|
|
| |
Phonon.
Both epoc32/include and $QTDIR/include/Phonon contain a file called videoplayer.h. Both of these directories are listed as SYSTEMINCLUDE paths in the generated MMP file, with the Phonon path coming first. This means that '#include <videoplayer.h>' picks up the Phonon header rather than (as intended) the Symbian one.
A new qmake variable, PREPEND_INCLUDEPATH, is defined, allowing the .pro file to specify that /epoc32/include should be the first SYSTEMINCLUDE.
|
|
|
|
| |
This reverts commit 1062bbbcd6c30844d9ade10de80f27a3afd4dacf.
|
| |
|