[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: Need help with qApp->processEvents()
From:       Michael Zanetti <michael_zanetti () gmx ! net>
Date:       2009-01-23 10:00:58
Message-ID: 200901231100.58783.michael_zanetti () gmx ! net
[Download RAW message or body]

On Monday 19 January 2009 15:28:52 Thiago Macieira wrote:
> Em Segunda-feira 19 Janeiro 2009, ās 14:19:15, Michael Zanetti escreveu:
> > On Monday 19 January 2009 13:56:10 Thiago Macieira wrote:
> > > Em Segunda-feira 19 Janeiro 2009, ās 13:31:44, Michael Zanetti escreveu:
> > > > Hi all,
> > > >
> > > > In Kopete's OTR Plugin I use qApp->processEvents() to keep the GUI
> > > > updated while a second thread is creating the private/public keypair.
> > >
> > > Don't do that.
> > >
> > > Instead, from the other thread, post an event or emit a signal
> > > indicating that the operation is done. Let the main (GUI) thread
> > > continue running and working normally.
> > >
> > > Avoid processEvents like the plague.
> >
> > The problem is that I need to block incoming/outgoing messages or libotr
> > will crash. I could keep the main thread running but then I would need to
> > keep some sort of a message buffer in the plugin. In my opinion thats
> > even worse than blocking the main thread.
> >
> > What do you think?
>
> I think you can do it without processEvents.
>
> Don't write into libotr until you're cleared. Keep messages in a queue
> until that point.

First of all,
thanks for your answers!

Altough I believe you (and agree with you) that blocking the main thread is 
usually a bad thing, I cannot agree with you in this specific case.

1. If the plugin is enabled, _every_ message (also unencrypted) have to pass 
through libotr. For this, If I would keep my message-queue in the plugin the 
user won't be able to send or receive any message. What else should it do then 
with Kopete if not sending or receiving messages?

2. even more, the user would be wondering: "Where is the message I just typed 
in?" It  is stuck into kopete... For this, the message-queue solution would 
also include to write some sort of user-feedback about the current message-
queue.

3.The plugin configuration module, the contact list context menu and many other 
parts where the user could interact with the libotr would be needed to be 
disabled temporary to prevent the user from interrupting the libotr through 
some configuration options etc.

So, the results are: Most parts of kopete would be needed to be blocked 
anyway. So why don't block the main thread and be _sure_ no potential user-
intaraction would be possible. The eventLoop consists of 3 lines of code. The 
queueing system would consist of about 100 lines or more. This means 100 
potential buggy lines for no other than the "avoid-it-like-the-plague" reason.

In this specific case I really tend to block the main thread as kopete wouln't 
be usable anyway during the key creation process.

So the final question is:

As "qApp->processEvents(QEventLoop::ExcludeSocketNotifiers)" worked very well 
in KDE3, but does not work in KDE4, could this be a Qt bug? Or has anything 
changed that do not understand here? According to the documentation 
"QEventLoop::ExcludeSocketNotifiers" sould not tell kopete to get new incoming 
messages, but it actually does...

Tahnks,
Michael

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]