tags:

views:

19

answers:

1

The following code works (and it's very simple):

class Scrape(QApplication):
  def __init__(self):
    super(Scrape, self).__init__(None)
    self.webView = QWebView()
    self.webView.loadFinished.connect(self.loadFinished)
  def load(self, url):
    self.webView.load(QUrl(url))
  def loadFinished(self):
    documentElement = self.webView.page().currentFrame().documentElement()

myScrape = Scrape()
myScrape.load('http://google.com/ncr')
myScrape.exec_()

but I do not really understand why the exec_() needs to be the last call and if it needs to be then what that load() really does...? How would any of this would work if I would need to load, say, two web pages?

+2  A: 

The exec_ call starts the event loop. This is where keyboard and mouse events, timer events, as well as async slot calls are dispatched.

The load method does what you expect: sets the Url in the view. This doesn't need events to be processed for it to work. But if you don't finish with exec_, there will be nothing to deal with events, or to prevent the program from just finishing up and exiting.

The exec_ method, as the term 'event loop' indicates, loops until the application quits. Functions called after that won't be called until the event loop exits.

If you want to 'do things' in your program, normally you would work within the event-driven framework. To load pages, you might hook up a button that will fire an event, which is connected to a function that loads a different page. Or, you might set up a timer that calls a function that sets the Url from a list.

An example of connecting signals and slots (from here):

# Define a new signal called 'trigger' that has no arguments.
trigger = QtCore.pyqtSignal()

def connect_and_emit_trigger(self):
    # Connect the trigger signal to a slot.
    self.trigger.connect(self.handle_trigger)

    # Emit the signal.
    self.trigger.emit()

def handle_trigger(self):
    # Show that the slot has been called.

    print "trigger signal received"
sje397
Does exec_() fire a signal then...? Or the above is the correct where you do something before exec_() and work with the signals emitted as a consequence?
chx
Yes, the latter. There isn't any 'app started' signal that I'm aware of, although if you fire a signal in an __init__ method, it should be queued up and handled by the event loop when it is started. Look up 'QEventLoop' and 'QCoreApplication::processEvents'
sje397