I wrote a simple class for notifying user using tray balloon message. Here is the code:
# -*- coding: utf8 -*-
import sys
import time
from PyQt4 import QtGui
class TrayInformer():
def __init__(self, icon_file):
self.app = QtGui.QApplication(sys.argv)
self.app.setQuitOnLastWindowClosed(False)
self.tray_icon = QtGui.QSystemTrayIcon(
QtGui.QIcon(icon_file)
)
def notify(self, title, message, wait_time=1000):
self.tray_icon.show()
self.tray_icon.showMessage(title, message)
time.sleep(wait_time / 1000)
self.tray_icon.hide()
inf = TrayInformer('timeico.ico')
inf.notify('Error', 'Connection refused', 5000)
inf.notify('test', 'test', 500)
After running it I sometimes get: Process finished with exit code -1073741819 (0xC0000005). What could be the problem?
Try to instantiate QSystemTrayIcon with parent specified. I've had resembling random crashes on exit, and surprisingly tray icon appeared to cause the problem
<...> the problem is probably the random order in which C++
instances get destroyed. Explicitly del'ing a object, or giving it an appropriate parent is the best way to deal with it.
QSystemTrayIcon still crashed app (PyQt4 4.9.1)
Related
I have a GUI in PyQt with a function addImage(image_path). Easy to imagine, it is called when a new image should be added into a QListWidget. For the detection of new images in a folder, I use a threading.Thread with watchdog to detect file changes in the folder, and this thread then calls addImage directly.
This yields the warning that QPixmap shouldn't be called outside the gui thread, for reasons of thread safety.
What is the best and most simple way to make this threadsafe? QThread? Signal / Slot? QMetaObject.invokeMethod? I only need to pass a string from the thread to addImage.
You should use the built in QThread provided by Qt. You can place your file monitoring code inside a worker class that inherits from QObject so that it can use the Qt Signal/Slot system to pass messages between threads.
class FileMonitor(QObject):
image_signal = QtCore.pyqtSignal(str)
#QtCore.pyqtSlot()
def monitor_images(self):
# I'm guessing this is an infinite while loop that monitors files
while True:
if file_has_changed:
self.image_signal.emit('/path/to/image/file.jpg')
class MyWidget(QtGui.QWidget):
def __init__(self, ...)
...
self.file_monitor = FileMonitor()
self.thread = QtCore.QThread(self)
self.file_monitor.image_signal.connect(self.image_callback)
self.file_monitor.moveToThread(self.thread)
self.thread.started.connect(self.file_monitor.monitor_images)
self.thread.start()
#QtCore.pyqtSlot(str)
def image_callback(self, filepath):
pixmap = QtGui.QPixmap(filepath)
...
I believe the best approach is using the signal/slot mechanism. Here is an example. (Note: see the EDIT below that points out a possible weakness in my approach).
from PyQt4 import QtGui
from PyQt4 import QtCore
# Create the class 'Communicate'. The instance
# from this class shall be used later on for the
# signal/slot mechanism.
class Communicate(QtCore.QObject):
myGUI_signal = QtCore.pyqtSignal(str)
''' End class '''
# Define the function 'myThread'. This function is the so-called
# 'target function' when you create and start your new Thread.
# In other words, this is the function that will run in your new thread.
# 'myThread' expects one argument: the callback function name. That should
# be a function inside your GUI.
def myThread(callbackFunc):
# Setup the signal-slot mechanism.
mySrc = Communicate()
mySrc.myGUI_signal.connect(callbackFunc)
# Endless loop. You typically want the thread
# to run forever.
while(True):
# Do something useful here.
msgForGui = 'This is a message to send to the GUI'
mySrc.myGUI_signal.emit(msgForGui)
# So now the 'callbackFunc' is called, and is fed with 'msgForGui'
# as parameter. That is what you want. You just sent a message to
# your GUI application! - Note: I suppose here that 'callbackFunc'
# is one of the functions in your GUI.
# This procedure is thread safe.
''' End while '''
''' End myThread '''
In your GUI application code, you should create the new Thread, give it the right callback function, and make it run.
from PyQt4 import QtGui
from PyQt4 import QtCore
import sys
import os
# This is the main window from my GUI
class CustomMainWindow(QtGui.QMainWindow):
def __init__(self):
super(CustomMainWindow, self).__init__()
self.setGeometry(300, 300, 2500, 1500)
self.setWindowTitle("my first window")
# ...
self.startTheThread()
''''''
def theCallbackFunc(self, msg):
print('the thread has sent this message to the GUI:')
print(msg)
print('---------')
''''''
def startTheThread(self):
# Create the new thread. The target function is 'myThread'. The
# function we created in the beginning.
t = threading.Thread(name = 'myThread', target = myThread, args = (self.theCallbackFunc))
t.start()
''''''
''' End CustomMainWindow '''
# This is the startup code.
if __name__== '__main__':
app = QtGui.QApplication(sys.argv)
QtGui.QApplication.setStyle(QtGui.QStyleFactory.create('Plastique'))
myGUI = CustomMainWindow()
sys.exit(app.exec_())
''' End Main '''
EDIT
Mr. three_pineapples and Mr. Brendan Abel pointed out a weakness in my approach. Indeed, the approach works fine for this particular case, because you generate / emit the signal directly. When you deal with built-in Qt signals on buttons and widgets, you should take another approach (as specified in the answer of Mr. Brendan Abel).
Mr. three_pineapples adviced me to start a new topic in StackOverflow to make a comparison between the several approaches of thread-safe communication with a GUI. I will dig into the matter, and do that tomorrow :-)
I'm getting a message box: "Python has stopped working" when I load an image into a QLabel in a window that is already visible. Selecting debug shows: an unhandled Win32 exception occurred in Python.exe.
If I load the image into the label before showing the window, it displays correctly.
Here's the stripped down code:
#!/usr/bin/etc python
import sys
import os
import stat
from PyQt5.QtCore import *
from PyQt5.QtGui import *
from PyQt5.QtWidgets import *
from PIL import *
from PIL.ImageQt import *
def update(label):
filename = r"C:\Users\me\Pictures\images\00000229.jpg"
im1 = Image.open(filename)
print ("Read ({},{})".format(im1.width, im1.height))
im2 = im1.rotate(90, expand=True)
print("Rotate ({},{})".format(im2.width, im2.height))
im2.thumbnail((1200,1200))
print("Thumbnail({},{})".format(im2.width, im2.height))
qimage = ImageQt(im2)
pixmap = QPixmap.fromImage(qimage)
label.setPixmap(pixmap)
app = QApplication(sys.argv)
desktop = QDesktopWidget()
deskGeometry = desktop.availableGeometry()
print("desktop ({},{})".format(deskGeometry.width(), deskGeometry.height()))
window = QFrame()
# If you let QT pick the sizes itself, it picks dumb ones, then complains
# 'cause they are dumb
window.setMinimumSize(300, 200)
window.setMaximumSize(deskGeometry.width(), deskGeometry.height())
label = QLabel()
#call update here: no crash
caption = QLabel()
caption.setText("Hello world")
box = QVBoxLayout()
box.addWidget(label)
box.addWidget(caption)
#call update here, no crash
window.setLayout(box)
#call update here, no crash
window.show()
#this call to update results in a crash
update(label)
#window.updateGeometry()
print("App: exec")
app.exec_()
Output:
desktop (3623,2160)
Read (1515,1051)
Rotate (1051,1515)
Thumbnail(832,1200)
App: exec
Do I need to do anything special to tell QT that the window size will be changing? Any suggestions for diagnosing the problem from here...
Update:
If I copy the body of the update function and paste it in place of the call to update, it no long crashes -- it works as expected.
From this I conclude that there is an object-lifetime issue. Somewhere behind the scenes QT and/or Pillow is keeping a pointer to an internal buffer rather than making a copy or "stealing" the buffer. When the object containing the buffer is deleted the pointer becomes invalid and "Bad Things Happen[TM]"
Now to determine who's being lazy...
I found a solution based on the observation mentioned in the Update that this appeared to be an object lifetime issue.
Changing the line in the update function from
pixmap = QPixmap.fromImage(qimage)
to
pixmap = QPixmap.fromImage(qimage).copy()
forces a copy of the pixmap. This copy apparently has its own data buffer rather than borrowing the buffer from the Image.
The Label then keeps a reference to the pixmap -- ensuring the lifetime of the buffer. The 'bug' seems to be that QPixmap.fromImage captures a pointer to the data in the Image, but does not keep a reference to the Image so if the Image gets garbage collected (which is likely 'cause it's a big object, the Label (and the pixmap) have a pointer to unallocated memory.
[This 'pointer to the buffer' stuff is sheer speculation on my part, but the bottom line is the program no longer crashes.]
In case anybody else stumbles upon this:
I struggled with a very similar issue and was able to solve it using slots and signals (based on this great article) since the .copy() solution did not work for me. My solution was to separate the creation of the QPixmap and the QLabel.setPixmap into different functions. When the function that creates the QPixmap finishes, it emits a signal that triggers the function that sets the pixmap to the label.
For instance, if you wanted to use threading:
class WorkerSignals(QObject):
ready = pyqtSignal()
class Worker(QRunnable):
def __init__(self, some_function, *args, **kwargs):
super(Worker, self).__init__()
self.some_function = some_function
self.args = args
self.kwargs = kwargs
self.signals = WorkerSignals()
self.kwargs['ready'] = self.signals.ready
#pyqtSlot()
def run(self):
self.some_function(*self.args, **self.kwargs)
def make_pixmap(qimage, ready, **kwargs):
pixmap = QPixmap.fromImage(qimage) # qimage is some QImage
ready.emit()
def set_pixmap(pixmap):
label.setPixmap(pixmap) # 'label' is some QLabel
threadpool = QThreadPool
worker = Worker(make_pixmap, image)
worker.signals.ready.connect(set_pixmap)
threadpool.start(worker)
Obviously using threading is not necessary in this scenario, but this is just to show that it's possible in case you want to process and show images without hanging the rest of the GUI.
Edit: The crashes came back, disregard the above. Working on another fix.
In my PyQt4-based program, QSliders (with signals sliderMoved and sliderReleased connected to callables) sometimes "freeze", i.e. they don't move anymore when trying to drag them with the mouse, even though sliderMoved and sliderReleased are still emitted.
This behaviour happens seemingly randomly, sometimes after running the program for hours -- making it more or less impossible to reproduce and test.
Any help to solve this issue would be welcome.
EDIT: This is with PyQt 4.10.4 on Python 3.4 and Windows 7.
After some debugging I am pretty sure that this was due to calling a GUI slot from a separate thread, which (I knew) is forbidden. Fixing this to use a proper signal-slot approach seems to have fixed the issue.
After calling the patch function defined below, all slot calls are wrapped by a wrapper that checks that they are called only from the GUI thread -- a warning is printed otherwise. This is how I found the culprit.
import functools
import sys
import threading
import traceback
from PyQt4.QtCore import QMetaMethod
from PyQt4.QtGui import QWidget
SLOT_CACHE = {}
def patch():
"""Check for calls to widget slots outside of the main thread.
"""
qwidget_getattribute = QWidget.__getattribute__
def getattribute(obj, name):
attr = qwidget_getattribute(obj, name)
if type(obj) not in SLOT_CACHE:
meta = qwidget_getattribute(obj, "metaObject")()
SLOT_CACHE[type(obj)] = [
method.signature().split("(", 1)[0]
for method in map(meta.method, range(meta.methodCount()))
if method.methodType() == QMetaMethod.Slot]
if (isinstance(attr, type(print)) and # Wrap builtin functions only.
attr.__name__ in SLOT_CACHE[type(obj)]):
#functools.wraps(
attr, assigned=functools.WRAPPER_ASSIGNMENTS + ("__self__",))
def wrapper(*args, **kwargs):
if threading.current_thread() is not threading.main_thread():
print("{}.{} was called out of main thread:".format(
type(obj), name), file=sys.stderr)
traceback.print_stack()
return attr(*args, **kwargs)
return wrapper
else:
return attr
QWidget.__getattribute__ = getattribute
I am using Mark Summerfield's Rapid GUI programming book, which was written for PyQt4, and I am using PyQt5. Some things must be different.
Can anybody see why this is failing on my Linux machine that runs Ubuntu 13.04? It runs on Mint 15 but sometimes ends with a segmentation fault. I think it has to do with the difference between PyQt4 and PyQt5, and I have been looking into the C++ implementation at the qt-project.org website. So far I can tell that QVBoxLayout does inherit from QDialog, and it does have a setLayout function. However, commenting out the last line in the _init_ function will allow the program to run without crashing, but also without any widgets added to the QDialog box.
import sys
import PyQt5.QtCore
import PyQt5.QtGui
import PyQt5.QtWidgets
class Form(PyQt5.QtWidgets.QDialog):
def __init__(self, parent=None):
super(Form, self).__init__(parent)
self.browser = PyQt5.QtWidgets.QTextBrowser()
self.lineEdit = PyQt5.QtWidgets.QLineEdit("default statement here")
self.lineEdit.selectAll()
layout = PyQt5.QtWidgets.QVBoxLayout()
layout.addWidget(self.browser)
layout.addWidget(self.lineEdit)
self.setLayout(layout) # <--- program seems to crash here
app = PyQt5.QtWidgets.QApplication(sys.argv)
form = Form()
form.show()
app.exec_()
I get an initial error message like this, repeated about 10 times:
(python3:9896): Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WIDGET (widget)' failed
Then it is followed by the following block, which repeats until I kill the program:
QXcbShmImage: shmget() failed (22) for size -524284 (65535x65535)
QWidget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
QWidget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
QPainter::translate: Painter not active
QPainter::save: Painter not active
QPainter::setClipRect: Painter not active
QPainter::pen: Painter not active
QPainter::setPen: Painter not active
QPainter::pen: Painter not active
QPainter::setPen: Painter not active
QPainter::restore: Unbalanced save/restore
QWidget::paintEngine: Should no longer be called
QPainter::begin: Paint device returned engine == 0, type: 1
QPainter::setClipRect: Painter not active
[etc, etc, etc...]
The problem is the size of the QTextBrowser.
See this bug:
https://bugreports.qt-project.org/browse/QTBUG-32527
I have attempted to purloin some of the code shipped with IP in Action and, following issues, I have even gone to the lengths of reading the book!
I am getting the error 'expect Delegate, got Function' when I use the following code. FYI I am passing in a reference to a WPF textBox so I should have a dispatcher on my UI element
I have removed all of the threading pipe reading stuff just to leave 'test' code:
import System
import System.IO
import Avacta.Optim.Server.WebServices
import Avacta.Optim.Server.DataModel
import sys
import clr
import time
from System import Console
from System.Threading import Thread, ThreadStart
def SetDispatcher(ui_element):
global dispatcher # needed else "Exception: 'NoneType' object has no attribute 'BeginInvoke'"
dispatcher = ui_element.Dispatcher
def Dispatch(function, *args):
dispatcher.BeginInvoke(lambda *_: function(*args))
def GetDispatchFunction(function):
return lambda *args: Dispatch(function, *args)
class ListOutput:
def __init__(self, textbox):
self.textbox = textbox
def write(self, string):
Dispatch(self.addText, string) # error: "expect Delegate, got Function"
#self.addText(string) # ok works fine w-w/o dispatcher stuff
def addText(self, string):
textbox.AppendText(string)
if textbox != None:
listout = ListOutput(textbox)
sys.stdout = listout
SetDispatcher(textbox)
print "Define running"
#running = True
Thread.Sleep(0)
time.sleep(2)
print "Start The Comms Thread..."
#comms_t = Thread(ThreadStart(run_comms))
#comms_t.Start()
Thread.Sleep(0)
time.sleep(2)
Any clues appreciated.
AndyF.
Thanks to Dino Viehland
Changing my dispatcher code to call the dispatcher directly fixes this issue.
dispatcher.BeginInvoke(System.Action(lambda *_: function(*args)))
Unfortunately I no longer get real-time output from my print statments to my 'console' - it all appears when the script completes. Remove the dispatcher and it reverts to real-time...
There is a set of dispatcher static methods (extension methods) are provided by way of DispatcherExtensions which take an Action as the parameter.
The code sample below demonstrates the usage of the WPF dispatcher. More information is available here http://msdn.microsoft.com/en-us/library/cc647497.aspx
import clr
clr.AddReference('WindowsBase')
clr.AddReference('System.Windows.Presentation')
from System import Action
from System.Windows.Threading import DispatcherExtensions, Dispatcher
dispatcher = Dispatcher.CurrentDispatcher
def workCallBack():
print 'working'
DispatcherExtensions.BeginInvoke(dispatcher, Action(workCallBack))