On Sunday 07 of March 2004 11:39, Guillaume Laurent wrote:
> On Sunday 07 March 2004 11:33, Matthias Ettrich wrote:
> > While I don't argue that it might be possible to find a generic solution
> > to this and similar problems on the toolkit level, I'm not quite sure
> > how, yet. General rule: do not exclude user input when the mouse is
> > pressed down.

 Actually I think the general rule rather should be: do not use misleading or 
wrong names. ExcludeSocketNotifiers ignores socket notifiers events, but 
keeps them pending. The same for the hidden ExcludeTimers. But 
ExcludeUserInput doesn't really exclude user input (at least according to 
what my dictionary says 'exclude' means), it discards it -> it should be 
either fixed to do what it says, or it should be called DiscardUserInput.

 Guillaume is not the only one to run into this problem. In case the dreadful 
KDE bug #61412 hasn't been fixed in Qt yet, just e.g. have a look at 
QClipboard.

>
> But the problem is that at the time I'm excluding user events, I don't
> expect the mouse button to be down. It's true that this is a wrong
> assumption in the case of the qslider, given that it reacts to the mouse
> button being kept down.
>
> > The sitation is roughtly equivalent to installing an event filter on a
> > push button on press that eats all mouse release events. It is hard for
> > the toolkit to know why you might not want the button to remained pressed
> > down in this case.
>
> Indeed. I think I'll just replace the slot's content by the posting of a
> QCustomEvent and do the "long changes" in the event handler.

-- 
Lubos Lunak
KDE developer
---------------------------------------------------------------------
SuSE CR, s.r.o.  e-mail: l.lunak@suse.cz , l.lunak@kde.org
Drahobejlova 27  tel: +420 2 9654 2373
190 00 Praha 9   fax: +420 2 9654 2374
Czech Republic   http://www.suse.cz/