headers
Matt Smith | 6 Oct 21:54
Favicon

Waiting on non-QT events.

I have written an app for checking my email, and it laggs when I am
downloading from the server and I am curious how to avoid this.

The general layout is 
EmailWidget (Qwidget with a layout)
	.ImapTool
	.MessageList(QlistView)
	.MailBoxList(QlistView)
	def RefreshMessageList()

 I double click the MailBoxList it emits a signal that Email Widget is
connected to which then calls the ImapTool to query the imap server.
This stops everything, the lists freeze and I can't do anything until
the imap routine finishes.  
Could this be avoided using more signals.  Like have the ImapTool as a
separate QObject that emits a signal when finish?.

thanks
mbs
Permalink | Reply |
headers
Lev Shamardin | 7 Oct 08:23

Re: Waiting on non-QT events.

On 10/06/2008 11:57 PM, Matt Smith wrote:
> > I have written an app for checking my email, and it laggs when I am
> > downloading from the server and I am curious how to avoid this.
> >
[...]
> >  I double click the MailBoxList it emits a signal that Email Widget is
> > connected to which then calls the ImapTool to query the imap server.
> > This stops everything, the lists freeze and I can't do anything until
> > the imap routine finishes.
> > Could this be avoided using more signals.  Like have the ImapTool as a
> > separate QObject that emits a signal when finish?.

Yes, if you start your ImapTool in a separate thread/process. I'm writing a
PyQt4 app with heavy networking and lots of slow queries to a remote server. All
queries are run in a separate from the GUI thread, and the GUI thread is
notified about the completion of queries with signals. The result is smooth UI
experience without much visible lags.

--
Lev.
Permalink | Reply |
headers
Marcell Mars | 8 Oct 15:55

Re: Waiting on non-QT events.

this is how i solved my problem... i run the non-qt process as thread
and inherit class Bridge which emits the Qt signals for me... hope it
will help you:

http://pastebin.com/f16019559

i'm sure there are more elegant solutions and i would like to learn
about them...
Permalink | Reply |
headers
Mistobaan | 8 Oct 17:16

Re: Waiting on non-QT events.

> http://pastebin.com/f16019559

I am wrong or the line 21 never gets called, so everything still  
happens on one single thread?

Fabrizio
Permalink | Reply |
headers
Marcell Mars | 8 Oct 22:57

Re: Waiting on non-QT events.

On Wed, Oct 8, 2008 at 5:16 PM, Mistobaan <mistobaan <at> gmail.com> wrote:
>> http://pastebin.com/f16019559
>
> I am wrong or the line 21 never gets called, so everything still happens on
> one single thread?

it's started after Gamepad.start() which trigger Gamepad.run() then...
i have it in commented code later on:
gamepad = Gamepad()

QObject.connect(gamepad.bridge, SIGNAL('gamepad'), pisi)
gamepad.start()

it works for me inside the application.. am i doing something wrong?
Permalink | Reply |
headers
Matt Smith | 8 Oct 23:32
Favicon

Re: Waiting on non-QT events.


Okay I looked at the example:

> http://pastebin.com/f16019559

 and it appears that Bridge is a little bit unnecessary when you could
just emit the signal from your QThread as it is?.  

So I tried to make an example following what you did;
http://pastebin.com/m192d4d3f

That brings me to a question of what happens when I make a new QWidget?
Does that automatically thread?  I couldn't do the above example with a
QObject alone I had to use a QThread, otherwise it would wait until
TerminalX finished.

thanks
mbs
Permalink | Reply |

Gmane