Re: [PyQt] Unexpected behaviour
On 17.08.10 13:07:00, Peter Milliken wrote: Sorry if the answer to this is obvious, but it is entirely unexpected behaviour IMO :-) I have created a simple GUI with some elements, such as a progressbar and radiobuttons, which are 'dynamically' updated when an underlying Python task (created using threading.Thread) communicates information back to the GUI i.e. I have a button, which calls a command, which starts a task and then loops continuously receiving update commands from the task via a pipe and updating the GUI elements with the information (radio buttons indicate which phase of the process is being executed, the progress bar indicates % completion for each phase). This all works fine, but the unexpected behaviour is when I switch focus away from the GUI application all of the graphics elements stop being updated! The underlying task is running and it runs to successful completion but no further graphics updates are performed once I switch focus away from the application. Even if I switch back to the application, the GUI elements remain frozen at the point at which I switched away until the task completes - it is only then that the graphics elements are changed due to the message from the task that the operation is complete i.e. the phase radio buttons are returned to a default value and the progress bar is cleared to 0%.. Non-Updating graphics sounds like you're blocking the event loop, you need to leave that running all the time. If thats not the problem you'll have to provide a small self-contained example showing the problem by stripping down your real app. Otherwise I can't see how to help you. Andreas -- You will have long and healthy life. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Unexpected behaviour
On Mon, Aug 16, 2010 at 11:03 PM, Andreas Pakulat ap...@gmx.de wrote: On 17.08.10 13:07:00, Peter Milliken wrote: Sorry if the answer to this is obvious, but it is entirely unexpected behaviour IMO :-) I have created a simple GUI with some elements, such as a progressbar and radiobuttons, which are 'dynamically' updated when an underlying Python task (created using threading.Thread) communicates information back to the GUI ... Another tidbit is that mixing Python threading.Thread() with Qt's own thread needs special care. The threading.Thread() thread should never do any GUI updating, or it will lead to some weird crashing issues. Yao ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] memory leak using QMainWindow.removeToolBar
On Mon, 16 Aug 2010 22:59:22 + (UTC), danny shev...@lanl.gov wrote: thanks, your solution works, and stops my code from seg faulting. I'm curious why mine doesn't work. In the documentation for QMainWindow http://www.riverbankcomputing.co.uk/static/Docs/PyQt4/html/qmainwindow.html#addToolBar-3 The third overloading of the addToolBar method, was what I was using. It should be equivalent, but I must be missing something. There does seem to be a bug. Even though addToolBar() takes ownership of the toolbar, removeToolBar() doesn't change the current ownership. It will be fixed in tonight's snapshot. The consequence is that you have to do extra work to really delete a removed toolbar, ie. reparent it to None. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Relative imports in compiled UI files?
I recently ported one of my apps to Python 3, and one of the headaches I had was because import statements in compiled UI files aren't relative (from . import foo). In python 2, it wasn't a problem because the lookup was made in the same folder as the module importing the thing, but under Python 3, I had to tweak my sys.path to make it work. If there was a way to generate relative imports, that would be a cleaner solution than my sys.path hackage. So, possible? If not, can I hope on it being implemented some day? Thanks, Virgil Dupras ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Just for fun: QCompleter accessing a QListWidget's internal model through a proxy ?
Hi everyone, After many moons of lurking I have finally subscribed to ask for advice about my current challenge: In this app I'm working on (my first real, non-trivial one, admittedly), I have a number of QListWidgets in the main window, holding plain strings, each with an associated QLineEdit for input. They work just fine, and there really is no need for anything more elaborate than list widgets for what they do. Only now that it's almost finished, with everything in place and the code working well, I just discovered the existence of QCompleters by accident... and obviously now I want them in the line edits. However, QCompleters are designed to work only with real models, not convenience widgets. Of course it's very easy to use them with a plain QStringList, but it feels somewhat clunky and inefficient to duplicate the list widget's content to the completer's string list, refreshing it each time that content changes... and I don't really feel like retooling the entire UI to use QListViews just for the sake of completers. So I thought, perhaps naively, that it might be possible to build a kind of proxy model, that would feed a completer with data pulled from a list widget's hidden, internal model. After quite some time trying to make sense of the Qt docs (which seem to contradict themselves sometimes), I settled on the following : - make the model a subclass of QAbstractListModel; - reimplement the rowCount(), data() and index() methods as required, to fetch the relevant data from the list widget (passed as a parameter to the constructor). Here is the entire model code : class proxyModel(QAbstractListModel): def __init__(self, qlwi, parent=None): QAbstractListModel.__init__(self, parent) self.qlwi = qlwi def index (self, row, col = 0, parent = None): return self.qlwi.indexFromItem(self.qlwi.item(row)) def rowCount (self, parent = None): return self.qlwi.count() def data (self, index, role = Qt.DisplayRole): return self.qlwi.itemFromIndex(index).data(role) I have verified (with good old prints) that the three methods return the expected values and types (QModelIndex, int and QVariant), reflecting changes made to the list widget on the fly. Unfortunately, setting a completer's model to a proxyModel instance does exactly nothing: everything works just as before, without completion. Lacking a better understanding of the Qt internals, I'm at a loss as to which way I should dig now... I tried to Google for prior art, and found nothing relevant, which usually means one of two things : - the entire notion is stupid and impossible, for some fundamental reason that eludes me; - or else it is actually so trivial that no one has ever thought of documenting it, and I'm just missing something really obvious. Either way, I'd welcome suggestions and pointers to the what and why, hopefully learning something important about (Py)Qt in the process... Thanks in advance, fp ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Best way to implement a modular framework?
Hello all, I'm looking for some advice as to the best way of implementing an MDI - like application which is modular. i.e. I want to have a MainWindow host with a menu which dynamically loads a list of modules available at start-up; where each module is simply a different dialog window interface (QDialog). The idea is deploy my application so that I may, in the future, expand its functionality by adding new dialogs as needed (e.g. e-mailing the users one or more files which can be dropped in the app directory) My first simplistic idea was to have the host application look for available ui_xxx.py files in the application directory at start-up to populate the list of available dialogs, using a suitable naming convention. However, I ultimately need to deploy an executable host application to the users and am not sure how if it still would allow me to load ui_xxx.py files dynamically. I welcome any suggestions ... there must be a much better way of building a modular app.. Thanks for any advice. Bernard. CONFIDENTIALITY WARNING This e-mail message, including any attachment(s), is confidential. If we sent this communication to you in error, please do not disclose it to anyone else or use the information in it. Please notify the sender of the transmission error and then delete our communication from your system without printing, copying or forwarding it. Thank you for your co-operation. AVERTISSEMENT CONCERNANT LE CARACTERE CONFIDENTIEL DE L'INFORMATION Le present courriel, y compris toute piece qui y est jointe, est confidentiel. Si nous vous avons envoye cette communication par erreur, nous vous prions de ne la divulguer a personne ni a utiliser l’information qu’elle contient. Veuillez informer l’expediteur de l’erreur de transmission et effacer ensuite notre communication de votre systeme sans l’imprimer, ni la copier ni la retransmettre. Nous vous remercions de votre cooperation. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Just for fun: QCompleter accessing a QListWidget's internal model through a proxy ?
On Tuesday 17 August 2010 11:23:55 fpp wrote: Hi everyone, After many moons of lurking I have finally subscribed to ask for advice about my current challenge: In this app I'm working on (my first real, non-trivial one, admittedly), I have a number of QListWidgets in the main window, holding plain strings, each with an associated QLineEdit for input. They work just fine, and there really is no need for anything more elaborate than list widgets for what they do. Only now that it's almost finished, with everything in place and the code working well, I just discovered the existence of QCompleters by accident... and obviously now I want them in the line edits. However, QCompleters are designed to work only with real models, not convenience widgets. Of course it's very easy to use them with a plain QStringList, but it feels somewhat clunky and inefficient to duplicate the list widget's content to the completer's string list, refreshing it each time that content changes... and I don't really feel like retooling the entire UI to use QListViews just for the sake of completers. So I thought, perhaps naively, that it might be possible to build a kind of proxy model, that would feed a completer with data pulled from a list widget's hidden, internal model. I could be overlooking something but I don't see why you can't use the list widget's model directly. The details of the implemenation may be private, but the QAbstractItemModel interface is still public and usable. Should be as simple as completer = QCompleter( listWidget.model(), parent ) Matt ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Just for fun: QCompleter accessing a QListWidget's internal model through a proxy ?
On Tue, Aug 17, 2010 at 9:25 PM, Matt Newell newe...@blur.com wrote: On Tuesday 17 August 2010 11:23:55 fpp wrote: So I thought, perhaps naively, that it might be possible to build a kind of proxy model, that would feed a completer with data pulled from a list widget's hidden, internal model. I could be overlooking something but I don't see why you can't use the list widget's model directly. The details of the implementation may be private, but the QAbstractItemModel interface is still public and usable. Should be as simple as completer = QCompleter( listWidget.model(), parent ) Indeed it is !... self.slaps_forehead() Wow, that was quick... so it was actually option #2 of my self-prediction: or else it is so trivial that no one has ever thought of documenting it, and I'm just missing something really obvious. ...which is good news. Just the usual result of my inability to parse the Qt docs, wrap my head around object models, and generally add two plus two. Thanks Matt ! fp ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
