@behruz-montazeri if you want to learn how to do MVC within python-pyqt shoot me a message on Discord at DenniO#8137 and I will dive into that with you as well as share some example code as that can be a rather extensive discourse.

That depends on what you are actually trying to put into the ListView -- your List of Dictionaries is a bunch of Dictionary Objects or just the names of those Dictionary Objects?

With your description I would strongly suggest then doing away with the Tabs all together and use a Stackable Widget basically think an array of views or turning your tabs into an array and only showing the contents of the tab rather than showing the tab at all. If you need help on how to change this into a stackable widget just ask but give it a try first you will learn more from trying it than you will from being spoon fed ;)

@daljit97 that is awesome -- but to reiterate for future questions you might have - including an MRE (Minimal Reproducible Example) which means one can simply copy/paste the MRE and run it to get the same results greatly speeds up getting an answer. If you include an MRE that will not run because it has elements removed that are still referenced that is not technically an MRE because it does not reproduce what you are experiencing.

i found it. Edit Tab order under the Edit menu. i figured it would have been on each widget. learned something new..

Well without seeing a minimal fully functioning example of your code it is kind of hard to guess what you might be doing wrong. However as a general answer I (unless the combo box has a large amount of data in it) just store this data in dictionary and/or list and then add to the dictionary/list -- purge the combo box -- and add the data pre-sorted back into the combo box

Okay finally got a semi-copy of your code running -- below is the very slightly cleaned up tweaked version that basically does not work properly but does work. I have also commented on the few changes I had to make to get the code to function. I am guessing you used the Designer to create this because its a fairly ugly code which looks a lot like that stuff the Designer spits out. Note the biggest issue I encountered was the two cases of doing integer math on an object which my Python 3.7 / PyQt5 will not allow import sys from PyQt5 import QtCore, QtGui, QtWidgets class Ui_MainWindow(object): def setupUi(self, MainWindow): MainWindow.setObjectName("MainWindow") MainWindow.resize(1090, 681) MainWindow.setStyleSheet("") self.centralwidget = QtWidgets.QWidget(MainWindow) self.centralwidget.setObjectName("centralwidget") self.pushButton = QtWidgets.QPushButton(self.centralwidget) self.pushButton.setGeometry(QtCore.QRect(150, 290, 271, 121)) self.pushButton.setStyleSheet("") self.pushButton.setText("") icon = QtGui.QIcon() icon.addPixmap(QtGui.QPixmap("images/red-off-16.png"), QtGui.QIcon.Normal, QtGui.QIcon.Off) icon.addPixmap(QtGui.QPixmap("images/red-off-16.png"), QtGui.QIcon.Normal, QtGui.QIcon.On) icon.addPixmap(QtGui.QPixmap("images/red-off-16.png"), QtGui.QIcon.Disabled, QtGui.QIcon.Off) icon.addPixmap(QtGui.QPixmap("images/red-off-16.png"), QtGui.QIcon.Disabled, QtGui.QIcon.On) icon.addPixmap(QtGui.QPixmap("images/red-on-16.png"), QtGui.QIcon.Active, QtGui.QIcon.Off) icon.addPixmap(QtGui.QPixmap("images/red-on-16.png"), QtGui.QIcon.Active, QtGui.QIcon.On) icon.addPixmap(QtGui.QPixmap("images/grn-hov-16.png"), QtGui.QIcon.Selected, QtGui.QIcon.Off) # Remarked this line out because it gives an error doing integer math on an object ?? # icon.addPixmap(QtGui.QPixmap("images/grn-hov-16.png"), QtGui.QIcon.Selected, QtGui.QIcon.On)-10 self.pushButton.setIcon(icon) self.pushButton.setObjectName("pushButton") self.toolButton = QtWidgets.QToolButton(self.centralwidget) self.toolButton.setGeometry(QtCore.QRect(170, 30, 181, 231)) self.toolButton.setText("") self.toolButton.setIcon(icon) self.toolButton.setIconSize(QtCore.QSize(200, 300)) self.toolButton.setCheckable(True) self.toolButton.setChecked(True) self.toolButton.setObjectName("toolButton") MainWindow.setCentralWidget(self.centralwidget) self.menubar = QtWidgets.QMenuBar(MainWindow) self.menubar.setGeometry(QtCore.QRect(0, 0, 1090, 22)) self.menubar.setObjectName("menubar") MainWindow.setMenuBar(self.menubar) # I added a modified version to make the program work self.statusbar = QtWidgets.QStatusBar(MainWindow) #This is the original line that gives an error because your doing integer math on an object?? # self.statusbar = QtWidgets.QStatusBar(MainWindow)-10 # Do not have the image so re-marked it out should have had no ill effect but not 100% sure # self.statusbar.setStyleSheet("border-image: url(:/images/Button5-3.png)") self.statusbar.setObjectName("statusbar") MainWindow.setStatusBar(self.statusbar) self.retranslateUi(MainWindow) QtCore.QMetaObject.connectSlotsByName(MainWindow) def retranslateUi(self, MainWindow): _translate = QtCore.QCoreApplication.translate MainWindow.setWindowTitle(_translate("MainWindow", "MainWindow")) if __name__ == "__main__": app = QtWidgets.QApplication(sys.argv) MainWindow = QtWidgets.QMainWindow() ui = Ui_MainWindow() ui.setupUi(MainWindow) MainWindow.show() sys.exit(app.exec_())

