Going through the phantomJS code i ran into this in the webpage.cpp file (line 315)
connect(m_networkAccessManager, SIGNAL(resourceRequested(QVariant)),
SIGNAL(resourceRequested(QVariant)));
And i don't quite understand how this works, i'm aware that you can connect signals to signals in Qt.
On the Qt documentation i found out that you can also connect signals directly to a method (http://doc.qt.io/qt-5/qobject.html#connect-2) , seeing that it's a 3 parameters call i thought that this would be the desired function on the webpage.cpp code, but connecting a signal to the same signal...i got completely lost there, any help?
PD: not very experienced in Qt i should say, sorry if it's a dumb question
Three parameters QObject::connect()
connect(m_networkAccessManager, SIGNAL(resourceRequested(QVariant)),
SIGNAL(resourceRequested(QVariant)));
is an equivalent of
connect(m_networkAccessManager, SIGNAL(resourceRequested(QVariant)),
this, SIGNAL(resourceRequested(QVariant)));
Thus, QNetworkAccessManager::resourceRequested(QVariant) is connected to WebPage::resourceRequested(QVariant) and cause the latter to be emitted every time when the former is emitted.
More details in Qt documentation
Related
When the code HERE(Edit: Wrong code :) is used, the Serial monitor is spammed with this:
http://pastebin.com/nsD4CALFg
I cannot find any problems with the code, and it is a long one...
EDIT2: It now spams this http://pastebin.com/BXfFFBKHz
I know what was wrong(Sort of)... There was a bug with that specific program, because I copied the exact same program into an empty one and it worked :L...
In writing a Qt4 app, I clumsily wrote:
QObject::connect(spinbox, SIGNAL(vlaueChanged(int)), ....
and it compiled, and it ran, but of course the spinbox didn't have any effect.
Such misspellings should be caught. I always assumed that valueChanged() was declared in some header file, but apparently not. Any arbitrary garbage can be given to SIGNAL() or SLOT(), and it'll compile. My toy program is small. For a huge app with dynamically created controls connected on the fly, an error like this could be very hard to track down.
Is there some way to do error checking for this kind of typo? Is it possible for the compiler (gcc) to do this, or is some other tool appropriate?
This has been changed for Qt5. You can read about it here.
SIGNAL and SLOT macros turn their arguments into strings, and they are not checked in compile time (because... they are string actually). In case of wrong signal/slot name Qt writes warning (qWarn) in runtime. They say, in Qt5 something changed there.
In my experience, sometimes you really can do such a mistake (though rarely, autocompletion helps a lot), but it can be easily tracked down and fixed.
I am loading a web page from a file, then i replace some of the html in it:
self.template_web_page = QtWebKit.QWebPage()
self.template_web_page.mainFrame().load(QtCore.QUrl('template.html'))
def load(ok):
main_window.web_view.loadFinished.disconnect(load)
self.table_element = self.template_web_page.mainFrame().findFirstElement("#table")
self.table_element.setInnerXml(table_html)
main_window.web_view.loadFinished.connect(load)
Is there a way to connect to a signal just for one shot?
As already noted, there doesn't appear to be a better (more concise) way than this.
http://comments.gmane.org/gmane.comp.lib.qt.general/6883 suggests that such a solution is fine, although I have had issues with such a solution myself. I found that if I disconnected the slot at the start of the slot (as is done in the code in the question) and then tried to perform some GUI interactions (setting statusbar text was a problem, but not highlighting a row in a list view), I got an exception due to a NULL pointer dereference. This was with PyQt 4.6.2 for Python 2.6 for Windows. When I moved the disconnect() call to the end of the slot, the problem went away.
Apologies in advance if this is not relevant and it's just a stupid mistake I've made.
My scenario here is the following: I am using a pyqt widget to display a solid color fullscreen on a second display and observe this display with a camera that is continuously capturing images. I do some processing with the images and this is the data I am interested in. This works great when used interactively with ipython and matplotlib using the qt4agg backend like so
% ipython -pylab
# ... import PatternDisplay, starting camera
pd = PatternDisplay(); pd.show(); pd.showColor(r=255,g=255,b=255)
imshow(cam.current_image)
I need a similar behavior now in a console script though: it should display the PatternDisplay widget, capture an image, than change the color on the PatternDisplay and take a new image and so on.
The problem is now that the PatternDisplay is never updated/redrawn in my script, likely because PyQt never gets a chance to run it's event queue. I had no luck trying to move the linear worker part of my script into a QThread because I cannot communicate with the PatternDisplay Widget from another Thread any longer. I tried to replicate the implementation of ipython/matplotlib, but I didn't fully understand it, it is quite complicated - it avoids running the QApplication main loop via monkey patching and somehow moves QT into it's own thread. It then checks periodically using a QTimer if a new command was entered by the user.
Isn't there an easy way to achieve what I want to do? I am gladly providing more information if needed. Thanks for any help!
What you need is easier than IPython's job - IPython makes the Qt application and the command line interactive at the same time.
I think the way to do it in Qt is to use a timer which fires at regular intervals, and connect the signal to the 'slot' representing your function that gets the new image and puts it in the widget. So you're pulling it in from the event loop, rather than trying to push it.
I've not used Qt much, so I can't give specifics, but the more I think about it, the more I think that's the right way to do it.
I solved the same problem (i.e. interactive ipython console in terminal, and GUI thread running independently) in the following way with ipython 0.10 (code here)
1. Construct QApplication object, but don't enter its event loop explicitly
2. Run the embedded IPython instance
3. Run the UI code you need by instantiating your window and calling show() on it (like here with the yade.qt.Controller(), which I aliased to F12. (I did not find a way how to ask the embedded shell to run a command at the start of the session, as if the user had typed it)
(You can also show() your window first, then run the embedded ipython. It will provide event loop for Qt.)
(BTW I also tried running Qt4 from a background thread (using both python threads module, and Qt4.QThreads), but it refuses to run in such way stubbornly. Don't bother going that way.)
The disadvantage is that UI will be blocked while ipython is busy. I hope to finding something better for 0.11, which should have much better threading facilities (I asked on ipython-users about how to unblock the UI).
HTH, v.
I have my own application in QT.It has one main GUI thread which will handling the event from the inputs but i have created one thread that will applicable to change images every 10 seconds (just like slideshow or screen saver). but when i call function setPixmap from thread then it gives me warning that it's not safe to use Pixmap from thread.
what is the solution ?. why i don't use setPixmap from thread ?
Thanks,
Neel
The why, is because that function is not thread safe.
The solution, is to use a QTimer to run your function every 10 seconds. QTimer is integrated in the Qt Event Loop, so you don't need another thread to do it.
I don't have an actual answer to this but I know that setPixmap() should only be called from the main GUI thread. I found this mailing list post from a few years back that also points to trolltechs docs. Reading through the thing quickly leads me to think that it has something to do with how different platforms render stuff and so on.
http://lists.trolltech.com/qt-interest/2008-11/thread00534-0.html
http://doc.trolltech.com/4.4/threads.html#painting-in-threads
Instead of having your worker thread call setPixmap(), have it emit a signal (something like newImagesReady()).
Then, connect that signal to your widget's update() slot. (Or make your own slot if you want to do more than refresh the widget).
This technique lets you cross thread boundaries.