On Fri, 16 Dec 2005, Arthur Pemberton wrote: > Ideally, the console client would be simply a downloader, while the GUI > would use the same mechanisms to access the data, but give more > interactivty (renaming, prioritizing of downloads, etc.) Not sure if this > is the information you meant that was missing.
OK. So you could implement the downloader in such a way that makes it fairly independent from the way it was invoked. Perhaps it would perform blocking network operations using modules from the Python standard library, or maybe you would provide a way for the main application to monitor its progress and interrupt it if required. Keeping the GUI interactive while a long-term operation is being performed can be a challenge, especially if the control isn't returned until the operation is finished. There are ways to ensure that the GUI interface is refreshed while this occurs: by calling QApplication.processEvents() or by performing the operation in a separate thread. Note that GUI programming has to be performed in the main thread - you can't (easily) make calls to PyQt from a separate thread. If the console-only version of the client doesn't use PyQt, and you want to use the same implementation in the GUI client, you can probably use Python's threading module to run the downloader in a separate thread. I guess this should work with PyQt for Qt 3 as long as you don't use the Qt's threading features. You may not use threading in the console-only client - users may be satisifed with a client that only provides feedback once it is finished. I hope this advice is helpful, even if it is a bit vague. I'm sure others will correct me if what I've said is confusing. David _______________________________________________ PyKDE mailing list PyKDE@mats.imk.fraunhofer.de http://mats.imk.fraunhofer.de/mailman/listinfo/pykde