@nekitamtip what I would do is not rely on the call stack as @Kent-Dorfman points out its unreliable at best and not available due to threading issues (now that does not mean it cannot be just means it would take a lot of work and time to figure it out if it is even possible). So with that said and a much easier methodology for handling this in code regardless of the coding language you use here is what I do. Any place you plan to "raise" an error or handle an exception include enough information so that you can easily determine where that error occurred along with what that error was. In your example I would change the raise to read: raise Exception('MyTreadWorker.job_with_exception_raised :' + error_message) This basically (at a glance) tells you where the error occurred in detail and if the error was dynamic what that error was -- note if the error is static then simply replace [ ' + error_message ] with [ Description of Error ' ] again do this any place you raise an error and/or use a try except -- further I would actually call an error_handler routine in case I want to switch from live debugging to production debugging and want those errors posted to an error-log of some sort. Basically it is considered quality programming that when you raise an error or handle an exception that you report enough information back so that with that error message you (1) Know exactly where the error occurred (2) Know exactly what the error was (3) and include any extra information that might be available that would make fixing that error much easier If you do this as a standard within all your code you will soon find out that tracking done bugs becomes a trivial task.

First off regardless of the coding language you should follow the MVC (Model-View-Controller) methodology of coding which basically divorces the front-end (View) from the back-end (Model) by putting in a middle interpreter layer (Controller). Why do this well first it has the benefit of separating functionality and focusing each element on what it does best. The GUI (View) is best for handling the user interface and not very good with dealing with the data, while the Database (Model) is best for handling the data and is not very good with handling the user interface. The Controller is just the method for moving the data from the View to Model. This also has a secondary benefit if you ever change the back-end with a different database engine the only thing that is effected is the Model and maybe a bit of the Controller the GUI is essentially untouched and vice-versa if you wish to change the front-end the only thing that really changes is the front-end since all the API calls to the middle-tier would essentially remain the same. Further should the business logic affecting the data occur that is generally dealt with within the Controller or the Database depending on the implementation of the business logic. For instance data validation and manipulation generally takes place within the Controller layer making sure that no bad-data gets into the database which is always a nightmare and something that happens often if you directly tie the front-end into the back-end. So in short use pyqt5 to handle your front-end GUI and use python to handle your interface to your database (validating and moving the data to the database) and let the database do what its best at doing - handling the data with storage and stored-procedures, triggers, etc... I hope that helps

It appears they are using the following version of the overloaded QImage call QtGui.QImage(uchar *data, int width, int height, int bytesPerLine, QImage::Format format, QImageCleanupFunction cleanupFunction = nullptr, void *cleanupInfo = nullptr) Thus the h*np.nbytes[np.uint8] would be the bytesPerLine That being said here is an augmented bit of documentation (https://doc.qt.io/qt-5/qimage.html#QImage-5) covering this function that I think will answer the basic question, cannot guarantee it will not raise additional questions though This constructs an image with the given width, height and format, that uses an existing memory buffer, data. The width and height must be specified in pixels. The bytesPerLine specifies the number of bytes per line (stride). For information on Stride see: (https://medium.com/@oleg.shipitko/what-does-stride-mean-in-image-processing-bba158a72bcd) The buffer must remain valid throughout the life of the QImage and all copies that have not been modified or otherwise detached from the original buffer. The image does not delete the buffer at destruction. You can provide a function pointer cleanupFunction along with an extra pointer cleanupInfo that will be called when the last copy is destroyed. If format is an indexed color format, the image color table is initially empty and must be sufficiently expanded with setColorCount() or setColorTable() before the image is used.

So I solved my problem. It turns out QImage needs the image to be a flat numpy array. Here is how it's done: qrgb_dict = {'r': lambda x: QtGui.qRgb(x, 0, 0), 'g': lambda x: QtGui.qRgb(0, x, 0), 'b': lambda x: QtGui.qRgb(0, 0, x)} colortable = [qrgb_dict[color](i) for i in range(256)] img = QtGui.QImage(arr, w, h, w, QtGui.QImage.Format_Indexed8) img.setColorTable(colortable) Where arr is an array of shape (h,w) and with uint8 values in 0-255

I was able to solve this by switching to pycharm, for some reason spyder did not want to cooperate, kept getting DLL not found errors, "application failed could not find or load qt plugin could not be initialized", and importing QCharts would not work. everything seems to be working now thorough pycharm.

In short use Qt/C++ for Android. PyQt claims to support Android, but nobody achieved to get it working. Qt for Python doesn't support it at all.

@LarsR not sure if you are still looking but I have been using OpenCue located on https://github.com/vfxpipeline Now granted it is not pyqt5 but its close enough to use it has a tool to better understand how the MVC could be implemented within pyqt5

OK, so the issue turned out to be something different. We are using QtPy and it needs the environment variable QT_API set to pyside2 for our Windows setup. For some reason the environment passed to QProcess isn't inheriting that variable and it was defaulting to pyside. Setting it manually to pyside2 by calling setProcessEnvironment on our QProcess before the start call gets everything working. Not sure if this is a PySide2 bug or not. The QProcess.execute documentation says: "The environment and working directory are inherited from the calling process." but it doesn't say this explicitly for start.

@blossomsg Hi That is fine, please marked as solved then :)