0

Overview:

I am trying to create a PoC application that mimics WebIntents-like feature. So, in my Qt application, I create two QWebviews launching two different webApps. Now let's call them apps A and B.

Scenario:

  • Main Application creates two QWebViews each launching an App i.e. AppA, AppB.
  • App A is programmed to fetch some data via AJAX, automatically.
  • App B also needs part of that data. AppB simply displays a button (HTML) called . Note: Since, AppA already has that info, I would like the AppB to invoke a JavaScript API which was injected into it's(appB) DOM by means of addToJavaScriptWindowObject() method call when the QWebView was launched.
  • App-A completed the Ajax Call and indicates the completion in its WebView.
  • User clicks the button in AppB,
  • App B invokes that JavaScript API i.e. fetcData({source: "AppA");
  • Now the control is in the QT-world:

Question: the Control is in the context of AppB, How should I communicate with the WebView in AppA -- i.e. AppB asks AppA: hey AppA, please give me that data that you have fetched?

Can Signals and Slots help me here? Or should I use some other form of IPC.

I read this page: http://qt-project.org/doc/qt-4.8/qtwebkit-bridge.html, but I still didn't get a hint for a solution for my problem.

Another related question: Are QWebViews created in their own threads ?

Karthik
  • 1,006
  • 3
  • 10
  • 19

1 Answers1

0

Can't you just emit some sort of signal from AppB that basically says, "Hey, I finished fetching my data if anyone wants it" or am I missing something? It would happen at the end of AppB::fetchData().

All you have to do after that is connect any interested objects to that signal.

Phlucious
  • 3,704
  • 28
  • 61
  • Sorry, there was a typo in my question, i just fixed that. – Karthik Apr 18 '13 at 20:07
  • The AppB doesn't need such a signal just yet. Since it is a Proof-Of-Concept. I didn't make the AppA to emit the "data-ready" "finished-fetching" type signals. So the user (i.e. me) would click a button on the AppB to fetch data through the QT. This would be done upon seeing that the QWebView of AppA is populated with the fetched data. – Karthik Apr 18 '13 at 20:13
  • So in this scenario, the AppB needs to get the handle of WebView of AppA and call a method AppB::fetchData(in QT-CPP). This method in turn needs to call the JavaScript code of AppB's QWebView which has the data! I am not totally sure how to to accomplish this. – Karthik Apr 18 '13 at 20:17
  • Since control is back in the MainWindow, you could simple pass the address of AppA to `AppB::fetchData(MyWebView* app_ptr)`, then use `app_ptr` to access any members of AppA that you need. – Phlucious Apr 18 '13 at 20:34
  • If you did connect a `dataFetched()` signal from AppA to a slot in AppB, you can accomplish the same thing in AppB's slot using QObject::sender(); – Phlucious Apr 18 '13 at 20:36
  • Thanks. I still have one lingering question in the back of the mind: In the above example, are both QWebViews created in the same thread-context? Are the QWebviews simple UI-widgets without any execution context of it's own? I am guessing the answers for both of the questions are "Yes". I saw this similar post (http://qt-project.org/forums/viewthread/14426) seem to indicate the QWebview would always be on the main-UI thread. Could you please comment? Thanks in Advance! – Karthik Apr 20 '13 at 14:28
  • QWebView, [like all UI elements](http://stackoverflow.com/questions/2086142/qt-signaling-across-threads-one-is-gui-thread), runs on the main thread. You can bypass this by realizing that QWebPage is a QObject that can be [moved to another thread](http://qt-project.org/doc/qt-4.8/qobject.html#moveToThread) if needed. – Phlucious Apr 22 '13 at 15:28