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

List:       kde-commits
Subject:    Re: kdenetwork/kmail
From:       Marc Mutz <mutz () kde ! org>
Date:       2001-12-27 15:42:20
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thursday 27 December 2001 15:13, Carsten Pfeiffer wrote:
> On Tue, Dec 18, 2001 at 10:32:23PM +0100, kde-cvs@kde.org wrote:
> >  Log Message:
> >  fix #36285; QListView doesn't seem to emit the currentChanged()
> > signal on setCurrentItem() *sigh*. The signals seem to be really
> > messed up with Qt3.x so far :-(
>
> But that's rather correct. You shouldn't emit a "changed" when a
> "set" method was called.
<snip>

Why not?

I think the signal should be emitted whenever the current item changed. 
Not just in the "user interaction" case.

Else, how do you want to keep other classes informed about the current 
item? Say, you have a subclass of a listview that sometimes sets a new 
current item (common when removing or adding stuff). Do you really want 
to audit all those places where this can happen (even hidden ones, e.g. 
"delete currentItem()") and emit the signal yourself?

For a connected slot it doen't make a difference whether the user 
clicked on an item or the subclass did a setCurrentItem(). Worse: It 
can't distinguish those. But the signal is there to inform the 
connected slot about that. What's the point in doing so only for 
certain cases.

Marc

- -- 
"Similia similibus currentur"
           -- Bush's new motto in fighting terrorism.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8K0Fc3oWD+L2/6DgRAtuoAJ9m4WQdQqYp7eIKYy/F1Tr0yrx0OwCgwUkU
WKZun0nTw4fcXLT76wv5mkk=
=FNeS
-----END PGP SIGNATURE-----

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