Bug 38304 - [Qt] Reinstate qt_drt_ symbol exports as of QtWebKit 4.6 release
Summary: [Qt] Reinstate qt_drt_ symbol exports as of QtWebKit 4.6 release
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Qt (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC All
: P2 Normal
Assignee: Nobody
URL:
Keywords: Qt
Depends on:
Blocks:
 
Reported: 2010-04-28 18:40 PDT by Laszlo Gombos
Modified: 2010-04-29 11:26 PDT (History)
3 users (show)

See Also:


Attachments
proposed patch (4.48 KB, patch)
2010-04-28 18:48 PDT, Laszlo Gombos
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Laszlo Gombos 2010-04-28 18:40:06 PDT
It would be a small effort (and small overhead) and potentially a big win to maintain some of the previously exported qt_drt_ symbols after r57433 for some time until all QtWebKit clients transition to the API changes. 

There is no backward compatibility grantee on the qt_drt interfaces, but some of these interfaces are only not exported because a "clean" Qt-style interface has not been commonly agreed (and not because they are not useful). 

This is a stop gap solution until a proper QtWebKit API is commonly agreed for some of this functionality.
Comment 1 Laszlo Gombos 2010-04-28 18:48:20 PDT
Created attachment 54660 [details]
proposed patch
Comment 2 Kenneth Rohde Christiansen 2010-04-28 20:10:08 PDT
Comment on attachment 54660 [details]
proposed patch

> void QWEBKIT_EXPORT qt_drt_run(bool b)

I'm pretty sure this one is not used by anyone outside the DRT, does it really make sense to reintroduce it?


WebKit/qt/WebCoreSupport/DumpRenderTreeSupportQt.cpp:431
 +  bool QWEBKIT_EXPORT qt_drt_pauseAnimation(QWebFrame *qframe, const QString &animationName, double time, const QString &elementId)
Wrong coding style, please fix before landing. Also, just use frame, not need to call it qFrame/qframe.

I think it makes sense to order the DRT methods together and the QWebPage ones as well; right now they are mixed.
Comment 3 Simon Hausmann 2010-04-28 22:06:38 PDT
I'm fine with reinstating the qt_* functions that were accidentially removed, but why should we reinstate the qt_drt_* ones? As the DRT suffix suggests they are only meant for the DRT implementation, which doesn't need them.

Are you using the qt_drt_* functions in applications?
Comment 4 Kenneth Rohde Christiansen 2010-04-29 05:07:30 PDT
Judging from the email to the list, they indeed are.
Comment 5 Laszlo Gombos 2010-04-29 10:30:03 PDT
Bug 31875 would be a good example of a functionality that should be a public API but the only way this is exposed today is trough DRT methods.
Comment 6 Laszlo Gombos 2010-04-29 11:26:17 PDT
Landed as http://trac.webkit.org/changeset/58527 with the changes suggested by Kenneth.

I kept qt_drt_run for now - we would need to mark the symbol ABSENT in the def file for Symbian if we remove it. 

It also potentially allows using the same DRT binary for a few different WebKit versions to check for differences between releases, but I'm not sure if this is a compelling enough case.